linux-kernel - Re: [RFC][PATCH] Randomize kernel base address on boot

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: <20110531165252.GB8971@srcf.ucam.org>
Date:	Tue, 31 May 2011 17:52:52 +0100
From:	Matthew Garrett <mjg@...hat.com>
To:	Dan Rosenberg <drosenberg@...curity.com>
Cc:	Tony Luck <tony.luck@...il.com>, linux-kernel@...r.kernel.org,
	kees.cook@...onical.com, davej@...hat.com,
	torvalds@...ux-foundation.org, adobriyan@...il.com,
	eranian@...gle.com, penberg@...nel.org, davem@...emloft.net,
	Arjan van de Ven <arjan@...radead.org>, hpa@...or.com,
	Valdis.Kletnieks@...edu, Andrew Morton <akpm@...ux-foundation.org>,
	pageexec@...email.hu, Ingo Molnar <mingo@...e.hu>,
	Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [RFC][PATCH] Randomize kernel base address on boot

On Thu, May 26, 2011 at 04:39:27PM -0400, Dan Rosenberg wrote:

> 1. I'm nearly finished a first draft of code to parse the BIOS E820
> memory map to determine where it's safe to place the randomized kernel.
> This code accounts for overlapping regions, as well as potential
> conflicts in region types (free vs. reserved, etc.), in favor of
> non-free types.  The end result is, I'll have a reasonable upper bound.

The BIOS E820 map, or the kernel representation? In either case, this 
isn't going to work well with EFI. There are regions that will be marked 
as available in the E820 map that we *mustn't* touch until we've entered 
EFI virtual mode.

(This is, clearly, insane).

One other thing is that when we've entered EFI virtual mode we'll have 
remapped various parts of the EFI memory map into virtual address space. 
There's no way to update these mappings later. If we want kexec to work 
then there has to be a mechanism for ensuring that these mappings can be 
provided to the second kernel and for it to preserve them.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/