Hi,
If I’m on PASSIVE_LEVEL - can I access current process memory directly (with __try/__except)? Is it going to be pagedin always? Or there are some exceptions from this rule? This is general question - so I would be grateful if you will answer as wide as possible.
what with loadimage routine? Can I access fields of image (parse pe) image safely or need to use MmProbeAndLock* function?
thank you for responses.
Well you can access the memory of a process if it exists, but there are
holes in a processes memory, and accessing a non-existent page still will
fail, and exception handling does nothing. It is recommended to probe and
lock, since there is nothing guaranteeing the “current process” when you
test the process will be the same when you access the process under many
circumstances.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Sunday, September 15, 2013 2:49 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] accessing memory in kernel
Hi,
If I’m on PASSIVE_LEVEL - can I access current process memory directly
(with __try/__except)? Is it going to be pagedin always? Or there are some
exceptions from this rule? This is general question - so I would be grateful
if you will answer as wide as possible.
what with loadimage routine? Can I access fields of image (parse pe)
image safely or need to use MmProbeAndLock* function?
thank you for responses.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
Pavel,
OS ‘forgives’ you page faults that happen at PASSIVE. It will silently page in. __try/__except on access to user mode pages is needed to handle incorrect page protection. E.g. if kernel mode tries to write to user mode read-only pages. In multi-threaded environment page protection may be changed at any time by thread that runs concurrently on another CPU/core (intentionally or accidentally). You can’t check protection once and trust it every time. So, any time you access user mode memory, you should use __try/__except. Another way is to ‘capture’ data – copy it to kernel-allocated memory with __try/__except, do whatever modifications you need and copy back to user (again, wrapped with __try/__except). You have to do it even if you access data from process notify routine, since memory protection may be already changed by some process.
Not sure that ProbeAndLock is related to your task. Originally it is intended to map user mode memory into kernel mode (together with MmGetMdlSystemAddressSafe) to access big chunks of user mode memory. It is Ok to access PE fields from image notify since it’s called in the context of the thread that loads image. Note that you can’t modify read-only pages of PE though. (At least officially).
It is insufficient to be at PASSIVE_LEVEL. You must also be in the
context of the calling thread.
The way breakpoints are set is a Copy-On-Write (COW) operation, although I
am uncertain how this is actually implemented (implicitly, meaning any
write to the page makes a copy if the page is still “original”, or
explicit, meaning the breakpoint logic has to determine if the page is
“original”, and if so, makes a copy, updates the map, then sets the
breakpoint). Otherwise, you are able to modify the code of any running
process, which creates a security hole big enough to drive a freight train
through. Sideways. As indicated below, attempting to write to a
write-protected page cannot be caught by _try/_except. Note the debugger
is able to trust the page protection because it has suspended all threads
in the process, and assumes that no other process is going to be changing
them. This also requires COW to be “atomic” for maximum robustness, which
is why I think the first alternative is the likelier implementation, so
maybe someone with source access can clarify this.
As usual, here’s the canonical question: what problem are you trying to
solve?
joe
p.s. I found a bug in the TOPS-10 (DEC PDP-10 OS) around 1970 when the
product compiler failed. So, naturally, I ran it under the debugger. COW
wasn’t implemented, and everyone running the product compiler on our
machine started taking the breakpoint! With the inevitable confusion and
catastrophe. In several years, nobody at DEC had ever done this, and no
customer had ever reported it.
Pavel,
OS ‘forgives’ you page faults that happen at PASSIVE. It will silently
page in. __try/__except on access to user mode pages is needed to handle
incorrect page protection. E.g. if kernel mode tries to write to user mode
read-only pages. In multi-threaded environment page protection may be
changed at any time by thread that runs concurrently on another CPU/core
(intentionally or accidentally). You can’t check protection once and trust
it every time. So, any time you access user mode memory, you should use
__try/__except. Another way is to ‘capture’ data – copy it to
kernel-allocated memory with __try/__except, do whatever modifications you
need and copy back to user (again, wrapped with __try/__except). You have
to do it even if you access data from process notify routine, since memory
protection may be already changed by some process.Not sure that ProbeAndLock is related to your task. Originally it is
intended to map user mode memory into kernel mode (together with
MmGetMdlSystemAddressSafe) to access big chunks of user mode memory. It is
Ok to access PE fields from image notify since it’s called in the context
of the thread that loads image. Note that you can’t modify read-only pages
of PE though. (At least officially).
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer