Hi, I'm having problems with Mac users not being able toupload my web site that I designed usin...
By frank
Can I contribute a small TabindexIterator class for ZTUtils. It is notbig, but handy for generating ...
By davidpratt
Pavel Pokorny wrote:> Dear Mathematica friends> what is the reason Mathematica 5.2 does not co...
By daniel_lichtblau
Hello;This is Mathematica 5.1 on windows.This is a strange one.When I start Mathematica and typeZTar...
By steve
Starting yesterday, everytime I go to go on the internetinstaed of the screen opening to the full sc...
By maisie
Christoph,How aboutDistribute[(a + b) ** c]a ** c + b ** cDavid Parkdjmp@earthlink.nethttp://home.ea...
By david_park
ylafon (AT) w3 (DOT) org changed: What |Removed |Added Status|NEW |RESLVED Resolution| |FIXED Additi...
By bugzilla
I am developing an USB installer for windows Me. The API used is 16-bit. So I used the Win ME DDK�...
By anonymous, 1 Comments
Hi, For our next AV product we would like to use the UAA (Universal Audio Architecture) HD (High Def...
By anonymous, 6 Comments
I have not used Zsyncer before, so please excuse me ifthis question is remedial. Would Zsyncer be a ...
By matthowell, 1 Comments
I want to only open a directory to read its security settings. I am of course in kernel mode , and I...
By anonymous, 1 Comments
I was just wondering if anyone knows of any good diagnostic software out there that will analyze win...
By ecpool, 1 Comments
Can anyone help me? For some reason my internet has slowed down in speed considerably. I've run...
By schellbl, 1 Comments
I received an eagerly awaited program on CD ROM. As I have tried to install, I have gotten:1. progra...
By kitnchuck, 3 Comments
Can some one help out how to set up a ZTP form to use a mailhost objectand send a email with the dat...
By georgakopoulosnicolas, 4 Comments
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
antonbassov | Tues, 20 May 2008 07:36:00 GMT |
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
usfinecats | Tues, 20 May 2008 07:36:00 GMT |
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 | Tues, 20 May 2008 07:38:00 GMT |
What I'm trying to accomplish is to make a temporary copy of an existing
file. In XP this worked fine, in Vista with the verifier on it pukes as
described earlier.
So it looks like what I will do is to create a buffer in kernel mode and
copy the mapped file into the buffer and then into the kernel. This does
sound inefficient, but is there an alternative?
--
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
>
usfinecats | Tues, 20 May 2008 07:39:00 GMT |
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.
mark | Tues, 20 May 2008 07:40:00 GMT |
> You get a section mapped into the user mode portion of the
> system process.
Since when does a system process has its representation in the user mode?
After all, this is just a collection of system's kernel-mode worker threads
(not be be confused with the collection of idle threads - System Idle
process internally it is also known as SYSTEM process, but its PID is zero,
and PID of the "real" system process is 4)
Anton Bassov
"Mark Roddy" wrote:
> 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.
>
antonbassov | Tues, 20 May 2008 07:41:00 GMT |
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
>
usfinecats | Tues, 20 May 2008 07:42:00 GMT |
> 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
maxim | Tues, 20 May 2008 07:43:00 GMT |
> > 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
>
antonbassov | Tues, 20 May 2008 07:44:00 GMT |
> > 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
maxim | Tues, 20 May 2008 07:45:00 GMT |
> > ... 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
>
antonbassov | Tues, 20 May 2008 07:46:00 GMT |
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
>>
mark | Tues, 20 May 2008 07:47:00 GMT |
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
> >>
> >>
>
antonbassov | Tues, 20 May 2008 07:48:00 GMT |
"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.
pavel | Tues, 20 May 2008 07:49:00 GMT |
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.
>
>
antonbassov | Tues, 20 May 2008 07:50:00 GMT |
> And how does the system mark access rights in PTEs that describe target
> pages? Are they for user/supervisor access or for supervisor only?
Most (probably all?) are user-accessible (which is why cdb can read them
from user mode). You can check this from kd using !pte.
> 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?
I didn't dump any kernel structures, only some pages from the user part
of the address space. And cdb/ntsd don't use a driver - they simply call
OpenProcess. Let's run ntsd under cdb to confirm:
C:\Debuggers>cdb ntsd -pvr -pn system
0:000> bp kernel32!OpenProcess
0:000> g
Breakpoint 0 hit
kernel32!OpenProcess:
7c8309e1 mov edi,edi
0:000> dd esp
0007e948 0229a415 001f0fff 00000000 00000004
ProcessId is 4 (System)
0:000> gu
eax=000007bc
0:000> !handle 7bc f
Handle 7bc
Type Process
Attributes 0
GrantedAccess 0x1f0fff:
Delete,ReadControl,WriteDac,WriteOwner,Synch
Terminate,CreateThread,,VMOp,VMRead,VMWrite,DupHandle,CreateProcess,SetQuota,SetInfo,QueryInfo,SetPort
HandleCount 4
PointerCount 64
Name <none>
Object Specific Information
Process Id 4
Parent Process 0
Base Priority 8
GrantedAccess includes PROCESS_VM_OPERATION.
pavel | Tues, 20 May 2008 07:51:00 GMT |