On Memory Allocation routines

NTDEV
1

Hi All,
I have some doubts on the memory allocation routines, especially
ExAllocatePoolWithTag. Hope some one here could help me in getting an
anwswer for them. I sent this message to Windbg first, sending to this group
since I think this would be the better place.

Suppose that i have a structure with a size of 18 bytes. Documentation of
ExAllocatePoolWithTag says that it will align all the request at an 8 byte
boundary. And thru the debugger Iam able to see that all succesfull
allocations return an address that is divisible by 8. So What happens to the
remaining 7 bytes in this case? The next succesfull allocation would then be
aligned at a minimum differnce of 7 bytes from the end of my allocation,
right? What happens in case of a memory overrun of less than 7 bytes ? From
the documenation of Driver verifier i believe that, i wouldnt be able to
catch that becasue of the same isse ? Verifier special pool will try to
allocate the memory request from the lowest possible 8 byte aligned address
that will fit my request and then put an invalid page and then mark the
previous and next page inaccessible. And from what i understand, it still
wont be able to able to detect overrun less that 7 bytes in this specific
case, right ? Or is it that the remaining 7 bytes can also be counted to be
part of my allocation? But in that case why in this case sizeof operator
would give me 18 bytes and not 24 bytes? So though not recommended, would it
be okay to ignore overruns that comply with this ?

My second doubt is regarding Tags used along with? The four byte tag is
seens prior to the returned address, and the start of the tag doesnt seem to
be 8 byte aligned. Then how is this done? How do applications like poolmon
identify whether the allocations contains a valid tag or not?

Thanking you in advance
Anees

Screensavers unlimited! Funny, serious, religious.
http://www.msn.co.in/Cinema/screensaver/ Take your pick!

2

C’s sizeof() has no idea about alignment in the OS. sizeof() will
return the structure size, not the alignment size that the os maintains
on an allocation.

All allocations are of a minimum size. The remaining bytes (7 in your
case) are burned and left unused until you free the memory. When
verifier runs, the OS puts a pattern in the remaining bytes. When you
free the memory, the pattern is checked. If you overran your buffer,
the expected pattern is not present.

Where the tag lives does not matter in terms of alignment. Just b/c the
OS returns an allocation at an 8 byte aligment, it does not mean that
internally the alignment is 8 bytes. The external alignment is not
necessarily the internal alignment. Poolmon knows how to find the
allocations b/c it is understands the internals how allocations are
tracked, not by the alignment of a buffer.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of anees mannessery
Sent: Thursday, November 11, 2004 9:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] On Memory Allocation routines

Hi All,
I have some doubts on the memory allocation routines, especially
ExAllocatePoolWithTag. Hope some one here could help me in getting an
anwswer for them. I sent this message to Windbg first, sending to this
group
since I think this would be the better place.

Suppose that i have a structure with a size of 18 bytes. Documentation
of
ExAllocatePoolWithTag says that it will align all the request at an 8
byte
boundary. And thru the debugger Iam able to see that all succesfull
allocations return an address that is divisible by 8. So What happens to
the
remaining 7 bytes in this case? The next succesfull allocation would
then be
aligned at a minimum differnce of 7 bytes from the end of my allocation,

right? What happens in case of a memory overrun of less than 7 bytes ?
From
the documenation of Driver verifier i believe that, i wouldnt be able to

catch that becasue of the same isse ? Verifier special pool will try to
allocate the memory request from the lowest possible 8 byte aligned
address
that will fit my request and then put an invalid page and then mark the
previous and next page inaccessible. And from what i understand, it
still
wont be able to able to detect overrun less that 7 bytes in this
specific
case, right ? Or is it that the remaining 7 bytes can also be counted to
be
part of my allocation? But in that case why in this case sizeof operator

would give me 18 bytes and not 24 bytes? So though not recommended,
would it
be okay to ignore overruns that comply with this ?

My second doubt is regarding Tags used along with? The four byte tag is
seens prior to the returned address, and the start of the tag doesnt
seem to
be 8 byte aligned. Then how is this done? How do applications like
poolmon
identify whether the allocations contains a valid tag or not?

Thanking you in advance
Anees

Screensavers unlimited! Funny, serious, religious.
http://www.msn.co.in/Cinema/screensaver/ Take your pick!

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

> allocations return an address that is divisible by 8. So What happens to the

remaining 7 bytes in this case?

Unused padding.

My second doubt is regarding Tags used along with? The four byte tag is
seens prior to the returned address, and the start of the tag doesnt seem to
be 8 byte aligned.

So what? Why this is strange for you? Tag is the last word of 16byte (IIRC)
pool header.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

4

Hi Doran,

Thanx for the info.

But from the verifier documentation provided along with DDK help, it talks
about filling special patterns on previous portions of the page and not
about the last bytes. Also, in my case verifier special pool option didnt
catch an overrun of 1 byte. This is why i got confused on.

-Anees
-----Original Message-----
From: Doron Holan
Reply To: “Windows System Software Devs Interest List”
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] On Memory Allocation routines
Sent: Friday, November 12, 2004 6:27:53 AM
C’s sizeof() has no idea about alignment in the OS. sizeof() will
return the structure size, not the alignment size that the os maintains
on an allocation.

All allocations are of a minimum size. The rematining bytes (7 in your
case) are burned and left unused until you free the memory. When
verifier runs, the OS puts a pattern in the remaining bytes. When you
free the memory, the pattern is checked. If you overran your buffer,
the expected pattern is not present.

Where the tag lives does not matter in terms of alignment. Just b/c the
OS returns an allocation at an 8 byte aligment, it does not mean that
internally the alignment is 8 bytes. The external alignment is not
necessarily the internal alignment. Poolmon knows how to find the
allocations b/c it is understands the internals how allocations are
tracked, not by the alignment of a buffer.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of anees mannessery
Sent: Thursday, November 11, 2004 9:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] On Memory Allocation routines

Hi All,
I have some doubts on the memory allocation routines, especially
ExAllocatePoolWithTag. Hope some one here could help me in getting an
anwswer for them. I sent this message to Windbg first, sending to this
group
since I think this would be the better place.

Suppose that i have a structure with a size of 18 bytes. Documentation
of
ExAllocatePoolWithTag says that it will align all the request at an 8
byte
boundary. And thru the debugger Iam able to see that all succesfull
allocations return an address that is divisible by 8. So What happens to
the
remaining 7 bytes in this case? The next succesfull allocation would
then be
aligned at a minimum differnce of 7 bytes from the end of my allocation,

right? What happens in case of a memory overrun of less than 7 bytes ?
From
the documenation of Driver verifier i believe that, i wouldnt be able to

catch that becasue of the same isse ? Verifier special pool will try to
allocate the memory request from the lowest possible 8 byte aligned
address
that will fit my request and then put an invalid page and then mark the
previous and next page inaccessible. And from what i understand, it
still
wont be able to able to detect overrun less that 7 bytes in this
specific
case, right ? Or is it that the remaining 7 bytes can also be counted to
be
part of my allocation? But in that case why in this case sizeof operator

would give me 18 bytes and not 24 bytes? So though not recommended,
would it
be okay to ignore overruns that comply with this ?

My second doubt is regarding Tags used along with? The four byte tag is
seens prior to the returned address, and the start of the tag doesnt
seem to
be 8 byte aligned. Then how is this done? How do applications like
poolmon
identify whether the allocations contains a valid tag or not?

Thanking you in advance
Anees

_________________________________________________________________
Instant personal loans. Celebrate this season with your family.
http://acm.bridgeovertw.com/hdfc/pl/landingpage/sep04/index.htm?sitecode=611|395
Apply.

5

This is from memory, based on a presentation at the Driver Developers
conference about a year ago, so if someone says different from microsoft,
it’s obviously their code and they know better than me…

When using special pool in driver verifier, small allocations (less than
one page in size) will be done as follows:

  1. Allocate one page for the allocation. Make sure that page before and
    after are “unavailable”.
  2. Place the allocation at the end of the page, whilst still maintaining
    correct alignment for the allocation.
  3. Fill unused space on either side of the actual allocated memory with a
    pseudo-random selected byte.

Freeing will check the pattern around the allocation is the expected
pattern.

It is possible for a single or multibyte write outside the allocation to be
undetected for a particular allocation because it’s actually by coincident
the same pattern as the pseudo-random number.

But in general, a single byte overwrite should be detected. However, only
once you try to free the block!

Overwrites that go past the end of the page (either side) will be caught
immediately, since that’s not an available page, and will page-fault
immediately.

You should be able to check this using the debugger, just check the data
pattern after the memory you got back when calling the KeAllocatePoolXXXX.
You should see that the data around your area is filled with a pattern…

I think larger allocations than a page is just starting at one page, then
fill with pattern 'til the end of the last page, and check the pattern on
free. I also think you get a “guard-page” around it, but I’m not sure about
that.

–
Mats
xxxxx@lists.osr.com wrote on 11/16/2004 01:49:13 PM:

Hi Doran,

Thanx for the info.

But from the verifier documentation provided along with DDK help, it
talks
about filling special patterns on previous portions of the page and not
about the last bytes. Also, in my case verifier special pool option didnt

catch an overrun of 1 byte. This is why i got confused on.

-Anees
-----Original Message-----
From: Doron Holan
> Reply To: “Windows System Software Devs Interest List”

> To: “Windows System Software Devs Interest List”
> Subject: RE: [ntdev] On Memory Allocation routines
> Sent: Friday, November 12, 2004 6:27:53 AM
> C’s sizeof() has no idea about alignment in the OS. sizeof() will
> return the structure size, not the alignment size that the os maintains
> on an allocation.
>
> All allocations are of a minimum size. The rematining bytes (7 in your
> case) are burned and left unused until you free the memory. When
> verifier runs, the OS puts a pattern in the remaining bytes. When you
> free the memory, the pattern is checked. If you overran your buffer,
> the expected pattern is not present.
>
> Where the tag lives does not matter in terms of alignment. Just b/c the
> OS returns an allocation at an 8 byte aligment, it does not mean that
> internally the alignment is 8 bytes. The external alignment is not
> necessarily the internal alignment. Poolmon knows how to find the
> allocations b/c it is understands the internals how allocations are
> tracked, not by the alignment of a buffer.
>
> d
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of anees mannessery
> Sent: Thursday, November 11, 2004 9:27 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] On Memory Allocation routines
>
> Hi All,
> I have some doubts on the memory allocation routines, especially
> ExAllocatePoolWithTag. Hope some one here could help me in getting an
> anwswer for them. I sent this message to Windbg first, sending to this
> group
> since I think this would be the better place.
>
> Suppose that i have a structure with a size of 18 bytes. Documentation
> of
> ExAllocatePoolWithTag says that it will align all the request at an 8
> byte
> boundary. And thru the debugger Iam able to see that all succesfull
> allocations return an address that is divisible by 8. So What happens to
> the
> remaining 7 bytes in this case? The next succesfull allocation would
> then be
> aligned at a minimum differnce of 7 bytes from the end of my allocation,
>
> right? What happens in case of a memory overrun of less than 7 bytes ?
> From
> the documenation of Driver verifier i believe that, i wouldnt be able to
>
> catch that becasue of the same isse ? Verifier special pool will try to
> allocate the memory request from the lowest possible 8 byte aligned
> address
> that will fit my request and then put an invalid page and then mark the
> previous and next page inaccessible. And from what i understand, it
> still
> wont be able to able to detect overrun less that 7 bytes in this
> specific
> case, right ? Or is it that the remaining 7 bytes can also be counted to
> be
> part of my allocation? But in that case why in this case sizeof operator
>
> would give me 18 bytes and not 24 bytes? So though not recommended,
> would it
> be okay to ignore overruns that comply with this ?
>
> My second doubt is regarding Tags used along with? The four byte tag is
> seens prior to the returned address, and the start of the tag doesnt
> seem to
> be 8 byte aligned. Then how is this done? How do applications like
> poolmon
> identify whether the allocations contains a valid tag or not?
>
> Thanking you in advance
> Anees
>
> _________________________________________________________________
> Instant personal loans. Celebrate this season with your family.
> http://acm.bridgeovertw.com/hdfc/pl/landingpage/sep04/index.htm?
> sitecode=611|395
> Apply.
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> ForwardSourceID:NT00007492

6

Thanks a lot Mats. That was indeed a detailed answer. I give a try with the
debugger to see what actually is going on. And that also means that enabling
special pool is really very costly,especially in case of enabling it for all
instaleld drivers.

Thanks
Anees

From: Mats PETERSSON
>Reply-To: “Windows System Software Devs Interest List”
>
>To: “Windows System Software Devs Interest List”
>Subject: RE: [ntdev] On Memory Allocation routines
>Date: Tue, 16 Nov 2004 15:21:10 +0000
>
>
>
>
>
>
>This is from memory, based on a presentation at the Driver Developers
>conference about a year ago, so if someone says different from microsoft,
>it’s obviously their code and they know better than me…
>
>When using special pool in driver verifier, small allocations (less than
>one page in size) will be done as follows:
>1. Allocate one page for the allocation. Make sure that page before and
>after are “unavailable”.
>2. Place the allocation at the end of the page, whilst still maintaining
>correct alignment for the allocation.
>3. Fill unused space on either side of the actual allocated memory with a
>pseudo-random selected byte.
>
>Freeing will check the pattern around the allocation is the expected
>pattern.
>
>It is possible for a single or multibyte write outside the allocation to be
>undetected for a particular allocation because it’s actually by coincident
>the same pattern as the pseudo-random number.
>
>But in general, a single byte overwrite should be detected. However, only
>once you try to free the block!
>
>Overwrites that go past the end of the page (either side) will be caught
>immediately, since that’s not an available page, and will page-fault
>immediately.
>
>You should be able to check this using the debugger, just check the data
>pattern after the memory you got back when calling the KeAllocatePoolXXXX.
>You should see that the data around your area is filled with a pattern…
>
>I think larger allocations than a page is just starting at one page, then
>fill with pattern 'til the end of the last page, and check the pattern on
>free. I also think you get a “guard-page” around it, but I’m not sure about
>that.
>
>–
>Mats
>xxxxx@lists.osr.com wrote on 11/16/2004 01:49:13 PM:
>
> > Hi Doran,
> >
> > Thanx for the info.
> >
> > But from the verifier documentation provided along with DDK help, it
>talks
> > about filling special patterns on previous portions of the page and not
> > about the last bytes. Also, in my case verifier special pool option
>didnt
>
> > catch an overrun of 1 byte. This is why i got confused on.
> >
> > -Anees
> > -----Original Message-----
> > From: Doron Holan
> > Reply To: “Windows System Software Devs Interest List”
>
> > To: “Windows System Software Devs Interest List”
> > Subject: RE: [ntdev] On Memory Allocation routines
> > Sent: Friday, November 12, 2004 6:27:53 AM
> > C’s sizeof() has no idea about alignment in the OS. sizeof() will
> > return the structure size, not the alignment size that the os maintains
> > on an allocation.
> >
> > All allocations are of a minimum size. The rematining bytes (7 in your
> > case) are burned and left unused until you free the memory. When
> > verifier runs, the OS puts a pattern in the remaining bytes. When you
> > free the memory, the pattern is checked. If you overran your buffer,
> > the expected pattern is not present.
> >
> > Where the tag lives does not matter in terms of alignment. Just b/c the
> > OS returns an allocation at an 8 byte aligment, it does not mean that
> > internally the alignment is 8 bytes. The external alignment is not
> > necessarily the internal alignment. Poolmon knows how to find the
> > allocations b/c it is understands the internals how allocations are
> > tracked, not by the alignment of a buffer.
> >
> > d
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of anees mannessery
> > Sent: Thursday, November 11, 2004 9:27 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] On Memory Allocation routines
> >
> > Hi All,
> > I have some doubts on the memory allocation routines, especially
> > ExAllocatePoolWithTag. Hope some one here could help me in getting an
> > anwswer for them. I sent this message to Windbg first, sending to this
> > group
> > since I think this would be the better place.
> >
> > Suppose that i have a structure with a size of 18 bytes. Documentation
> > of
> > ExAllocatePoolWithTag says that it will align all the request at an 8
> > byte
> > boundary. And thru the debugger Iam able to see that all succesfull
> > allocations return an address that is divisible by 8. So What happens to
> > the
> > remaining 7 bytes in this case? The next succesfull allocation would
> > then be
> > aligned at a minimum differnce of 7 bytes from the end of my allocation,
> >
> > right? What happens in case of a memory overrun of less than 7 bytes ?
> > From
> > the documenation of Driver verifier i believe that, i wouldnt be able to
> >
> > catch that becasue of the same isse ? Verifier special pool will try to
> > allocate the memory request from the lowest possible 8 byte aligned
> > address
> > that will fit my request and then put an invalid page and then mark the
> > previous and next page inaccessible. And from what i understand, it
> > still
> > wont be able to able to detect overrun less that 7 bytes in this
> > specific
> > case, right ? Or is it that the remaining 7 bytes can also be counted to
> > be
> > part of my allocation? But in that case why in this case sizeof operator
> >
> > would give me 18 bytes and not 24 bytes? So though not recommended,
> > would it
> > be okay to ignore overruns that comply with this ?
> >
> > My second doubt is regarding Tags used along with? The four byte tag is
> > seens prior to the returned address, and the start of the tag doesnt
> > seem to
> > be 8 byte aligned. Then how is this done? How do applications like
> > poolmon
> > identify whether the allocations contains a valid tag or not?
> >
> > Thanking you in advance
> > Anees
> >
> >
> > Instant personal loans. Celebrate this season with your family.
> > http://acm.bridgeovertw.com/hdfc/pl/landingpage/sep04/index.htm?
> > sitecode=611|395
> > Apply.
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> > ForwardSourceID:NT00007492
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
NRIs - Free money transfer to India. Fly to India for free!
http://acm.bridgeovertw.com/hdfc/qr/landingpage/sep04/index.htm?sitecode=610|394
Apply Now.

7

Yes, if you do lots of allocations and de-allocations, it’s going to be
quite a substantial loss of performance in the system. Also, enabling it
for “ALL drivers” is probably less than desirable, unless you’re actually
trying to find problems where some other driver is clobbering your data,
which hopefully isn’t something that happens too often…

Enable it for your driver, and any drivers that are in that chain. But for
instance, when I’m working on a displaydriver, I don’t REALLY need to get
the file-system drivers checked with special pool, as it’s UNLIKELY that
any of my data comes from the file system data (not without going through
some user-mode application, at least).

–
Mats

xxxxx@lists.osr.com wrote on 11/17/2004 09:01:54 AM:

Thanks a lot Mats. That was indeed a detailed answer. I give a try with
the
debugger to see what actually is going on. And that also means that
enabling
special pool is really very costly,especially in case of enabling it for
all
instaleld drivers.

Thanks
Anees

>From: Mats PETERSSON
> >Reply-To: “Windows System Software Devs Interest List”
> >
> >To: “Windows System Software Devs Interest List”
> >Subject: RE: [ntdev] On Memory Allocation routines
> >Date: Tue, 16 Nov 2004 15:21:10 +0000
> >
> >
> >
> >
> >
> >
> >This is from memory, based on a presentation at the Driver Developers
> >conference about a year ago, so if someone says different from
microsoft,
> >it’s obviously their code and they know better than me…
> >
> >When using special pool in driver verifier, small allocations (less than
> >one page in size) will be done as follows:
> >1. Allocate one page for the allocation. Make sure that page before and
> >after are “unavailable”.
> >2. Place the allocation at the end of the page, whilst still maintaining
> >correct alignment for the allocation.
> >3. Fill unused space on either side of the actual allocated memory with
a
> >pseudo-random selected byte.
> >
> >Freeing will check the pattern around the allocation is the expected
> >pattern.
> >
> >It is possible for a single or multibyte write outside the allocation to
be
> >undetected for a particular allocation because it’s actually by
coincident
> >the same pattern as the pseudo-random number.
> >
> >But in general, a single byte overwrite should be detected. However,
only
> >once you try to free the block!
> >
> >Overwrites that go past the end of the page (either side) will be caught
> >immediately, since that’s not an available page, and will page-fault
> >immediately.
> >
> >You should be able to check this using the debugger, just check the data
> >pattern after the memory you got back when calling the
KeAllocatePoolXXXX.
> >You should see that the data around your area is filled with a
pattern…
> >
> >I think larger allocations than a page is just starting at one page,
then
> >fill with pattern 'til the end of the last page, and check the pattern
on
> >free. I also think you get a “guard-page” around it, but I’m not sure
about
> >that.
> >
> >–
> >Mats
> >xxxxx@lists.osr.com wrote on 11/16/2004 01:49:13 PM:
> >
> > > Hi Doran,
> > >
> > > Thanx for the info.
> > >
> > > But from the verifier documentation provided along with DDK help, it
> >talks
> > > about filling special patterns on previous portions of the page and
not
> > > about the last bytes. Also, in my case verifier special pool option
> >didnt
> >
> > > catch an overrun of 1 byte. This is why i got confused on.
> > >
> > > -Anees
> > > -----Original Message-----
> > > From: Doron Holan
> > > Reply To: “Windows System Software Devs Interest List”
> >
> > > To: “Windows System Software Devs Interest List”

> > > Subject: RE: [ntdev] On Memory Allocation routines
> > > Sent: Friday, November 12, 2004 6:27:53 AM
> > > C’s sizeof() has no idea about alignment in the OS. sizeof() will
> > > return the structure size, not the alignment size that the os
maintains
> > > on an allocation.
> > >
> > > All allocations are of a minimum size. The rematining bytes (7 in
your
> > > case) are burned and left unused until you free the memory. When
> > > verifier runs, the OS puts a pattern in the remaining bytes. When
you
> > > free the memory, the pattern is checked. If you overran your buffer,
> > > the expected pattern is not present.
> > >
> > > Where the tag lives does not matter in terms of alignment. Just b/c
the
> > > OS returns an allocation at an 8 byte aligment, it does not mean that
> > > internally the alignment is 8 bytes. The external alignment is not
> > > necessarily the internal alignment. Poolmon knows how to find the
> > > allocations b/c it is understands the internals how allocations are
> > > tracked, not by the alignment of a buffer.
> > >
> > > d
> > >
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of anees
mannessery
> > > Sent: Thursday, November 11, 2004 9:27 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: [ntdev] On Memory Allocation routines
> > >
> > > Hi All,
> > > I have some doubts on the memory allocation routines, especially
> > > ExAllocatePoolWithTag. Hope some one here could help me in getting an
> > > anwswer for them. I sent this message to Windbg first, sending to
this
> > > group
> > > since I think this would be the better place.
> > >
> > > Suppose that i have a structure with a size of 18 bytes.
Documentation
> > > of
> > > ExAllocatePoolWithTag says that it will align all the request at an 8
> > > byte
> > > boundary. And thru the debugger Iam able to see that all succesfull
> > > allocations return an address that is divisible by 8. So What happens
to
> > > the
> > > remaining 7 bytes in this case? The next succesfull allocation would
> > > then be
> > > aligned at a minimum differnce of 7 bytes from the end of my
allocation,
> > >
> > > right? What happens in case of a memory overrun of less than 7 bytes
?
> > > From
> > > the documenation of Driver verifier i believe that, i wouldnt be able
to
> > >
> > > catch that becasue of the same isse ? Verifier special pool will try
to
> > > allocate the memory request from the lowest possible 8 byte aligned
> > > address
> > > that will fit my request and then put an invalid page and then mark
the
> > > previous and next page inaccessible. And from what i understand, it
> > > still
> > > wont be able to able to detect overrun less that 7 bytes in this
> > > specific
> > > case, right ? Or is it that the remaining 7 bytes can also be counted
to
> > > be
> > > part of my allocation? But in that case why in this case sizeof
operator
> > >
> > > would give me 18 bytes and not 24 bytes? So though not recommended,
> > > would it
> > > be okay to ignore overruns that comply with this ?
> > >
> > > My second doubt is regarding Tags used along with? The four byte tag
is
> > > seens prior to the returned address, and the start of the tag doesnt
> > > seem to
> > > be 8 byte aligned. Then how is this done? How do applications like
> > > poolmon
> > > identify whether the allocations contains a valid tag or not?
> > >
> > > Thanking you in advance
> > > Anees
> > >
> > >
> > > Instant personal loans. Celebrate this season with your family.
> > > http://acm.bridgeovertw.com/hdfc/pl/landingpage/sep04/index.htm?
> > > sitecode=611|395
> > > Apply.
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at http://www.
> > > osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > > ForwardSourceID:NT00007492
> >
> >
> >—
> >Questions? First check the Kernel Driver FAQ at
> >http://www.osronline.com/article.cfm?id=256
> >
> >You are currently subscribed to ntdev as: xxxxx@hotmail.com
> >To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> NRIs - Free money transfer to India. Fly to India for free!
> http://acm.bridgeovertw.com/hdfc/qr/landingpage/sep04/index.htm?
> sitecode=610|394
> Apply Now.
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> ForwardSourceID:NT00007596