-3

I've read on this topic for many many hours and tried a plethora of different strategies but can't get this to work in a stable manner.

I am operating in the Windows kernel. I have allocated user-space memory for a process for their use. This memory needs to be executable. The solution I have got the farthest with is traversing the page table to find the matching PTE for the allocated user space memory and clearing the NX bit. This "works", but the system eventually freezes. WinDbg kernel debugger sometimes reports deadlocks.

I assume this is because there is some internal structure the Windows kernel uses to operate on these tables, but of course I do not have access. Does anybody know how to safely find and operate on PTEs? I stress that this issue does not happen at all when I do not run this code. I am 100% certain that this PTE modification, and not another part of my code is causing this.

nx bit
  • 1

1 Answers1

-1

Sounds like the OS is dead locking you while trying to access the same pages that you're modifying. Previous kernel versions had a hyperspace lock that was accessible via the EPROCESS struct but this is no longer required.

... the only “lock” that is now needed for mapping to “hyperspace” is to raise the IRQL: the HyperSpaceLock is needed no more.

Another mention if the deadlock issue with IRQL (as if Geoff Chappell's word wasn't enough) comes from the microsoft doc "Locks, Deadlocks, and Synchronization"

Consider the case where code running at a low IRQL successfully acquires a lock, but the thread is interrupted to run code at a higher IRQL. If the higher-IRQL code tries to acquire the same lock, the thread may hang forever. The lower-IRQL code cannot run until the higher-IRQL code exits, but the higher-IRQL code cannot exit until the lower-IRQL code releases the lock. Only a single thread is involved. To prevent this problem, code that acquires a lock usually raises its IRQL to the highest IRQL at which any driver code that acquires the lock can run.

So, raise your IRQL and you shouldn't deadlock. Just be sure to lower it back down to PASSIVE level ASAP as you're messing with some serious resources.

ObjectivePhP
  • 9
  • 5