-
Notifications
You must be signed in to change notification settings - Fork 412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Solving the stack "out of bounds" issue (allowing DriverVerifier to run) #4
Comments
Thank you for letting me know a way to "fix" the issue. I was unable to figure out that DriverVerifier was looking at PFN for the thread stack check. It is, personally, very interesting. In addition to risk of 109 bug check you mentioned, adding manipulation of PFN may make code more fragile against updates in the Windows kernel, and may not help developers produce bug-free tools that run multiple platforms. Although I wish to run HyperPlatform with DriveVerifier for ease of debugging, I would think it is lower priority for this reason. Thank you for providing very concrete information anyway. I would probably look into them for fun. |
Note that this issue prevent us from using a checked build too. It would be worth considering fixing this issue to have better tools for testing. Using KeExpandKernelStackAndCalloutEx() without returning from a callback, getting its stack base with IoGetInitialStack(), reusing it for a hypervisor as well as changing thread's stack info and/or PFN. That could potentially an option but still does seem to be a clean enough solution. MmCreateKernelStack() could be handy for solving this issue if it were exported.
|
Hi,
Just to let you know, the correct way to "fix" this issue is to edit the PFNs for the kernel stack, and to set them as kernel stack pages (one of the flags in e2.u1 I believe) as well as write the KTHREAD as the u1.KernelStackOwner, and then OR'ing with 1. You can see this by doing a !pte on a kernel stack page (a real one), and then !pfn, and analyzing the MMPFN structure.
This requires pretty low-level hacking of the PFN database, but in case you were curious, that's why Verifier/Kernel don't like it when you do API calls from VMM context. It's also technically possible to get 109 bug check in this situation.
You may want to investigate KeExpandKernelStackAndCalloutEx as a possible way to avoid this -- it should create a 'legitimate' stack for the VMM.
The text was updated successfully, but these errors were encountered: