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: <1296924395.4d4d7eeb6f1fe@imp.free.fr>
Date:	Sat, 05 Feb 2011 17:46:35 +0100
From:	castet.matthieu@...e.fr
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Ingo Molnar <mingo@...e.hu>, 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

Selon "H. Peter Anvin" <hpa@...or.com>:

> 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.
You could remove PCI BIOS +x hack in static protection, and the x mapping will
be set by set_memory_x().

The problem is that acpi_reserve_wakeup_memory is called too early, before we
build the page table with kernel_physical_mapping_init.

Doing the setting in a arch_initcall make it work.

>
> 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.
The only stuff I understood of static_protections is the comment on top of it :
mapping of bios/kernel region should be on it otherwise, some callers can mess
the protection flags.


Matthieu
Download attachment "diff" of type "application/octet-stream" (705 bytes)