From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f169.google.com ([209.85.212.169]:36653 "EHLO mail-wi0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751342AbbJBJoI (ORCPT ); Fri, 2 Oct 2015 05:44:08 -0400 Received: by wicgb1 with SMTP id gb1so24910902wic.1 for ; Fri, 02 Oct 2015 02:44:06 -0700 (PDT) Date: Fri, 2 Oct 2015 10:44:05 +0100 From: Matt Fleming To: tglx@linutronix.de, hpa@zytor.com, leif.lindholm@linaro.org, ard.biesheuvel@linaro.org, jlee@suse.com, stable@vger.kernel.org, mjg59@srcf.ucam.org, linux-kernel@vger.kernel.org, mingo@kernel.org, torvalds@linux-foundation.org, bp@suse.de, dyoung@redhat.com, matt.fleming@intel.com, pjones@redhat.com, JBottomley@Odin.com, peterz@infradead.org, efault@gmx.de Cc: linux-tip-commits@vger.kernel.org Subject: Re: [tip:core/urgent] x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down Message-ID: <20151002094405.GA2846@codeblueprint.co.uk> References: <1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org List-ID: On Thu, 01 Oct, at 05:48:43AM, tip-bot for Matt Fleming wrote: > Commit-ID: a5caa209ba9c29c6421292e7879d2387a2ef39c9 > Gitweb: http://git.kernel.org/tip/a5caa209ba9c29c6421292e7879d2387a2ef39c9 > Author: Matt Fleming > AuthorDate: Fri, 25 Sep 2015 23:02:18 +0100 > Committer: Ingo Molnar > CommitDate: Thu, 1 Oct 2015 12:51:28 +0200 > > x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down > > Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced > that signals that the firmware PE/COFF loader supports splitting > code and data sections of PE/COFF images into separate EFI > memory map entries. This allows the kernel to map those regions > with strict memory protections, e.g. EFI_MEMORY_RO for code, > EFI_MEMORY_XP for data, etc. > > Unfortunately, an unwritten requirement of this new feature is > that the regions need to be mapped with the same offsets > relative to each other as observed in the EFI memory map. If > this is not done crashes like this may occur, > > BUG: unable to handle kernel paging request at fffffffefe6086dd > IP: [] 0xfffffffefe6086dd > Call Trace: > [] efi_call+0x7e/0x100 > [] ? virt_efi_set_variable+0x61/0x90 > [] efi_delete_dummy_variable+0x63/0x70 > [] efi_enter_virtual_mode+0x383/0x392 > [] start_kernel+0x38a/0x417 > [] x86_64_start_reservations+0x2a/0x2c > [] x86_64_start_kernel+0xeb/0xef > > Here 0xfffffffefe6086dd refers to an address the firmware > expects to be mapped but which the OS never claimed was mapped. > The issue is that included in these regions are relative > addresses to other regions which were emitted by the firmware > toolchain before the "splitting" of sections occurred at > runtime. > > Needless to say, we don't satisfy this unwritten requirement on > x86_64 and instead map the EFI memory map entries in reverse > order. The above crash is almost certainly triggerable with any > kernel newer than v3.13 because that's when we rewrote the EFI > runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi: > Runtime services virtual mapping"). For kernel versions before > v3.13 things may work by pure luck depending on the > fragmentation of the kernel virtual address space at the time we > map the EFI regions. > > Instead of mapping the EFI memory map entries in reverse order, > where entry N has a higher virtual address than entry N+1, map > them in the same order as they appear in the EFI memory map to > preserve this relative offset between regions. > > This patch has been kept as small as possible with the intention > that it should be applied aggressively to stable and > distribution kernels. It is very much a bugfix rather than > support for a new feature, since when EFI_PROPERTIES_TABLE is > enabled we must map things as outlined above to even boot - we > have no way of asking the firmware not to split the code/data > regions. > > In fact, this patch doesn't even make use of the more strict > memory protections available in UEFI v2.5. That will come later. > > Suggested-by: Ard Biesheuvel > Reported-by: Ard Biesheuvel > Signed-off-by: Matt Fleming > Cc: > Cc: Borislav Petkov > Cc: Chun-Yi > Cc: Dave Young > Cc: H. Peter Anvin > Cc: James Bottomley > Cc: Lee, Chun-Yi > Cc: Leif Lindholm > Cc: Linus Torvalds > Cc: Matthew Garrett > Cc: Mike Galbraith > Cc: Peter Jones > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: linux-kernel@vger.kernel.org > Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk > Signed-off-by: Ingo Molnar It's probably a little late to change this now, but I just realised that I dropped Joey's Tested-by tags from this patch. Sorry Joey! -- Matt Fleming, Intel Open Source Technology Center