Re: Address Verification
- From: "Doron Holan [MS]" <doronh@xxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 22 Jul 2006 18:09:34 -0700
MmIsAddressValid() does not tell you if it is a valid memory location, just
that the location could cause paging i/o or not. If you pass in a totally
random address, the result is not defined. The memory location must be
valid already before the call.
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
<soviet_bloke@xxxxxxxxxxx> wrote in message
news:1153598991.428455.154360@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi mate
In order to check whether virtual address is valid in the address space
of a calling process, you can call MmIsAddressValid(). However, keep
in mind that if MmIsAddressValid() returns TRUE, it does not
necessarily mean page is physically resident in RAM (i.e. page faults
still may occur when you access it), unless the virtual address
corresponds to non-paged area.
If you are sure that you are going to access memory only in context of
your application at IRQL<DISPATCH_LEVEL , you can do it directly - this
is how METHOD_NEITHER works.
If memory buffer may get accessed from the kernel mode in context of
some other process and/or at IRQL >=DISPATCH_LEVEL, you have to map it
into the system address space in advance. It can be done either with
MmGetSystemAddressForMdlSafe() or as MmGetPhysicalAddress -
MmMapIoSpace() pair (if you are sure that your buffer does not cross
page boundary or resides on physically adjacent pages)
I hope now you have all info that you need in order to write code that
does not throw exceptions
Anton Bassov
L. Spiro wrote:
I need my kernel-mode driver to access my application's virtual RAM.
I know that I can simply have my driver perform a try/catch on the read
(after using KeStackAttachProcess()), but this throws exceptions on
invalid
RAM (yes, I know that is the point in determining which RAM is valid and
which isn't).
My second option is to use ProbeForRead(), but this again will throw
exceptions on invalid RAM.
My third option is to verify the RAM from user land using IsBadReadPtr(),
but yet again this throws exceptions.
How can I verify the RAM manually without throwing exceptions?
Yes, I know that exceptions are the normal way of telling invalid RAM
from
good RAM, and it would be okay to use these methods under normal
circumstance, but I am in a unique situation where I must not ever
possibly
throw an exception of any kind, at least during this operation.
I would be willing to go so far as to use the page table on 0xC0000000
directly, just to avoid throwing exceptions.
Is that my last option?
If so, where should I look to get started in order to correctly (and
QUICKLY) use the table for this? Speed is also of high importance in
this
unique situation.
Thank you.
.
- Follow-Ups:
- Re: Address Verification
- From: soviet_bloke
- Re: Address Verification
- References:
- Re: Address Verification
- From: soviet_bloke
- Re: Address Verification
- Prev by Date: Re: When to disable/enable APCs?
- Next by Date: Re: Creating a KMDF NDIS <==> USB driver
- Previous by thread: Re: Address Verification
- Next by thread: Re: Address Verification
- Index(es):
Relevant Pages
|
Loading
