Re: Address Verification
- From: soviet_bloke@xxxxxxxxxxx
- Date: 23 Jul 2006 09:30:29 -0700
Hi Doron
this is not a function that drivers should call b/c the context in which it is
called correctly is only w/in the memory manager itself.
But how come that it is documented in DDK, and documentation does not
say that this function is reserved for the system use only??????
Anton Bassov
Doron Holan [MS] wrote:
thatis not correct, i discussed this w/the owner of the memory manager. this
is not a function that drivers should call b/c the context in which it is
called correctly is only w/in the memory manager itself.
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:1153626519.045621.85100@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Doron
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.
If you look at implementation of MmIsAddressValid(), you will see that
it is EXTREMELY
similar to that of MmGetPhysicalAddress(). First of all, it checks page
directory. If page table, corresponding to the address in question, is
not loaded in RAM (i.e P bit of its corresponding entry in the page
directory is not set), MmIsAddressValid() returns FALSE straight away.
If everything is OK, it checks page table. If page , corresponding to
the address in question, is not loaded in RAM (i.e P bit of its
corresponding entry in the page table is not set), it returns FALSE,
otherwise it returns TRUE.
As it follows from the above explanation, MmIsAddressValid() just has
no chance to return TRUE if the target address is invalid in the
address space of the calling process.
Therefore, if it return TRUE, you can be 100% sure that the address is
valid
Anton Bassov
Doron Holan [MS] wrote:
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: Doron Holan [MS]
- Re: Address Verification
- References:
- Re: Address Verification
- From: soviet_bloke
- Re: Address Verification
- From: Doron Holan [MS]
- Re: Address Verification
- From: soviet_bloke
- Re: Address Verification
- From: Doron Holan [MS]
- Re: Address Verification
- Prev by Date: Re: Process Validation
- Next by Date: Re: Address Verification
- Previous by thread: Re: Address Verification
- Next by thread: Re: Address Verification
- Index(es):
Relevant Pages
|
