cr3 contains junk??

NTDEV
1

hi all,

we have a driver that extends the root enumerator bus and creates it’s own
device. to test this driver we have written a win32 command line application
which sends down IOCTLS. We observe that when ever thisapp runs, the cr3
registers values are completely bogus (please excuse the term bogus, it
might be a justifed value, which I cannot decode). when ever the app
termnates, cr3 is restored ot the correct value we expect.

is there something with command line apps that does this?

thanks

ap

2

> We observe that when ever thisapp runs, the cr3 registers values are

completely bogus

What do you mean by “bogus”? What kind of problem are you seeing that you
think relates to the CR3 register?

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“A P” wrote in message news:xxxxx@ntdev…
hi all,

we have a driver that extends the root enumerator bus and creates it’s own
device. to test this driver we have written a win32 command line application
which sends down IOCTLS. We observe that when ever thisapp runs, the cr3
registers values are completely bogus (please excuse the term bogus, it
might be a justifed value, which I cannot decode). when ever the app
termnates, cr3 is restored ot the correct value we expect.

is there something with command line apps that does this?

thanks

ap

3

no bogus was not the right word for this…after reading up, i see that
windows in app mod sets this value to the dr base addr for the add so that
the app boundary remains intact.

but once sysenter happens, and i view the vslue of cr3 in kernel mode,
should n’t i be seeing the actual cr3 value ?

thanks

ap

On Wed, Jul 22, 2009 at 7:09 PM, Scott Noone wrote:

> > We observe that when ever thisapp runs, the cr3 registers values are
> > completely bogus
>
> What do you mean by “bogus”? What kind of problem are you seeing that you
> think relates to the CR3 register?
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> “A P” wrote in message news:xxxxx@ntdev…
> hi all,
>
> we have a driver that extends the root enumerator bus and creates it’s own
> device. to test this driver we have written a win32 command line
> application
> which sends down IOCTLS. We observe that when ever thisapp runs, the cr3
> registers values are completely bogus (please excuse the term bogus, it
> might be a justifed value, which I cannot decode). when ever the app
> termnates, cr3 is restored ot the correct value we expect.
>
> is there something with command line apps that does this?
>
> thanks
>
> ap
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

4

Why are you groveling around in cr3 with a driver? What are you attempting to accomplish, here?

  • S

From: A P
Sent: Wednesday, July 22, 2009 06:36
To: Windows System Software Devs Interest List
Subject: [ntdev] cr3 contains junk??

hi all,

we have a driver that extends the root enumerator bus and creates it’s own device. to test this driver we have written a win32 command line application which sends down IOCTLS. We observe that when ever thisapp runs, the cr3 registers values are completely bogus (please excuse the term bogus, it might be a justifed value, which I cannot decode). when ever the app termnates, cr3 is restored ot the correct value we expect.

is there something with command line apps that does this?

thanks

ap
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

Ignoring all real details, the CR3 register contains the physical address of
the base of the virtual memory management tables for the process. But, the
O/S is in charge of all this and it should really be transparent to your
driver.

The question really is what led you to start looking at CR3…

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“A P” wrote in message news:xxxxx@ntdev…
no bogus was not the right word for this…after reading up, i see that
windows in app mod sets this value to the dr base addr for the add so that
the app boundary remains intact.

but once sysenter happens, and i view the vslue of cr3 in kernel mode,
should n’t i be seeing the actual cr3 value ?

thanks

ap

On Wed, Jul 22, 2009 at 7:09 PM, Scott Noone wrote:

> We observe that when ever thisapp runs, the cr3 registers values are
> completely bogus

What do you mean by “bogus”? What kind of problem are you seeing that you
think relates to the CR3 register?

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“A P” wrote in message news:xxxxx@ntdev…

hi all,

we have a driver that extends the root enumerator bus and creates it’s own
device. to test this driver we have written a win32 command line application
which sends down IOCTLS. We observe that when ever thisapp runs, the cr3
registers values are completely bogus (please excuse the term bogus, it
might be a justifed value, which I cannot decode). when ever the app
termnates, cr3 is restored ot the correct value we expect.

is there something with command line apps that does this?

thanks

ap

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

AP, you lost me here.

Snoone has already asked the most important question - why do you care - but I’m also wondering how you’re monitoring the value of cr3 and what values are you reading.

mm

7

A P wrote:

no bogus was not the right word for this…after reading up, i see that
windows in app mod sets this value to the dr base addr for the add so
that the app boundary remains intact.

but once sysenter happens, and i view the vslue of cr3 in kernel mode,
should n’t i be seeing the actual cr3 value ?

How are you “viewing” the value of CR3? In a debugger? CR3 contains
the physical address of the page directory, and that physical address
might change at every task switch.

And, parroting what Scott said, why on earth do you care?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

> i see that windows in app mod sets this value to the dr base addr for the add

Perhaps you should look better - accessing control register is a privileged operation, so that it just cannot be modified by the UM code under ANY OS…

Anton Bassov

9

answering all of your questions below:

No I don’t care about the value of cr3, it is just that I wanted to
understand how things are working in more detail. So I expected, that when
the user process makes a transition to kernel mode, the value of cr3 should
be changed to the respective kernel mode ones. But this i what I do not see,
ofcourse everything works like clock work, making me ore curios as to how it
is working if cr3 still has tland process spcific value.

How I saw cr3? well in windbg, i do a rcr3 to get the adress. the address
contains the user mode address. Also, I use !dc to view physical memory. and
!vtp to convert virtual addresses to physical ones.

Thanks

ap

On Thu, Jul 23, 2009 at 12:41 AM, wrote:

> > i see that windows in app mod sets this value to the dr base addr for the
> add
>
> Perhaps you should look better - accessing control register is a
> privileged operation, so that it just cannot be modified by the UM code
> under ANY OS…
>
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

10

No, cr3 doesn?t need to swap for a user to kernel transition on x86 and amd64. If you grab your local handy copy of the Intel manuals (which, last time I checked, Intel was happy to send you hardcopies for free if you managed to navigate their website to the right spot), there?s a user/supervisor bit (!pte calls it the user/kernel or owner bit) that controls what privilege level (CPL) is necessary to access a page.

That is the mechanism by which NT on x86 and amd64 currently protects kernel memory from user mode, not by simply making it inaccessible by providing a separate paging structure stack.

  • S

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of A P
Sent: Wednesday, July 22, 2009 9:11 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] cr3 contains junk??

answering all of your questions below:

No I don’t care about the value of cr3, it is just that I wanted to understand how things are working in more detail. So I expected, that when the user process makes a transition to kernel mode, the value of cr3 should be changed to the respective kernel mode ones. But this i what I do not see, ofcourse everything works like clock work, making me ore curios as to how it is working if cr3 still has tland process spcific value.

How I saw cr3? well in windbg, i do a rcr3 to get the adress. the address contains the user mode address. Also, I use !dc to view physical memory. and !vtp to convert virtual addresses to physical ones.

Thanks

ap
On Thu, Jul 23, 2009 at 12:41 AM, > wrote:
> i see that windows in app mod sets this value to the dr base addr for the add
Perhaps you should look better - accessing control register is a privileged operation, so that it just cannot be modified by the UM code under ANY OS…

Anton Bassov

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

11

>more detail. So I expected, that when the user process makes a transition to kernel mode, the value of

cr3 should be changed to the respective kernel mode ones.

There is no such thing as “kernel-mode DirBase”, the process’s DirBase is the same regardless of whether its thread runs in kernel mode or user mode.

There is a System process though, but this is another song.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

12

A P wrote:

No I don’t care about the value of cr3, it is just that I wanted to
understand how things are working in more detail. So I expected, that
when the user process makes a transition to kernel mode, the value of
cr3 should be changed to the respective kernel mode ones. But this i
what I do not see, ofcourse everything works like clock work, making
me ore curios as to how it is working if cr3 still has tland process
spcific value.

Because you’re still in the process context. Remember that the kernel
space (0x80000000 and up, on a default Win32 system) lives in ALL
processes. There is not a separate page directory for kernel mode,
because the kernel pages live in ALL of the page directories. The only
thing that changes from process to process is the user space.

If this were not the case, how could a kernel driver access buffers in
the user process?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

13

Tim Roberts wrote:

…There is not a separate page directory for kernel mode,
because the kernel pages live in ALL of the page directories. The only
thing that changes from process to process is the user space.

If this were not the case, how could a kernel driver access buffers in
the user process?

(By the way, this was a rhetorical question. It is not necessary to
reply with suggestions for operating system designs that would permit
this; such designs clearly ARE possible.)

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.