Re: [PATCH v2] x86, kaslr: propagate base load address calculation

From: Kees Cook <keescook@chromium.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Jiri Kosina <jkosina@suse.cz>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	live-patching@vger.kernel.org, Linux-MM <linux-mm@kvack.org>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH v2] x86, kaslr: propagate base load address calculation
Date: Mon, 16 Feb 2015 11:27:42 -0800	[thread overview]
Message-ID: <CAGXu5jJVMePoMZwFdH9ROaP2OEW8X-Mr4ztQ37GdP8p+W30ihg@mail.gmail.com> (raw)
In-Reply-To: <20150216115517.GB9500@pd.tnic>

On Mon, Feb 16, 2015 at 3:55 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Fri, Feb 13, 2015 at 03:25:26PM -0800, Kees Cook wrote:
>> No, no; I agree: a malicious boot loader is a lost cause. I mean
>> mostly from a misbehavior perspective. Like, someone sees "kaslr" in
>> the setup args and thinks they can set it to 1 and boot a kernel, etc.
>> Or they set it to 0, but they lack HIBERNATION and "1" gets appended,
>> but the setup_data parser sees the boot-loader one set to 0, etc. I'm
>> just curious if we should avoid getting some poor system into a
>> confusing state.
>
> Well, we can apply the rule of the last setting sticks and since the
> kernel is always going to be adding the last setup_data element of
> type SETUP_KASLR (the boot loader ones will be somewhere on the list
> in-between and we add to the end), we're fine, no?

Sounds good to me!

-Kees

>
> --
> Regards/Gruss,
>     Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --

-- 
Kees Cook
Chrome OS Security