Undocumented field in PEB?

[Jun Koi]

Hi,

I notice that in Windows Vista - and also Windows XP - there seems to
be an undocumented field in PEB.

>  From Windbg, I found some below fields in PEB
> structure' 
...
   +0x064 NumberOfProcessors : Uint4B
   +0x068 NtGlobalFlag     : Uint4B
   +0x070 CriticalSectionTimeout : _LARGE_INTEGER
...

We can see that NtGlobalFlag is at offset 0x68, and is 4 bytes field.
So the next field should be at 0x6C. However, CriticalSectionTimeout
is at 0x70.

- So the question is why that happens? I suspect that there is an
undocumented field after NtGlobalFlag, which is removed from the
debugging data. Any idea?

- Another thing: ReactOS now faithfully declares the PEB structure
like above, without that secret 4 bytes hole. As a result, the
ReactOS's PEB size is 4 bytes short than PEB structure in Windows. Do
we need to care about that? Or not?

Thanks,
J

[Alex Ionescu]

There is nothing "undocumented". LARGE_INTEGER is 8 bytes long and  
alignment padding is 8 bytes on x86.

On 6-Mar-09, at 2:46 AM, Jun Koi wrote:

>   Hi,
>
>  I notice that in Windows Vista - and also Windows XP - there seems to
>  be an undocumented field in PEB.
>
> >   From Windbg, I found some below fields in PEB
> > structure' 
>  ...
>  +0x064 NumberOfProcessors : Uint4B
>  +0x068 NtGlobalFlag     : Uint4B
>  +0x070 CriticalSectionTimeout : _LARGE_INTEGER
>  ...
>
>  We can see that NtGlobalFlag is at offset 0x68, and is 4 bytes field.
>  So the next field should be at 0x6C. However, CriticalSectionTimeout
>  is at 0x70.
>
>  - So the question is why that happens? I suspect that there is an
>  undocumented field after NtGlobalFlag, which is removed from the
>  debugging data. Any idea?
>
>  - Another thing: ReactOS now faithfully declares the PEB structure
>  like above, without that secret 4 bytes hole. As a result, the
>  ReactOS's PEB size is 4 bytes short than PEB structure in Windows. Do
>  we need to care about that? Or not?
>
>  Thanks,
>  J
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
Best regards,
Alex Ionescu

[Jun Koi]

On Fri, Mar 6, 2009 at 5:13 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   There is nothing "undocumented".
> LARGE_INTEGER is 8 bytes long and
>  alignment padding is 8 bytes on x86. 
I still dont understand your idea. This has nothing to do with how
large LARGE_INTERGER is, AFAICT.

Lets see again: NtGlobalFlag is 4 bytes, and it starts at 0x68. So the
next field should start at 0x68 + 4 = 0x6C.

But in fact the next field  (CriticalSectionTimeout) starts at 0x70.
No matter how big it is, we  actually dont care - because it is the
next field.

The question is: what is in the hole 0x68 -> 0x70 ? (that is 4 bytes)

Thanks,
J

>  
>  On 6-Mar-09, at 2:46 AM, Jun Koi wrote:
>
> >   Hi,
> >
> >  I notice that in Windows Vista - and also Windows XP - there seems to
> >  be an undocumented field in PEB.
> >
> > >   From Windbg, I found some below fields in PEB
> > > structure' 
> >  ...
> >  +0x064 NumberOfProcessors : Uint4B
> >  +0x068 NtGlobalFlag     : Uint4B
> >  +0x070 CriticalSectionTimeout : _LARGE_INTEGER
> >  ...
> >
> >  We can see that NtGlobalFlag is at offset 0x68, and is 4 bytes field.
> >  So the next field should be at 0x6C. However, CriticalSectionTimeout
> >  is at 0x70.
> >
> >  - So the question is why that happens? I suspect that there is an
> >  undocumented field after NtGlobalFlag, which is removed from the
> >  debugging data. Any idea?
> >
> >  - Another thing: ReactOS now faithfully declares the PEB structure
> >  like above, without that secret 4 bytes hole. As a result, the
> >  ReactOS's PEB size is 4 bytes short than PEB structure in Windows. Do
> >  we need to care about that? Or not?
> >
> >  Thanks,
> >  J
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  Best regards,
>  Alex Ionescu
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[KJK::Hyperion]

Jun Koi wrote:
>   But in fact the next field  (CriticalSectionTimeout)
> starts at 0x70.
>  No matter how big it is, we  actually dont care 
the size doesn't matter, but the alignment does (which, in the case of
long long on Windows, matches its size, i.e. 8). 0x6C is not a multiple
of 8, and the smallest multiple of 8 that's higher than 0x6C is 0x70

[Jun Koi]

On Fri, Mar 6, 2009 at 6:50 PM, KJK::Hyperion <hackbunny(a)reactos.org> wrote:
>   Jun Koi wrote:
> >   But in fact the next field
> >  (CriticalSectionTimeout) starts at 0x70.
> >  No matter how big it is, we  actually dont care 
>  the size doesn't matter, but the alignment does (which, in the case of
>  long long on Windows, matches its size, i.e. 8). 0x6C is not a multiple
>  of 8, and the smallest multiple of 8 that's higher than 0x6C is 0x70
>  
Now I see the reason.

But my question then is: how to make gcc automatically align
LARGER_INTEGER fields on 8 bytes like that?

I write a small test code with the NDK headers, and compile with gcc.
The result binary put CriticalSectionTimeout at 0x6C, not at 0x70.

Because ReactOS can be compiled with gcc, I guess there is an option
for gcc to do that. But I looked around for a while to no avail.

Anybody please enlighten me?

Thanks,
J


>   _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Dmitry Gorbachev]

Jun Koi writes:

>   Because ReactOS can be compiled with gcc, I guess
> there is an option
>  for gcc to do that. But I looked around for a while to no avail. 
Probably -mms-bitfields option. ReactOS is compiling with MinGW GCC, and no 
any special options are needed.

[Jun Koi]

On Fri, Mar 6, 2009 at 5:13 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   There is nothing "undocumented".
> LARGE_INTEGER is 8 bytes long and
>  alignment padding is 8 bytes on x86.
>  
I think you mean the next field must be aligned to 8 bytes. But why
really gcc doesnt think so, as it still reports that the next field
starts at 0x6C.

Or I must tell gcc to automatically pad that? Which option should I use for gcc?

Thanks,
J




>   On 6-Mar-09, at 2:46 AM, Jun Koi wrote:
>
> >   Hi,
> >
> >  I notice that in Windows Vista - and also Windows XP - there seems to
> >  be an undocumented field in PEB.
> >
> > >   From Windbg, I found some below fields in PEB
> > > structure' 
> >  ...
> >  +0x064 NumberOfProcessors : Uint4B
> >  +0x068 NtGlobalFlag     : Uint4B
> >  +0x070 CriticalSectionTimeout : _LARGE_INTEGER
> >  ...
> >
> >  We can see that NtGlobalFlag is at offset 0x68, and is 4 bytes field.
> >  So the next field should be at 0x6C. However, CriticalSectionTimeout
> >  is at 0x70.
> >
> >  - So the question is why that happens? I suspect that there is an
> >  undocumented field after NtGlobalFlag, which is removed from the
> >  debugging data. Any idea?
> >
> >  - Another thing: ReactOS now faithfully declares the PEB structure
> >  like above, without that secret 4 bytes hole. As a result, the
> >  ReactOS's PEB size is 4 bytes short than PEB structure in Windows. Do
> >  we need to care about that? Or not?
> >
> >  Thanks,
> >  J
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  Best regards,
>  Alex Ionescu
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>