linux-kernel - Re: [PATCH] NX protection for kernel data : fix 32 bits S3 suspend

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D4CA3FD.6000901@zytor.com>
Date:	Fri, 04 Feb 2011 17:12:29 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	castet.matthieu@...e.fr,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org,
	Matthias Hopf <mhopf@...e.de>, rjw@...k.pl,
	Andrew Morton <akpm@...ux-foundation.org>,
	Suresh Siddha <suresh.b.siddha@...el.com>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/