address space

hello folks,

  1. on 32bit windows, even if we have < 4gb installed, would kernel processes
    get a virtual memory address of >2gb? is the mapping start addrss constant
    for usr and kernel? that is kernel space will always start at 0x80000000
    unless /3gb switch is specified?

  2. how do these values change for 64bit? what are the defaults for user and
    kernel?

  3. since the /3gb switch is meaningless can we change the defaults for
    winxp64 and vista?

thx

-B

  1. on 32bit windows, even if we have < 4gb installed, would kernel processes get a virtual memory address of >2gb?

>isn’t this obvious. Where exactly the doubt is?

following is the table given in win internals.

Table 7-10. The 64-Bit Address Space Sizes

Region IA-64 x64 x86

Process Address Space 7152 GB 8192 GB 2 to 3 GB

System PTE Space 128 GB 128 GB 1.2 GB

System Cache 128 GB 128 GB 960 MB

Paged Pool 128 GB 128 GB 470 to 650 MB

Nonpaged Pool 128GB 128 GB 256 MB

and the start of system address is being mentioned as FFFF080000000000

Aditya

Standard preamble - you shouldn’t rely on any of the information you
seek in a commercial product.

Supplemental preamble - unless you’re doing something way, way out
there, you really shouldn’t need to rely on any of it either.

What are you looking to do here exactly? If you’re just trying to
configure the address space layout as a goal in and of itself, there may
(or may not) be ways to do that using admin tools; I really don’t know.
If you’re planning to use this information to configure the kernel to
work with a driver you’re writing, then if you tell us what you’re
trying to accomplish, then we might be able to provide a better way to
achieve that goal, because this seems like the sort of thing that might
break a lot of things.

  1. The highest user address is stored in MmHighestUserAddress. It is
    exported, so if you really want to do anything with this information, at
    least get the value from here rather than relying on what the defaults
    appear to be.

In general, you might want to take a look at the ‘Memory Mangement’
chapter of ‘Windows Internals,’ as well as take a look at the variables
(among other things) that ‘x nt!Mm*Address*’ produces.

  1. I have no idea. There may be a good reason to change the defaults,
    but there is definitely not a good one to use them for anything, whether
    or not they are constant.

  2. I’m not really sure what you mean here by ‘defaults.’ If you really
    wanted to prove a point, I suppose that in theory you could change
    MmHighestUserAddress and the values of some other variables and try roll
    your own rebasing, but that doesn’t seem like a high success proposition.

Good luck,

mm

Bedanto wrote:

hello folks,

  1. on 32bit windows, even if we have < 4gb installed, would kernel
    processes get a virtual memory address of >2gb? is the mapping start
    addrss constant for usr and kernel? that is kernel space will
    always start at 0x80000000 unless /3gb switch is specified?

  2. how do these values change for 64bit? what are the defaults for user
    and kernel?

  3. since the /3gb switch is meaningless can we change the defaults for
    winxp64 and vista?

thx

-B

thanks everyone for the ‘new year bash’ and answers :slight_smile:

martin,

i merely was trying to understand the layout, i didnt knw abt windows
internals book before ths thread.

thx

b

On Fri, Jan 2, 2009 at 6:36 AM, Martin O’Brien wrote:

> Standard preamble - you shouldn’t rely on any of the information you seek
> in a commercial product.
>
> Supplemental preamble - unless you’re doing something way, way out there,
> you really shouldn’t need to rely on any of it either.
>
> What are you looking to do here exactly? If you’re just trying to
> configure the address space layout as a goal in and of itself, there may (or
> may not) be ways to do that using admin tools; I really don’t know. If
> you’re planning to use this information to configure the kernel to work with
> a driver you’re writing, then if you tell us what you’re trying to
> accomplish, then we might be able to provide a better way to achieve that
> goal, because this seems like the sort of thing that might break a lot of
> things.
>
> 1. The highest user address is stored in MmHighestUserAddress. It is
> exported, so if you really want to do anything with this information, at
> least get the value from here rather than relying on what the defaults
> appear to be.
>
> In general, you might want to take a look at the ‘Memory Mangement’ chapter
> of ‘Windows Internals,’ as well as take a look at the variables (among other
> things) that ‘x nt!MmAddress’ produces.
>
> 2. I have no idea. There may be a good reason to change the defaults, but
> there is definitely not a good one to use them for anything, whether or not
> they are constant.
>
> 3. I’m not really sure what you mean here by ‘defaults.’ If you really
> wanted to prove a point, I suppose that in theory you could change
> MmHighestUserAddress and the values of some other variables and try roll
> your own rebasing, but that doesn’t seem like a high success proposition.
>
> Good luck,
>
> mm
>
>
> Bedanto wrote:
>
>> hello folks,
>> 1. on 32bit windows, even if we have < 4gb installed, would kernel
>> processes get a virtual memory address of >2gb? is the mapping start addrss
>> constant for usr and kernel? that is kernel space will always start at
>> 0x80000000 unless /3gb switch is specified?
>> 2. how do these values change for 64bit? what are the defaults for user
>> and kernel?
>> 3. since the /3gb switch is meaningless can we change the defaults for
>> winxp64 and vista?
>> thx
>> -B
>>
>
> —
> 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
>

Most people who ask this question are about to hang themselves. This is
because they think that they will be able to test a pointer for validity by
whether it falls on one side of the kernel-mode boundary or the other.

In reality, there is no validity test that is based on this. You need to
call MmProbe* or any of its cousins.

Imagine a user-mode application that wanted to subvert its security token.
I could craft a pointer that looked like it was from kernel-mode and pass it
to your driver. If your driver then uses that pointer, you’ll get whatever
happens to be at that address. An app can exploit this.

Now I don’t know whether this was your intent. But any thread which veers
into guessing whether a pointer is from kernel mode needs this disclaimer.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.


“Bedanto” wrote in message news:xxxxx@ntdev…
hello folks,

1. on 32bit windows, even if we have < 4gb installed, would kernel processes
get a virtual memory address of >2gb? is the mapping start addrss constant
for usr and kernel? that is kernel space will always start at 0x80000000
unless /3gb switch is specified?

2. how do these values change for 64bit? what are the defaults for user and
kernel?

3. since the /3gb switch is meaningless can we change the defaults for
winxp64 and vista?

thx

-B

Note that with /userva=, the split can be arbitrarily customized.

Why do you think that you need to know this? If you use the system-supplied probe functions, as you must for user mode pointers, then you’ll automatically support customized user/kernel address space splits.

? S


From: Bedanto
Sent: Friday, January 02, 2009 05:01
To: Windows System Software Devs Interest List
Subject: [ntdev] address space

hello folks,

1. on 32bit windows, even if we have < 4gb installed, would kernel processes get a virtual memory address of >2gb? is the mapping start addrss constant for usr and kernel? that is kernel space will always start at 0x80000000 unless /3gb switch is specified?

2. how do these values change for 64bit? what are the defaults for user and kernel?

3. since the /3gb switch is meaningless can we change the defaults for winxp64 and vista?

thx

-B
— 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

While we’re on the subject of address space, let me put a user-mode hat on
for a second. I’ve always mean to check this in a debugger, but somehow
never have.

If I’m running a 32-bit user mode app on x64 Windows, do I get a usable
user-mode addresss space of nearly 4 GB, since the kernel space is now much
higher? It seems like if an app works with the /3GB switch, it would work
with the address space expanded even more.

Jan

Table 7-10. The 64-Bit Address Space Sizes

Region IA-64 x64
x86

Process Address Space 7152 GB 8192 GB 2 to 3 GB

System PTE Space 128 GB 128 GB 1.2 GB

System Cache 128 GB 128 GB 960 MB

Paged Pool 128 GB 128 GB
470 to 650 MB

Nonpaged Pool 128GB 128 GB 256 MB

Yes, if the main process image was linked with /LARGEADDRESSAWARE:YES, then allocations in such a Wow64 process can go up to 4GB. Note that, of course, some fixed-address bits like SHARED_USER_DATA remain at around 2GB, so you won’t get that much *contiguous* address space.

? S

-----Original Message-----
From: Jan Bottorff
Sent: Friday, January 02, 2009 14:40
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] address space

While we’re on the subject of address space, let me put a user-mode hat on
for a second. I’ve always mean to check this in a debugger, but somehow
never have.

If I’m running a 32-bit user mode app on x64 Windows, do I get a usable
user-mode addresss space of nearly 4 GB, since the kernel space is now much
higher? It seems like if an app works with the /3GB switch, it would work
with the address space expanded even more.

Jan

> Table 7-10. The 64-Bit Address Space Sizes
>
> Region IA-64 x64
> x86
>
> Process Address Space 7152 GB 8192 GB 2 to 3 GB
>
> System PTE Space 128 GB 128 GB 1.2 GB
>
> System Cache 128 GB 128 GB 960 MB
>
> Paged Pool 128 GB 128 GB
> 470 to 650 MB
>
> Nonpaged Pool 128GB 128 GB 256 MB
>


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

If you are running a 32-bit OS with /3GB, you can get 3GB of user space, but
ONLY if you have linked your executable with the /LARGEADDRESSAWARE linker
option. You can retroactively fix this using the imgcfg utility
imgcfg -l whatever.exe

Where the flag is hyphen-lower-case-L (hard to tell depending on what font
you have selected to read this)

In Win64, this will allow you to get nearly the whole 4GB of user-visible
address space when a 32-bit app runs.

A 32-bit app which is not LARGEADDRESSAWARE will only get 2GB of user space
no matter how much is potentially available.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Friday, January 02, 2009 5:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] address space

While we’re on the subject of address space, let me put a user-mode hat on
for a second. I’ve always mean to check this in a debugger, but somehow
never have.

If I’m running a 32-bit user mode app on x64 Windows, do I get a usable
user-mode addresss space of nearly 4 GB, since the kernel space is now much
higher? It seems like if an app works with the /3GB switch, it would work
with the address space expanded even more.

Jan

Table 7-10. The 64-Bit Address Space Sizes

Region IA-64 x64
x86

Process Address Space 7152 GB 8192 GB 2 to 3 GB

System PTE Space 128 GB 128 GB 1.2 GB

System Cache 128 GB 128 GB 960 MB

Paged Pool 128 GB 128 GB
470 to 650 MB

Nonpaged Pool 128GB 128 GB 256 MB


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


This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.