linux-kernel - Re: [REGRESSION] EFI mixed mode patch triggers boot failure

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: <20161020120357.GB19876@codeblueprint.co.uk>
Date:   Thu, 20 Oct 2016 13:03:57 +0100
From:   Matt Fleming <matt@...eblueprint.co.uk>
To:     Laura Abbott <labbott@...hat.com>
Cc:     "x86@...nel.org" <x86@...nel.org>, linux-kernel@...r.kernel.org,
        linux-efi@...r.kernel.org, Justin Forbes <jforbes@...hat.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>
Subject: Re: [REGRESSION] EFI mixed mode patch triggers boot failure

On Wed, 19 Oct, at 02:13:00PM, Laura Abbott wrote:
> On 10/19/2016 01:04 PM, Laura Abbott wrote:
> >Hi,
> >
> >Fedora received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1384238
> >of a bootup failure with stable 4.7.6. efi=noruntime fixed the bootup problem.
> >1297667083d5442aafe3e337b9413bf02b114edb was linked as the cause
> >of the problem.
> >
> >
> >x86/efi: Only map RAM into EFI page tables if in mixed-mode
> >
> >Waiman reported that booting with CONFIG_EFI_MIXED enabled on his
> >multi-terabyte HP machine results in boot crashes, because the EFI
> >region mapping functions loop forever while trying to map those
> >regions describing RAM.
> >
> >While this patch doesn't fix the underlying hang, there's really no
> >reason to map EFI_CONVENTIONAL_MEMORY regions into the EFI page tables
> >when mixed-mode is not in use at runtime.
> >
> >Reported-by: Waiman Long <waiman.long@....com>
> >Cc: Ard Biesheuvel <ard.biesheuvel@...aro.org>
> >Cc: Borislav Petkov <bp@...en8.de>
> >Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> >CC: Theodore Ts'o <tytso@....edu>
> >Cc: Arnd Bergmann <arnd@...db.de>
> >Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> >Cc: Scott J Norton <scott.norton@....com>
> >Cc: Douglas Hatch <doug.hatch@....com>
> >Cc: <stable@...r.kernel.org> # v4.6+
> >Signed-off-by: Matt Fleming <matt@...eblueprint.co.uk>
> >
> >I made a request in the bugzilla for the reporter to
> >give a bootlog with efi=debug which I'm still waiting on.
> >
> >Any ideas?
> >
> >Thanks,
> >Laura
> 
> dmesg with efi=debug from the reporter is attached

> [    0.000000] DMI: Hewlett-Packard Compaq CQ58 Notebook PC/188B, BIOS F.36 06/07/2013

Hmm.. this is a fairly old machine, what kernel versions has the
reporter successfully run on it? The code that was nop'd out in the
above commit for the native case only came into existence in v4.6.

The fact that booting with efi=old_map does *not* seem to result in a
booting kernel is very suspicious. Could you ask them to double-check?

Maybe try this patch too on v4.7.6.

---

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 964c7022d31d..b07183c6b470 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -244,9 +244,12 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
 	 * text and allocate a new stack because we can't rely on the
 	 * stack pointer being < 4GB.
 	 */
-	if (!IS_ENABLED(CONFIG_EFI_MIXED) || efi_is_native())
+	if (!IS_ENABLED(CONFIG_EFI_MIXED))
 		return 0;
 
+	if (efi_is_native())
+		goto map_text;
+
 	/*
 	 * Map all of RAM so that we can access arguments in the 1:1
 	 * mapping when making EFI runtime calls.
@@ -273,6 +276,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
 	efi_scratch.phys_stack = virt_to_phys(page_address(page));
 	efi_scratch.phys_stack += PAGE_SIZE; /* stack grows down */
 
+map_text:
 	npages = (_etext - _text) >> PAGE_SHIFT;
 	text = __pa(_text);
 	pfn = text >> PAGE_SHIFT;