Software & Application Miscellaneous: ZwMapViewOfSection returning a user mode address

Can you show us your code - apparently, you forgot about OBJ_KERNEL_HANDLE
attribute on your ZwCreateSection() call....

Anton Bassov

"usfinecats" wrote:

> ZwMapViewOfSection(, NtCurrentProcess(),...);
> returns a pointer to the address of my section, but it in one case this is a
> user mode address. When I do a subsequent call of ZwWriteFile(...another
> file...) I am using this address as input and it crashes bugcheck C4 because
> of this.
> What I need then is to have ZwMapViewOfSection return a Kernel address as
> the base of the mapped view. Is PsGetCurrentProcess ()going to help me? Or
> is it just going to give me the User's process.
> A last resort would be to copy my view into a kernel buffer allocated from
> paged memory, before I do the write, but this seems a very long way around
> the block.
> How do I get a useful input buffer address for ZwWriteFile from
> ZwMapviewofSection()? Do I want the system process ? how do I get it?
> Thanks
>
> --
> Gak -
> Finecats

ZwMapViewOfSection maps a section into user address space of the calling
process. I don't know what would happen if you mapped the section in the
context of a system process.
Alternate solution instead of copying memory, you could allocate an MDL for
the memory you want to write, probe and lock the pages, and get system
address for MDL.
-Eliyas

"usfinecats" <usfinecats...nospam.nospam> wrote in message
news:7FB8FC84-6552-441A-AAC7-BC1EADCBEA25...microsoft.com...
> I've got the obvious stuff covered, here is the InitObjAttrs and
> ZwCreateSection code
>
> InitializeObjectAttributes(&ObjAttributes,NULL,OBJ_KERNEL_HANDLE,NULL,NULL);
> NtStatus = ZwCreateSection(
> &pFI->MMFHandle, //OUT PHANDLE SectionHandle,
> STANDARD_RIGHTS_REQUIRED | SECTION_QUERY | SECTION_MAP_READ,
> &ObjAttributes ,
> NULL ,
> PAGE_READONLY,
> SEC_COMMIT, // AllocationAttributes,
> H // FileHandle OPTIONAL
> );
> --
> Gak -
> Finecats
>
> "Anton Bassov" wrote:
>> Can you show us your code - apparently, you forgot about
>> OBJ_KERNEL_HANDLE
>> attribute on your ZwCreateSection() call....
>> Anton Bassov
>>
>> "usfinecats" wrote:
>> > ZwMapViewOfSection(, NtCurrentProcess(),...);
>> > returns a pointer to the address of my section, but it in one case this
>> > is a
>> > user mode address. When I do a subsequent call of
>> > ZwWriteFile(...another
>> > file...) I am using this address as input and it crashes bugcheck C4
>> > because
>> > of this.
>> >
>> > What I need then is to have ZwMapViewOfSection return a Kernel address
>> > as
>> > the base of the mapped view. Is PsGetCurrentProcess ()going to help
>> > me? Or
>> > is it just going to give me the User's process.
>> >
>> > A last resort would be to copy my view into a kernel buffer allocated
>> > from
>> > paged memory, before I do the write, but this seems a very long way
>> > around
>> > the block.
>> >
>> > How do I get a useful input buffer address for ZwWriteFile from
>> > ZwMapviewofSection()? Do I want the system process ? how do I get it?
>> >
>> > Thanks
>> >
>> >
>> >
>> > --
>> > Gak -
>> > Finecats

Eliyas Yakub [MSFT] wrote:
> ZwMapViewOfSection maps a section into user address space of the calling
> process. I don't know what would happen if you mapped the section in the
> context of a system process.

You get a section mapped into the user mode portion of the system
process. Of course you also have to find the correct value for
AllocationType, which is a bit of a mystery.

The MDL approach worked fine, thanks.
--
Gak -
Finecats

"Eliyas Yakub [MSFT]" wrote:

> ZwMapViewOfSection maps a section into user address space of the calling
> process. I don't know what would happen if you mapped the section in the
> context of a system process.
> Alternate solution instead of copying memory, you could allocate an MDL for
> the memory you want to write, probe and lock the pages, and get system
> address for MDL.
> -Eliyas
>
> "usfinecats" <usfinecats...nospam.nospam> wrote in message
> news:7FB8FC84-6552-441A-AAC7-BC1EADCBEA25...microsoft.com...
> >
> > I've got the obvious stuff covered, here is the InitObjAttrs and
> > ZwCreateSection code
> >
> >
> >
> > InitializeObjectAttributes(&ObjAttributes,NULL,OBJ_KERNEL_HANDLE,NULL,NULL);
> >
> > NtStatus = ZwCreateSection(
> > &pFI->MMFHandle, //OUT PHANDLE SectionHandle,
> > STANDARD_RIGHTS_REQUIRED | SECTION_QUERY | SECTION_MAP_READ,
> > &ObjAttributes ,
> > NULL ,
> > PAGE_READONLY,
> > SEC_COMMIT, // AllocationAttributes,
> > H // FileHandle OPTIONAL
> > );
> > --
> > Gak -
> > Finecats
> >
> >
> > "Anton Bassov" wrote:
> >
> >> Can you show us your code - apparently, you forgot about
> >> OBJ_KERNEL_HANDLE
> >> attribute on your ZwCreateSection() call....
> >>
> >> Anton Bassov
> >>
> >>
> >> "usfinecats" wrote:
> >>
> >> > ZwMapViewOfSection(, NtCurrentProcess(),...);
> >> > returns a pointer to the address of my section, but it in one case this
> >> > is a
> >> > user mode address. When I do a subsequent call of
> >> > ZwWriteFile(...another
> >> > file...) I am using this address as input and it crashes bugcheck C4
> >> > because
> >> > of this.
> >> >
> >> > What I need then is to have ZwMapViewOfSection return a Kernel address
> >> > as
> >> > the base of the mapped view. Is PsGetCurrentProcess ()going to help
> >> > me? Or
> >> > is it just going to give me the User's process.
> >> >
> >> > A last resort would be to copy my view into a kernel buffer allocated
> >> > from
> >> > paged memory, before I do the write, but this seems a very long way
> >> > around
> >> > the block.
> >> >
> >> > How do I get a useful input buffer address for ZwWriteFile from
> >> > ZwMapviewofSection()? Do I want the system process ? how do I get it?
> >> >
> >> > Thanks
> >> >
> >> >
> >> >
> >> > --
> >> > Gak -
> >> > Finecats
>

> > Since when does a system process has its representation in the user mode?
> Since NT4 at least. ZwMapViewOfSection works for System process in NT4, you can
> then access this memory from system thread context using __try/__except

... which still does not mean that a system process has its representation
in the user mode.

Actually, the only reason why I argued with Mark's statement about " user
mode portion of the system process" is because the very term "user address
space" is meaningless when applied to system process . In order to understand
it, you have to recall some x86-specific features.

Strictly speaking, terms "kernel mode" and "user mode" apply only to the
code segment - privilege level of currently running code is defined by CS
register.
As far as address space is concerned, a page can be accessible either to
both privileged and non-privileged code, or only to the privileged one - it
depends on the value of 'User/Supervisor' bit in PTE that describes the
target page. Please note that the value of this bit in itself has nothing to
do with numerical value of the target address. It somehow happens that
Windows sets PTEs in such way that all addresses above 0x80000000 are
unaccessible to non-privileged code (I assume 2G of kernel address space).
However, this is nothing more than just a convention - as long as you have an
access to the kernel address space can change it if you wish.

Therefore, even if ZwMapViewOfSection() returns the address below 0x80000000
if called in context of the system process, it still does not mean that it
may be accessed by non-privileged code - everything depends on how the system
sets up PTEs. Taking into consideration the fact that the system process does
not create any threads with separate values of CS register for the
privileged and non-privileged code, it just does not seem to make sense to
allow non-privileged code
to access these pages, due to the lack of any in context of a system process.
This is why I reminded Mark that a system process is just a collection of
system's kernel-mode worker threads - the term " user mode portion of the
system process" would be meaningfull if and only if there was some
non-privileged code running in its context......

Anton Bassov

"Maxim S. Shatskih" wrote:

> > Since when does a system process has its representation in the user mode?
> Since NT4 at least. ZwMapViewOfSection works for System process in NT4, you can
> then access this memory from system thread context using __try/__except
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim...storagecraft.com
> http://www.storagecraft.com
>

> > ... which still does not mean that a system process has its
representation
> > in the user mode.
> It has user address space at least.
>

.........

> > Actually, the only reason why I argued with Mark's statement about " user
> > mode portion of the system process" is because the very term "user address
> > space" is meaningless when applied to system process .
> Absolutely wrong. I have the actual code which relies on it.

Please read my previous post carefully...

If the address returned by ZwMapViewOfSection() that got called in context
of a system process is below 0x80000000, it is still not enough to say that
it points to the "user address space", due to the lack of any in the system
process. It would be more appropriate to call it with the ridiculous term
"process-specific memory" - I think that PTEs are set up in such way that all
addresses below 0x80000000 in the address space of a system process are still
available only to the privileged code (due to the lack of non-privileged
one). Therefore, the term" user address space" just does not seem to apply
here - after all, if it was really a user address space, then Admins would be
able to open a handle to the system process with PROCESS_VM_OPERATION
flag.....

Anton Bassov

"Maxim S. Shatskih" wrote:

> > > Since NT4 at least. ZwMapViewOfSection works for System process in NT4,
> >you can
> > > then access this memory from system thread context using __try/__except
> >
> >
> > ... which still does not mean that a system process has its representation
> > in the user mode.
> It has user address space at least.
> What is really lacking is the ability to run code from it - system threads
> cannot cross kernel/user boundary, their KTHREAD/ETHREAD fields needed for
> "return to user" operation are not filled.
> > Actually, the only reason why I argued with Mark's statement about " user
> > mode portion of the system process" is because the very term "user address
> > space" is meaningless when applied to system process .
> Absolutely wrong. I have the actual code which relies on it.
> > Therefore, even if ZwMapViewOfSection() returns the address below
> >0x80000000
> > if called in context of the system process, it still does not mean that it
> > may be accessed by non-privileged code
> You cannot run user mode code in System process, correct.
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim...storagecraft.com
> http://www.storagecraft.com
>

Mark,

> Then we are having a definitional problem.

In fact, all commonly used definitions are a bit imprecise. You will see it
shortly

> I am talking about the
> per-process division of the system process's virtual memory into a
> shared and privileged segment commonly known as 'kernel address space'
> and a private non-shared (unless explicitly shared) segment commonly
> known across all processes as 'user address space'.

Actually, the above definition in itself is a bit imprecise as well, even as
far as "regular" processes (i.e. the ones with user-mode representation) are
concerned ....

Just to give you an idea, a pageable driver module that is loaded with
ZwSetSystemInformation() gets loaded only into caller's address space,
although it is a privileged module that is loaded above 0x80000000.
Therefore, we have to make a distinction between shared and non-shared kernel
address space...

> You may use some
> other term for that portion of a system process that is not within the
> shared kernel address space, what would you like to call it?

Actually, it probably makes sense to avoid terms "kernel" and "user"
altogether.
When it comes to code, we can refer to it as to ether privileged or
unprivileged,
and to use terms "user/supervisor vs superviser-only" and "shared vs
non-shared" (which gives us 4 possible combinations) in respect of data.
Apparenly, terms "kernel address space" and "user address space" are widely
used simply because shared superviser-only and non-shared user/supervisor are
the most common types of combinations, with the former mapped above
0x80000000 and the latter below 0x80000000, i.e. data mapping is done in a
way that coincides with the one privileged and unprivileged code segments are
mapped...

Anton Bassov

"Mark Roddy" wrote:

> Anton Bassov wrote:
> >> Since when does a system process has its representation in the user mode?
> >> Since NT4 at least. ZwMapViewOfSection works for System process in NT4, you can
> >> then access this memory from system thread context using __try/__except
> >
> >
> > ... which still does not mean that a system process has its representation
> > in the user mode.
> >
> >
> > Actually, the only reason why I argued with Mark's statement about " user
> > mode portion of the system process" is because the very term "user address
> > space" is meaningless when applied to system process . In order to understand
> > it, you have to recall some x86-specific features.
> >
> >
> > Strictly speaking, terms "kernel mode" and "user mode" apply only to the
> > code segment - privilege level of currently running code is defined by CS
> > register.
> Then we are having a definitional problem. I am talking about the
> per-process division of the system process's virtual memory into a
> shared and privileged segment commonly known as 'kernel address space'
> and a private non-shared (unless explicitly shared) segment commonly
> known across all processes as 'user address space'. You may use some
> other term for that portion of a system process that is not within the
> shared kernel address space, what would you like to call it? I prefer to
> call it 'the system process user mode address space' as that is pretty
> clear, if perhaps imprecise.
> A system process, like all processes, have both. The outside of the
> kernel region of the system process, which for lack of a better term I
> will call its 'user mode address space', clearly is not the same as the
> shared kernel region. It does not, for example (and for which reason it
> is interesting) use system ptes for mapping. I fail to see much
> functional difference between a system process user mode address space
> and a non-system process user mode address space. It is a private
> non-shared (unless explicitly shared) per process chunk of virtual
> memory that no other process can access.
>
> > As far as address space is concerned, a page can be accessible either to
> > both privileged and non-privileged code, or only to the privileged one - it
> > depends on the value of 'User/Supervisor' bit in PTE that describes the
> > target page. Please note that the value of this bit in itself has nothing to
> > do with numerical value of the target address. It somehow happens that
> > Windows sets PTEs in such way that all addresses above 0x80000000 are
> > unaccessible to non-privileged code (I assume 2G of kernel address space).
> > However, this is nothing more than just a convention - as long as you have an
> > access to the kernel address space can change it if you wish.
> >
> >
> > Therefore, even if ZwMapViewOfSection() returns the address below 0x80000000
> > if called in context of the system process, it still does not mean that it
> > may be accessed by non-privileged code - everything depends on how the system
> > sets up PTEs. Taking into consideration the fact that the system process does
> > not create any threads with separate values of CS register for the
> > privileged and non-privileged code, it just does not seem to make sense to
> > allow non-privileged code
> > to access these pages, due to the lack of any in context of a system process.
> > This is why I reminded Mark that a system process is just a collection of
> > system's kernel-mode worker threads - the term " user mode portion of the
> > system process" would be meaningfull if and only if there was some
> > non-privileged code running in its context......
> >
> > Anton Bassov
> >
> >
> >
> >
> >
> >
> > "Maxim S. Shatskih" wrote:
> >
> >> Since when does a system process has its representation in the user mode?
> >> Since NT4 at least. ZwMapViewOfSection works for System process in NT4, you can
> >> then access this memory from system thread context using __try/__except
> >>
> >> --
> >> Maxim Shatskih, Windows DDK MVP
> >> StorageCraft Corporation
> >> maxim...storagecraft.com
> >> http://www.storagecraft.com
> >>
> >>
>

Pavel,

And how does the system mark access rights in PTEs that describe target
pages? Are they for user/supervisor access or for supervisor only? In my
experience, you cannot get a handle to the system process for
PROCESS_VM_OPERATION from the user mode, regardless of user privilege level,
which seems to be the case not only under Vista but under pre-Vista OS
versions as well...

> You can try this on XP:
> C:\Debuggers>cdb -pvr -pn system

Well, actually, this output alone does not prove that you can open a handle
for PROCESS_VM_OPERATION from the user mode - after all, the debugger may
obtain the sought info right from the kernel through a helper driver
that it accesses with CreateFile(). Apparently, this is how it works behind
the scenes - otherwise, how would you dump contents of the local host's
kernel structures when you run dd command?

Anton Bassov

"Pavel Lebedinsky [MSFT]" wrote:

> "Anton Bassov" wrote:
> > If the address returned by ZwMapViewOfSection() that got called in context
> > of a system process is below 0x80000000, it is still not enough to say
> > that
> > it points to the "user address space", due to the lack of any in the
> > system
> > process. It would be more appropriate to call it with the ridiculous term
> > "process-specific memory" - I think that PTEs are set up in such way that
> > all
> > addresses below 0x80000000 in the address space of a system process are
> > still
> > available only to the privileged code (due to the lack of non-privileged
> > one). Therefore, the term" user address space" just does not seem to apply
> > here - after all, if it was really a user address space, then Admins would
> > be
> > able to open a handle to the system process with PROCESS_VM_OPERATION
> > flag.....
> Yes, and before Vista this actually works, even though it's probably
> not supported, can destroy your system, etc. You can try this on XP:
> C:\Debuggers>cdb -pvr -pn system
> 0:000> !vadump
> BaseAddress: 7c900000
> RegionSize: 00001000
> State: 00001000 MEM_COMMIT
> Protect: 00000002 PAGE_READONLY
> Type: 01000000 MEM_IMAGE
> 0:000> dc 7c900000
> 7c900000 00905a4d 00000003 00000004 0000ffff MZ...........
> 7c900010 000000b8 00000000 00000040 00000000 ...............
> 7c900020 00000000 00000000 00000000 00000000 ............
> 7c900030 00000000 00000000 00000000 000000e0 ............
> 7c900040 0eba1f0e cd09b400 4c01b821 685421cd ......!..L.!Th
> 7c900050 70207369 72676f72 63206d61 6f6e6e61 is program canno
> 7c900060 65622074 6e757220 206e6920 20534f44 t be run in DOS
> 7c900070 65646f6d 0a0d0d2e 00000024 00000000 mode...$......
> On Vista this fails with access denied (even when running elevated
> and with SeDebugPrivilege enabled), most likely because the system
> process is marked as protected.
> In any case, user address space in the system process works
> pretty much the same way as in any other process - it has
> VADs, most Mm syscalls work with it, etc. The term "user address
> space" still applies in this case; you can think of it as "address space
> below MmHighestUserAddress".
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>