Is it possible having a pointer to check the memory location it it is accessible or if it is resident in physical memory or if it is from non-paged pool? Kernel Memory.
MmIsAddressValid will tell you if reading the specified address would cause a page fault - not more, not less.
“MmIsNonPagedSystemAddressValid” is documented but deprecated
wrote news:xxxxx@ntdev…
> Is it possible having a pointer to check the memory location it it is
> accessible or if it is resident in physical memory or if it is from
> non-paged pool? Kernel Memory.
>
access the memory and u’ll know if its valid or not…you can use try execpt for safety
Dhiren
Sorry, that is a great way to crash. Try/except will not catch bad
addresses in the kernel.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> access the memory and u’ll know if its valid or not…you can use try
> execpt for safety
>
> Dhiren
>
Where is the pointer coming from?
IMHO there’s no solution to your problem. Since you are checking the
validity of a pointer, it means that you don’t trust the kernel module that
is passing that pointer to your driver. Even if you have a function that
validates the pointer, who guarantees that such memory will not be freed
while you are accessing it?
Have a nice day
GV
–
Gianluca Varenni, Windows DDK MVP
CACE Technologies
http://www.cacetech.com
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Wednesday, November 28, 2007 3:16 AM
Subject: [ntdev] Any way to chek arbitrary memory location?
> Is it possible having a pointer to check the memory location it it is
> accessible or if it is resident in physical memory or if it is from
> non-paged pool? Kernel Memory.
>
> —
> 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
> MmIsAddressValid will tell you if reading the specified address would cause
a page fault - not more, not less.
The only thing it can tell you is what the situation *was* like at the moment PTE had been examined. However, by the time you access the address in question the situation may be already different. Therefore, you should not rely too much on it. As Doron explained to me, this function is meant to be used only by the Memory Manager itself, so that it should not have ever been exposed in WDK documentation, in the first place…
Anton Bassov
> access the memory and u’ll know if its valid or not
Great advice!!! If you bluescreen you can be pretty sure that the target address was invalid ( or at least non-resident if you did it at elevated IRQL), and if you don’t, everything was OK. Really easy solution…
Anton Bassov
Well, you can always catch the exception. We used that technique in the
BoundsChecker driver, made life easier in many an occasion!
Alberto.
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Thursday, November 29, 2007 12:44 AM
Subject: RE:[ntdev] Any way to chek arbitrary memory location?
>> access the memory and u’ll know if its valid or not
>
> Great advice!!! If you bluescreen you can be pretty sure that the target
> address was invalid ( or at least non-resident if you did it at elevated
> IRQL), and if you don’t, everything was OK. Really easy solution…
>
> 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
There is a concept well known in the high availability computing world
called ‘fail stop’. In particular, continuing execution in a shared memory
region like the kernel after an unexpected exception likely the result of
data corruption or likely to result in data corruption is a *really bad idea
*. Your exception handler has not contained the error, it has merely masked
its detection (the exception) without any correction. The damage done is
then allowed to propagate throughout the system with unknown consequences.
On Nov 29, 2007 9:40 AM, Alberto Moreira wrote:
> Well, you can always catch the exception. We used that technique in the
> BoundsChecker driver, made life easier in many an occasion!
>
> Alberto.
>
>
> ----- Original Message -----
> From:
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, November 29, 2007 12:44 AM
> Subject: RE:[ntdev] Any way to chek arbitrary memory location?
>
>
> >> access the memory and u’ll know if its valid or not
> >
> > Great advice!!! If you bluescreen you can be pretty sure that the target
> > address was invalid ( or at least non-resident if you did it at elevated
> > IRQL), and if you don’t, everything was OK. Really easy solution…
> >
> > 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
>
–
Mark Roddy
I don’t have any whatsoever experience with high availability, and some little one with kernel development. I agree 150% with Mark and Anton (that surely have more experience that me).
This is just my two cents. I might be wrong here.
The very concept here is where the pointer comes from. If you need to validate the pointer, it means that you don’t trust your caller. Which is perfectly fine if such pointer comes from user level (this is what the I/O manager does for you if you are not adventurous enough to use IO_NEITHER). If it’s a pointer in the system address space, then you do have to trust it. You have function to validate the pointer. And then? for that 1ns in which your ValidateMyPointer() run, the pointer *was* valid. And what guarantees you that the pointer is a valid pointer to some random kernel structure you should not touch?
Ciao
GV
----- Original Message -----
From: Mark Roddy
To: Windows System Software Devs Interest List
Sent: Thursday, November 29, 2007 7:28 PM
Subject: Re: RE:[ntdev] Any way to chek arbitrary memory location?
There is a concept well known in the high availability computing world called ‘fail stop’. In particular, continuing execution in a shared memory region like the kernel after an unexpected exception likely the result of data corruption or likely to result in data corruption is a really bad idea. Your exception handler has not contained the error, it has merely masked its detection (the exception) without any correction. The damage done is then allowed to propagate throughout the system with unknown consequences.
On Nov 29, 2007 9:40 AM, Alberto Moreira wrote:
Well, you can always catch the exception. We used that technique in the
BoundsChecker driver, made life easier in many an occasion!
Alberto.
----- Original Message -----
From:
To: “Windows System Software Devs Interest List” < xxxxx@lists.osr.com>
Sent: Thursday, November 29, 2007 12:44 AM
Subject: RE:[ntdev] Any way to chek arbitrary memory location?
>> access the memory and u’ll know if its valid or not
>
> Great advice!!! If you bluescreen you can be pretty sure that the target
> address was invalid ( or at least non-resident if you did it at elevated
> IRQL), and if you don’t, everything was OK. Really easy solution…
>
> 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
–
Mark Roddy — 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
> The very concept here is where the pointer comes from.
Exactly - this is what we should have started with, in the first place. As long as you have obtained it legitimately, it is responsibility of the component that has provided you with the pointer to make sure that it stays valid at least until you release it, so that you have nothing to worry about. However, if you obtained it in “not-so-legitimate” way, there is nothing that you can do here - you just cannot safely access memory that is owned by someone else without the owner’s knowledge. As simple as that…
Anton Bassov
You make the assumption that accessing an unmapped address is an error. That assumption may not hold, in fact, one may design one’s software around that premise. The exception may not be at all unexpected, or maybe the issue of data corruption is moot, or maybe we’re trying to assess if there is any memory underneath.
There’s another thing. In a piece of code such as BoundsChecker, one of the basic points maybe that you do not stop the machine if you find such an error: you trap it, you diagnose it, you log the fact, and you take steps to protect the machine from a faulty driver so that event though the error happens, the system goes on because that’s exactly what you want BoundsChecker to do.
Every situation is different!
Alberto.
----- Original Message -----
From: Mark Roddy
To: Windows System Software Devs Interest List
Sent: Thursday, November 29, 2007 10:28 PM
Subject: Re: RE:[ntdev] Any way to chek arbitrary memory location?
There is a concept well known in the high availability computing world called ‘fail stop’. In particular, continuing execution in a shared memory region like the kernel after an unexpected exception likely the result of data corruption or likely to result in data corruption is a really bad idea. Your exception handler has not contained the error, it has merely masked its detection (the exception) without any correction. The damage done is then allowed to propagate throughout the system with unknown consequences.
On Nov 29, 2007 9:40 AM, Alberto Moreira wrote:
Well, you can always catch the exception. We used that technique in the
BoundsChecker driver, made life easier in many an occasion!
Alberto.
----- Original Message -----
From:
To: “Windows System Software Devs Interest List” < xxxxx@lists.osr.com>
Sent: Thursday, November 29, 2007 12:44 AM
Subject: RE:[ntdev] Any way to chek arbitrary memory location?
>> access the memory and u’ll know if its valid or not
>
> Great advice!!! If you bluescreen you can be pretty sure that the target
> address was invalid ( or at least non-resident if you did it at elevated
> IRQL), and if you don’t, everything was OK. Really easy solution…
>
> 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
–
Mark Roddy — 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
As others have pointed out, the OS layering restricts pointer validity
checking to the usermode/kernel interface. MmProbeAndLockPages is an example
of a kernel interface designed to deal with pointer checking between
usermode and kernel mode and uses exception handling. Outside of such
mechanisms, elsewhere in the kernel, pointers, once correctly allocated, are
assumed to be valid. The OS simply is not designed (thankfully) to tolerate
kernel components passing garbage pointers to each other. How exactly would
that work? Is my driver performing the role of memory management, handling
page faults for pointers for which there currently is ‘no memory
underneath’? How often should I be testing these pointers to make sure that
there still is valid memory where they point? How would I know that the
memory pointed to actually belongs to that pointer if I cannot trust it?
Shouldn’t I have my own mechanism to validate memory allocation/deallocation
in addition to having my own memory manager to handle VM? Each kernel
component would do this? What if the cause is an uncorrected memory error?
How many more chances are you going to give that bitrot to wreck customer
application data?
As I said, by masking but not correcting an exception caused by an invalid
memory reference, your driver is allowing potential data corruption to
propagate throughout the system. By not allowing the system to stop at the
earliest point in time, you are increasing the probability of undetected
data corruption. Not a good idea.
On Nov 30, 2007 11:01 PM, Alberto Moreira wrote:
> You make the assumption that accessing an unmapped address is an error.
> That assumption may not hold, in fact, one may design one’s software around
> that premise. The exception may not be at all unexpected, or maybe the issue
> of data corruption is moot, or maybe we’re trying to assess if there is any
> memory underneath.
>
> There’s another thing. In a piece of code such as BoundsChecker, one of
> the basic points maybe that you do not stop the machine if you find such an
> error: you trap it, you diagnose it, you log the fact, and you take steps to
> protect the machine from a faulty driver so that event though the error
> happens, the system goes on because that’s exactly what you want
> BoundsChecker to do.
>
> Every situation is different!
>
>
> Alberto.
>
>
> ----- Original Message -----
> From: Mark Roddy
> To: Windows System Software Devs Interest List
> Sent: Thursday, November 29, 2007 10:28 PM
> Subject: Re: RE:[ntdev] Any way to chek arbitrary memory location?
>
> There is a concept well known in the high availability computing world
> called ‘fail stop’. In particular, continuing execution in a shared memory
> region like the kernel after an unexpected exception likely the result of
> data corruption or likely to result in data corruption is a really bad
> idea. Your exception handler has not contained the error, it has merely
> masked its detection (the exception) without any correction. The damage done
> is then allowed to propagate throughout the system with unknown
> consequences.
>
>
>
>
> On Nov 29, 2007 9:40 AM, Alberto Moreira wrote:
>
> > Well, you can always catch the exception. We used that technique in the
> > BoundsChecker driver, made life easier in many an occasion!
> >
> > Alberto.
> >
> >
> > ----- Original Message -----
> > From:
> > To: “Windows System Software Devs Interest List” < xxxxx@lists.osr.com>
> > Sent: Thursday, November 29, 2007 12:44 AM
> > Subject: RE:[ntdev] Any way to chek arbitrary memory location?
> >
> >
> > >> access the memory and u’ll know if its valid or not
> > >
> > > Great advice!!! If you bluescreen you can be pretty sure that the
> > target
> > > address was invalid ( or at least non-resident if you did it at
> > elevated
> > > IRQL), and if you don’t, everything was OK. Really easy solution…
> > >
> > > 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
> >
>
>
>
> –
> Mark Roddy — 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
>
–
Mark Roddy