linux-kernel - Re: [PATCH 4.8? 0/4] Allow the trampoline to use EFI boot services RAM

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]

Date:	Sun, 31 Jul 2016 22:38:17 +0100
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	Andy Lutomirski <luto@...nel.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Mario Limonciello <mario_limonciello@...l.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Borislav Petkov <bp@...en8.de>,
	Matt Fleming <mfleming@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4.8? 0/4] Allow the trampoline to use EFI boot services
 RAM

On Tue, 26 Jul, at 03:55:24PM, Andy Lutomirski wrote:
> As currently configured, my laptop cannot boot any existing kernel
> because the real mode trampoline can't be reserved.  The ranges in
> which it could live are rejected by the kernel: one is EFI boot
> services data and the other is above the EBDA.
> 
> Allowing use of RAM between the EBDA and 640k is scary: there are
> probably many quirky BIOSes out there, and, as currently structured,
> it would be awkward to allow it just on EFI boots because we
> currently reserve that range before we figure out whether we're
> using EFI.
> 
> This series fixes it the other way: it allow the trampoline to live
> in boot services memory.  It achieves this by deferring the panic
> due to failure to reserve a trampoline until early_initcall time
> and then adjusting the EFI boot services quirk to reserve space
> for the trampoline if we haven't already found it a home.
> 
> I'm hoping this is okay for 4.8 even though it's late: it fixes
> a boot failure and it's fairly conservative -- the only significant
> changes in behavior should be on systems that currently fail to boot.
> 
> I'm not currently proposing it for stable because AFAIK I'm the
> only person to have seen this issue.  If it survives in Linus'
> tree for a while, though, I might propose it for -stable later
> on.

I took a very, very quick look over this series and nothing jumped out
as being wrong. I'll take a much closer look this week.