Messages in this thread | | | Date | Fri, 04 Feb 2011 17:12:29 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH] NX protection for kernel data : fix 32 bits S3 suspend |
| |
On 02/01/2011 10:26 PM, Ingo Molnar wrote: > > So why not call set_memory_x() in your patch? Mind trying that? > > Thanks, > > Ingo
So I just tried that... it doesn't work. The resulting pages still end up NX:
---[ Kernel Mapping ]--- 0xc0000000-0xc00a0000 640K RW GLB NX pte
This implies that the NX protection is applied after these allocations happen, which is probably why the ugly hack in static_protections() to set the PCI BIOS +x is there as well.
I have to admit to being rather at a loss for where in the boot sequence the NX mappings get set up, despite staring at the code for some time. mark_nxdata_nx() seems to only mark the kernel data/rodata and init region... even though the latter is already done in free_init_pages(). It is also run way, way, way too late in the process -- why on earth should we not have these protections during the driver initialization phase of booting?
I talked to Suresh about the whole static_protections() bit, and as far as he recalls it is because the entire set_memory_*() interface is misdesigned to work on all aliases of a page, despite the fact that protections are per mapping, not per physical page.
However, this isn't something we can fix for .38... I suspect unprotecting the entire 0-640K region might just make most sense, and then we need to do some serious restructuring of the entire handling of this stuff, because it's broken seven ways to Sunday.
-hpa
| |