linux-kernel - [PATCH v2 0/5] 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-next>] [day] [month] [year] [list]

Message-Id: <cover.1470821230.git.luto@kernel.org>
Date:	Wed, 10 Aug 2016 02:29:12 -0700
From:	Andy Lutomirski <luto@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Cc:	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,
	Andy Lutomirski <luto@...nel.org>
Subject: [PATCH v2 0/5] Allow the trampoline to use EFI boot services RAM

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.

Andy Lutomirski (4):
  x86/boot: Synchronize trampoline_cr4_features and mmu_cr4_features
    directly
  x86/boot: Defer setup_real_mode() to early_initcall time
  x86/boot: Rework reserve_real_mode() to allow multiple tries
  x86/efi: Allocate a trampoline if needed in efi_free_boot_services()

Changes from v1:
 - Fix comment in the last patch (hpa)
 - Add missing first patch (I can't count...)
 - Rebase to v4.8-rc1, uneventfully

Andy Lutomirski (5):
  x86/boot: Run reserve_bios_regions() after we initialize the memory
    map
  x86/boot: Synchronize trampoline_cr4_features and mmu_cr4_features
    directly
  x86/boot: Defer setup_real_mode() to early_initcall time
  x86/boot: Rework reserve_real_mode() to allow multiple tries
  x86/efi: Allocate a trampoline if needed in efi_free_boot_services()

 arch/x86/include/asm/realmode.h | 10 ++++++++-
 arch/x86/kernel/head32.c        |  2 --
 arch/x86/kernel/head64.c        |  1 -
 arch/x86/kernel/setup.c         | 19 ++++++++++-------
 arch/x86/platform/efi/quirks.c  | 21 ++++++++++++++++++
 arch/x86/realmode/init.c        | 47 ++++++++++++++++++++++++++++++-----------
 6 files changed, 76 insertions(+), 24 deletions(-)

-- 
2.7.4