Re: Address Verification

Hi Peter


Apparently, this is the reason why no one,apart from Memory Manager
itself, should call this function - the problem is that the address
may get invalidated by the time you touch it, although it used to be
valid at the time page table got checked. On UP machine you can deal
with this problem by raising IRQL to DISPATCH_LEVEL, but there is
nothing that can be done on MP machine

Anton Bassov


peterwie@xxxxxxxxxxxxxxxxxxxx wrote:
It's also an instantaneous sampling. Unless you own the memory you have no
reason to expect it to remain valid for any length of time. If it's
application memory the app can free it, unmap it, remap it, etc... If it's
kernel memory then another driver can free it, unmap it, remap it, etc...

since you can never trust an application to do the right thing (even if it's
your own), you can't use MmIsAddressValid for any memory that you don't
already own, and if you own it then you already know it's valid.

-p

--
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.


"Doron Holan [MS]" <doronh@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:uCZSI3nrGHA.4912@xxxxxxxxxxxxxxxxxxxxxxx
things sometimes move slowly.

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:1153672229.291700.142140@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.






.

Relevant Pages

  • Re: Address Verification
    ... called correctly is only w/in the memory manager itself. ... not loaded in RAM (i.e P bit of its corresponding entry in the page ... MmIsAddressValid() returns FALSE straight away. ... but this throws exceptions on ...
    (microsoft.public.development.device.drivers)
  • Re: Address Verification
    ... i discussed this w/the owner of the memory manager. ... not loaded in RAM (i.e P bit of its corresponding entry in the page ... MmIsAddressValid() returns FALSE straight away. ... but this throws exceptions on ...
    (microsoft.public.development.device.drivers)
  • Re: Steve Jobs demos Macintosh in 1984
    ... Woody wrote: ... Stop annoying the fucking hell out of me, ... For sure not much computer memory had been made in 1948 - but it could ... For sure you got a bit more RAM to use in the Speccy - ...
    (uk.comp.sys.mac)
  • Re: Windows uses 4 GB? Really?
    ... I bought 4 GB of RAM because I thought it would speed up my system a bit. ... Some info that is posted here as reference seems to suggest that it is a Windows issue, but others seem to suggest that it is also a hardware issue. ... "I have install total 4GB memory on my motherboard. ... On a SLI system, since PCI-Ex graphic cards will occupy around 256MB, another 256MB will be occupied after you install a 2nd PCI-Ex graphic card. ...
    (microsoft.public.windowsxp.general)
  • Re: Address Verification
    ... Please do not send e-mail directly to this alias. ... called correctly is only w/in the memory manager itself. ... not loaded in RAM (i.e P bit of its corresponding entry in the page ... but this throws exceptions on ...
    (microsoft.public.development.device.drivers)