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: <4D4F31BC.3000709@zytor.com>
Date:	Sun, 06 Feb 2011 15:41:48 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	castet.matthieu@...e.fr
CC:	Ingo Molnar <mingo@...e.hu>,
	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/05/2011 08:46 AM, castet.matthieu@...e.fr wrote:
> 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.

No, the problem is that the code is braindamaged and don't take into
account reserved areas or have a mechanism for marking the reserved
areas so that kernel_physical_mapping_init can do the right thing... and
then it's hacked around instead of done properly.

We obviously need to reserve this memory very early in order to make
sure it exists, and init_memory_mapping() ->
kernel_physical_mapping_init() really should be able to deal with that
(for example by walking the list of reserved memory regions and look
which ones of them should have specific protection bits -- not just NX
-- set appropriately.)

The trampoline unification patch could have made this less broken, but
that code is certainly not ready for .38.

I'm officially proposing that we mark the low 1 MiB +x for .38, and do
something saner for .39, including my finishing the trampoline
unification code.

Ingo: ok with you?

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.
--
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/