Hi
Why is a page fault handler hook including setting page attributes to read only and trapping access not safe and reliable (I don’t mind about OS updates, HW dependency etc.)?
I don’t want to implement that, but I like to know why that concept does not work although its implemented often in security software.
Cheers
Hans
> Why is a page fault handler hook including setting page attributes to read only and trapping
access not safe and reliable
You want to do it, and I want to do it as well. It is obvious that only one of us can be the first in a call chain. Once we don’t share a protocol we can easily screw up one another’s operations. Although you can make it work fine on a “clean” system, you cannot guarantee to avoid interops with other third-party software that wants to do exactly the same things that you do…
Anton Bassov
Erm, I read once about technical problems like something about thats unsafe because of the synchronization with the MMU?
Hans
Anton points out one of the problems. The other is that people who do this
seem to take a simplistic view that the page table is all the data. Do you
have the access to all the structures that Windows uses are part of paging,
are you sure you are covering all the cases that Windows checks consistency
for, etc?
Years ago I needed such a capability and met someone who claimed to have it.
Their code looked reasonable, and it worked on their test machine, but even
when I had all the same service packs and hot fixes it would not work on my
test machine. And the second we turned on hotfixes again on his, forget it.
Microsoft owns the hardware in this case, and just like people who try to
play with PCI config space by the raw hardware you may get away with it
once, but not every time. Nowadays people who want this, get a system with
hypervisor support and put the hooks into additional layers of page maps.
–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
wrote in message news:xxxxx@ntdev…
>> Why is a page fault handler hook including setting page attributes to
>> read only and trapping
>> access not safe and reliable
>
> You want to do it, and I want to do it as well. It is obvious that only
> one of us can be the first in a call chain. Once we don’t share a protocol
> we can easily screw up one another’s operations. Although you can make it
> work fine on a “clean” system, you cannot guarantee to avoid interops with
> other third-party software that wants to do exactly the same things that
> you do…
>
> Anton Bassov
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4337 (20090815)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
Information from ESET NOD32 Antivirus, version of virus signature database 4337 (20090815)
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
> Erm, I read once about technical problems like something about thats unsafe because
of the synchronization with the MMU?
Actually, MMU is implemented in a hardware…
Apparently, you mean memory manager, right? Indeed, you can get into a conflict with the MM because you don’t own memory occupied by PTE. However, the only risk is that MM will undo your update to PTE so that your operation on it has no effect - you are not going to catch MM in the middle of its operations if you are careful enough not to start messing around with its internal structures and limit yourself only to clearing RW bit in PTE (it can be done as interlocked set-and-test). However, if you go further than that, you can, indeed, get into a conflict with MM…
Anton Bassov
There can be different approaches to this but all of them require you to
understand in detail how interrupt handling works at CPU level and in
particular what it does to the stack. If your code is more than just a
prologue and you need to retain control after the Windows interrupt 14
handler has executed this is even much more difficult as you will have to
patch Windows as hooking the IDT alone will not be enough. Also these
actions will be caught by patchguard on x64 versions of Windows.
//Daniel
wrote in message news:xxxxx@ntdev…
> Hi
>
> Why is a page fault handler hook including setting page attributes to read
> only and trapping access not safe and reliable (I don’t mind about OS
> updates, HW dependency etc.)?
>
> I don’t want to implement that, but I like to know why that concept does
> not work although its implemented often in security software.
>
> Cheers
>
> Hans
>
> If your code is more than just a prologue and you need to retain control after the Windows
interrupt 14 handler has executed this is even much more difficult as you will have
to patch Windows as hooking the IDT alone will not be enough.
Actually, there is no need to do any patching of the code - modifying the stack of the failing thread in prologue will suffice…
Anton Bassov
Thanks for the answers.
There is Pax PAGEEXEC project, which simulates non-executable pages via software. Same problems with this approach?
Cheers
Hans
> There is Pax PAGEEXEC project, which simulates non-executable pages via software.
Same problems with this approach?
I just wonder how PAX project (which deals with open-source OS) may be related to the whole thing…
It is plainly obvious that all problems that we have pointed out may arise only under proprietary OSes…
Anton Bassov
This may not be correct, but I think that the PAX/PAGEXEC concept (perhaps code?) found it’s way in to Windows (along with ASLR from the same folks) in the form of Software DEP that’s available to XP, even on processors that lack hardware support.
Probably best to ignore what I just said.
mm
“Software DEP” as Windows refers to it is essentially support for /SafeSEH. NT doesn’t use the split-tlb hack and doesn’t support NX on platforms without hardware support for shipping platforms.
-----Original Message-----
From: xxxxx@evitechnology.com
Sent: Monday, August 17, 2009 13:42
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Page fault handler hook, concept buggy?
This may not be correct, but I think that the PAX/PAGEXEC concept (perhaps code?) found it’s way in to Windows (along with ASLR from the same folks) in the form of Software DEP that’s available to XP, even on processors that lack hardware support.
—
NTDEV is sponsored by OSR
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