On Oct 21, 2016 5:32 AM, "Matt Fleming" <matt@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 24 Aug, at 06:03:04AM, tip-bot for Andy Lutomirski wrote: > > Commit-ID: e37e43a497d5a8b7c0cc1736d56986f432c394c9 > > Gitweb: http://git.kernel.org/tip/e37e43a497d5a8b7c0cc1736d56986f432c394c9 > > Author: Andy Lutomirski <luto@xxxxxxxxxx> > > AuthorDate: Thu, 11 Aug 2016 02:35:23 -0700 > > Committer: Ingo Molnar <mingo@xxxxxxxxxx> > > CommitDate: Wed, 24 Aug 2016 12:11:42 +0200 > > > > x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y) > > > > This allows x86_64 kernels to enable vmapped stacks by setting > > HAVE_ARCH_VMAP_STACK=y - which enables the CONFIG_VMAP_STACK=y > > high level Kconfig option. > > > > There are a couple of interesting bits: > > This commit broke booting EFI mixed mode kernels. Here's what I've got > queued up to fix it. > > --- > From acf11e55bfcef7a1dca7d1735f4a780e0cdb1c89 Mon Sep 17 00:00:00 2001 > From: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> > Date: Thu, 20 Oct 2016 22:17:21 +0100 > Subject: [PATCH] x86/efi: Prevent mixed mode boot corruption with > CONFIG_VMAP_STACK > > Booting an EFI mixed mode kernel has been crashing since commit: > > e37e43a497d5 ("x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)") > > The user-visible effect in my test setup was the kernel being unable > to find the root file system ramdisk. This was likely caused by silent > memory or page table corruption. > > Enabling CONFIG_DEBUG_VIRTUAL immediately flagged the thunking code as > abusing virt_to_phys() because it was passing addresses that were not > part of the kernel direct mapping. > > Use the slow version instead, which correctly handles all memory > regions by performing a page table walk. > > Suggested-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx> > Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > Cc: Ingo Molnar <mingo@xxxxxxxxxx> > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Cc: "H. Peter Anvin" <hpa@xxxxxxxxx> > Signed-off-by: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> > --- > arch/x86/platform/efi/efi_64.c | 59 +++++++++++++++++++++++++----------------- > 1 file changed, 35 insertions(+), 24 deletions(-) > > diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c > index 58b0f801f66f..e3569a00885b 100644 > --- a/arch/x86/platform/efi/efi_64.c > +++ b/arch/x86/platform/efi/efi_64.c > @@ -211,6 +211,17 @@ void efi_sync_low_kernel_mappings(void) > memcpy(pud_efi, pud_k, sizeof(pud_t) * num_entries); > } > > +/* > + * Wrapper for slow_virt_to_phys() that handles NULL addresses. > + */ > +static inline phys_addr_t virt_to_phys_or_null(void *va) > +{ > + if (!va) > + return 0; > + > + return slow_virt_to_phys(va); > +} > + This is asking for trouble if any of the variable length parameters are on the stack. How about adding a "size_t size" parameter and doing: if (!va) { return 0; } else if (virt_addr_valid(va)) { return virt_to_phys(va); } else { /* A fully aligned variable on the stack is guaranteed not to cross a page boundary. */ WARN_ON(!IS_ALIGNED((uintptr_t)va, size) || size > PAGE_SIZE); return slow_virt_to_phys(va); } -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
