Patching IDT

I am writing a debugger with the capability of reading kernel RAM to show
extra information about the process. Sometimes I follow pointers around the
kernel but not all the pointers are valid, so I manually check pagetable.

#1: I currently check PTE.V (valid) || PTE.PAGED (paged to disk) (bits 0 and
11) and if either is set I consider the page valid for reading. This seemed
to be working well until this morning when I got a blue screen of death.
-> Am I checking the right things? If not, what should I be checking?


#2: Checking the pagetable is apparently not safe, even though I was in
dispatch level on a single-processor machine.
-> Could I patch the page fault vector in the IDT and manually rescue myself
if I end up reading invalid kernel RAM?


#3.1: If patching the IDT is a solid plan for the simple thing I am trying
to do, what are some good resources showing how to do this? I have a few but
they aren’t so hot.
#3.2: What precautions should I take while patching to ensure stability? My
understanding is my patch will work only on the current processor, so I don’t
have to worry about other processors accessing vector 14 while I am changing
it. I plan to apply the patch only when I start to read kernel RAM and apply
the original back when I am done, and I will be in dispatch level for both
the apply and unapply (but not inbetween since I could not raise exceptions
then). Anything else about which I should be careful?



Also, just a quick miscellaneous. How do I get the page size for the system
from kernel? I use GetSystemInfo() in user mode and could pass that to my
driver, but I prefer to get it from the kernel directly.


Thank you,
L. Spiro

Is my idea just completely batty?


L. Spiro

L. Spiro,

Perhaps you will find some inspiration here:

http://www.openrce.org/repositories/.../Tron-TC8.pdf;
http://www.acm.uiuc.edu/sigmil/talks...lker+Talk.pdf;
and http://www.joestewart.org/ollybone/tutorial.html.

Regards,

Rossetoecioccolato.

LS> #1: I currently check PTE.V (valid) || PTE.PAGED (paged to disk)
LS> (bits 0 and 11) and if either is set I consider the page valid
for
LS> reading.

Why? The CPU doesn't.

LS> #2: Checking the pagetable is apparently not safe, [...]

If one isn't doing it correctly, certainly.

<URL:http://www.cs.miami.edu./~burt/journal/NT/page_chasing.html>

> To J de Boyne Pollard :

If the page is paged to disk (PTE & 0x80) it should be readable. Why would
a no-access page be paged to disk?

And, if I wanted to read that page, I would not be able to do it if I only
check (PTE & 0x01). When paged to disk this is not set. It won’t be set
until I try to read from it.
So if I don’t consider a page valid unless bit 0 is set, I would not be able
to read a lot of RAM that actually is valid/readable.




> To RossettoeCioccolato:
The middle link seems to confirm my idea but I still have questions that
seem not to be answered anywhere else.
#1: Is it correct that patching the IDT is a per-processor operation? So I
can patch on the current processor without having to wory about other
processors.

#2: My patch would allow invalid access to kernel RAM without causing a blue
screen of death. This would not cause security issues or allow other
processes to take advantage of the no-crashing state because if they tried to
read invalid kernel RAM it would just keep calling the page-fault exception
handler over and over.
Since my thread would be checking a global it could safely escape this
cycle, however other threads would be calling the exception routine over and
over until I remove it and put the old one back. I can not be in dispatch
level since I would not be able to throw the exception, so I have no choice
but to allow other threads to run. This leads to my concern and question.
What is the safest way to patch the IDT to avoid race conditions?
The patch is typically made in two parts with the high and low address of
the function to be used. Is it safe to cast the low pointer to a UINT_PTR
and set it to the address of my function with one instruction?


I want to the answer to this but it might not be an issue, since my actual
plan is not to set the exception handler over and over but to set it once and
use a global to determine if mine should just call the real handler or not.
Swapping the global is much faster and allows multiple threads to use my
routine at once.
But even for the one time I set the exception handler I want to know the
true safe way to do it.
Would it be sufficient to just CLI first? If it is per-processor…


L. Spiro

LS> #1: I currently check PTE.V (valid) || PTE.PAGED (paged to disk)
LS> (bits 0 and 11) and if either is set I consider the page valid
LS> for reading.

JdeBP> Why? The CPU doesn't.

LS> If the page is paged to disk (PTE & 0x80) it should be readable.

By reading the data from the disc, certainly. Not necessarily by
pretending that the PTE is valid when it isn't and trying to read some
area of RAM.

LS> Why would a no-access page be paged to disk?

The question that you should be asking is "Why would a page marked as
'paged to disk' exist in RAM?".