kernel.git/drivers/firmware/efi/arm-runtime.c, branch linux-4.18.y

efi/arm: preserve early mapping of UEFI memory map longer for BGRT

2018-09-26T06:39:27Z

[ Upstream commit 3ea86495aef2f6de26b7cb1599ba350dd6a0c521 ] The BGRT code validates the contents of the table against the UEFI memory map, and so it expects it to be mapped when the code runs. On ARM, this is currently not the case, since we tear down the early mapping after efi_init() completes, and only create the permanent mapping in arm_enable_runtime_services(), which executes as an early initcall, but still leaves a window where the UEFI memory map is not mapped. So move the call to efi_memmap_unmap() from efi_init() to arm_enable_runtime_services(). Signed-off-by: Ard Biesheuvel [will: fold in EFI_MEMMAP attribute check from Ard] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

efi: Use efi_mm in x86 as well as ARM

2018-03-12T09:05:01Z

Presently, only ARM uses mm_struct to manage EFI page tables and EFI runtime region mappings. As this is the preferred approach, let's make this data structure common across architectures. Specially, for x86, using this data structure improves code maintainability and readability. Tested-by: Bhupesh Sharma [ardb: don't #include the world to get a declaration of struct mm_struct] Signed-off-by: Sai Praneeth Prakhya Signed-off-by: Ard Biesheuvel Reviewed-by: Matt Fleming Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Lee, Chun-Yi Cc: Linus Torvalds Cc: Michael S. Tsirkin Cc: Peter Zijlstra Cc: Ravi Shankar Cc: Ricardo Neri Cc: Thomas Gleixner Cc: Tony Luck Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180312084500.10764-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

efi/arm*: Stop printing addresses of virtual mappings

2018-03-09T07:58:22Z

With the recent %p -> %px changes, we now get something like this in the kernel boot log on ARM/arm64 EFI systems: Remapping and enabling EFI services. EFI remap 0x00000087fb830000 => (ptrval) EFI remap 0x00000087fbdb0000 => (ptrval) EFI remap 0x00000087fffc0000 => (ptrval) The physical addresses of the UEFI runtime regions will also be printed when booting with the efi=debug command line option, and the virtual addresses can be inspected via /sys/kernel/debug/efi_page_tables (if enabled). So let's just remove the lines above. Signed-off-by: Ard Biesheuvel Acked-by: Leif Lindholm Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180308080020.22828-4-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

efi/arm*: Only register page tables when they exist

2018-03-09T07:58:21Z

Currently the arm/arm64 runtime code registers the runtime servies pagetables with ptdump regardless of whether runtime services page tables have been created. As efi_mm.pgd is NULL in these cases, attempting to dump the efi page tables results in a NULL pointer dereference in the ptdump code: /sys/kernel/debug# cat efi_page_tables [ 479.522600] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 479.522715] Mem abort info: [ 479.522764] ESR = 0x96000006 [ 479.522850] Exception class = DABT (current EL), IL = 32 bits [ 479.522899] SET = 0, FnV = 0 [ 479.522937] EA = 0, S1PTW = 0 [ 479.528200] Data abort info: [ 479.528230] ISV = 0, ISS = 0x00000006 [ 479.528317] CM = 0, WnR = 0 [ 479.528317] user pgtable: 4k pages, 48-bit VAs, pgd = 0000000064ab0cb0 [ 479.528449] [0000000000000000] *pgd=00000000fbbe4003, *pud=00000000fb66e003, *pmd=0000000000000000 [ 479.528600] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 479.528664] Modules linked in: [ 479.528699] CPU: 0 PID: 2457 Comm: cat Not tainted 4.15.0-rc3-00065-g2ad2ee7ecb5c-dirty #7 [ 479.528799] Hardware name: FVP Base (DT) [ 479.528899] pstate: 00400009 (nzcv daif +PAN -UAO) [ 479.528941] pc : walk_pgd.isra.1+0x20/0x1d0 [ 479.529011] lr : ptdump_walk_pgd+0x30/0x50 [ 479.529105] sp : ffff00000bf4bc20 [ 479.529185] x29: ffff00000bf4bc20 x28: 0000ffff9d22e000 [ 479.529271] x27: 0000000000020000 x26: ffff80007b4c63c0 [ 479.529358] x25: 00000000014000c0 x24: ffff80007c098900 [ 479.529445] x23: ffff00000bf4beb8 x22: 0000000000000000 [ 479.529532] x21: ffff00000bf4bd70 x20: 0000000000000001 [ 479.529618] x19: ffff00000bf4bcb0 x18: 0000000000000000 [ 479.529760] x17: 000000000041a1c8 x16: ffff0000082139d8 [ 479.529800] x15: 0000ffff9d3c6030 x14: 0000ffff9d2527f4 [ 479.529924] x13: 00000000000003f3 x12: 0000000000000038 [ 479.530000] x11: 0000000000000003 x10: 0101010101010101 [ 479.530099] x9 : 0000000017e94050 x8 : 000000000000003f [ 479.530226] x7 : 0000000000000000 x6 : 0000000000000000 [ 479.530313] x5 : 0000000000000001 x4 : 0000000000000000 [ 479.530416] x3 : ffff000009069fd8 x2 : 0000000000000000 [ 479.530500] x1 : 0000000000000000 x0 : 0000000000000000 [ 479.530599] Process cat (pid: 2457, stack limit = 0x000000005d1b0e6f) [ 479.530660] Call trace: [ 479.530746] walk_pgd.isra.1+0x20/0x1d0 [ 479.530833] ptdump_walk_pgd+0x30/0x50 [ 479.530907] ptdump_show+0x10/0x20 [ 479.530920] seq_read+0xc8/0x470 [ 479.531023] full_proxy_read+0x60/0x90 [ 479.531100] __vfs_read+0x18/0x100 [ 479.531180] vfs_read+0x88/0x160 [ 479.531267] SyS_read+0x48/0xb0 [ 479.531299] el0_svc_naked+0x20/0x24 [ 479.531400] Code: 91400420 f90033a0 a90707a2 f9403fa0 (f9400000) [ 479.531499] ---[ end trace bfe8e28d8acb2b67 ]--- Segmentation fault Let's avoid this problem by only registering the tables after their successful creation, which is also less confusing when EFI runtime services are not in use. Reported-by: Will Deacon Signed-off-by: Mark Rutland Signed-off-by: Ard Biesheuvel Acked-by: Will Deacon Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180308080020.22828-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

efi/arm: Enable DMI/SMBIOS

2017-06-05T15:50:44Z

Wire up the existing arm64 support for SMBIOS tables (aka DMI) for ARM as well, by moving the arm64 init code to drivers/firmware/efi/arm-runtime.c (which is shared between ARM and arm64), and adding a asm/dmi.h header to ARM that defines the mapping routines for the firmware tables. This allows userspace to access these tables to discover system information exposed by the firmware. It also sets the hardware name used in crash dumps, e.g.: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ed3c0000 [00000000] *pgd=bf1f3835 Internal error: Oops: 817 [#1] SMP THUMB2 Modules linked in: CPU: 0 PID: 759 Comm: bash Not tainted 4.10.0-09601-g0e8f38792120-dirty #112 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 ^^^ NOTE: This does *NOT* enable or encourage the use of DMI quirks, i.e., the the practice of identifying the platform via DMI to decide whether certain workarounds for buggy hardware and/or firmware need to be enabled. This would require the DMI subsystem to be enabled much earlier than we do on ARM, which is non-trivial. Signed-off-by: Ard Biesheuvel Acked-by: Russell King Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-14-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

efi/arm: Fix boot crash with CONFIG_CPUMASK_OFFSTACK=y

2017-03-02T07:11:19Z

On ARM and arm64, we use a dedicated mm_struct to map the UEFI Runtime Services regions, which allows us to map those regions on demand, and in a way that is guaranteed to be compatible with incoming kernels across kexec. As it turns out, we don't fully initialize the mm_struct in the same way as process mm_structs are initialized on fork(), which results in the following crash on ARM if CONFIG_CPUMASK_OFFSTACK=y is enabled: ... EFI Variables Facility v0.08 2004-May-17 Unable to handle kernel NULL pointer dereference at virtual address 00000000 [...] Process swapper/0 (pid: 1) ... __memzero() check_and_switch_context() virt_efi_get_next_variable() efivar_init() efivars_sysfs_init() do_one_initcall() ... This is due to a missing call to mm_init_cpumask(), so add it. Signed-off-by: Ard Biesheuvel Cc: # v4.5+ Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1488395154-29786-1-git-send-email-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

arm64: dump: Make ptdump debugfs a separate option

2016-11-07T18:15:04Z

ptdump_register currently initializes a set of page table information and registers debugfs. There are uses for the ptdump option without wanting the debugfs options. Split this out to make it a separate option. Reviewed-by: Ard Biesheuvel Reviewed-by: Kees Cook Reviewed-by: Mark Rutland Tested-by: Mark Rutland Signed-off-by: Laura Abbott Signed-off-by: Catalin Marinas

efi/arm64: Add debugfs node to dump UEFI runtime page tables

2016-09-09T15:08:51Z

Register the debugfs node 'efi_page_tables' to allow the UEFI runtime page tables to be inspected. Note that ARM does not have 'asm/ptdump.h' [yet] so for now, this is arm64 only. Signed-off-by: Ard Biesheuvel Acked-by: Mark Rutland Cc: Leif Lindholm Signed-off-by: Matt Fleming

efi: Add efi_memmap_init_late() for permanent EFI memmap

2016-09-09T15:07:43Z

Drivers need a way to access the EFI memory map at runtime. ARM and arm64 currently provide this by remapping the EFI memory map into the vmalloc space before setting up the EFI virtual mappings. x86 does not provide this functionality which has resulted in the code in efi_mem_desc_lookup() where it will manually map individual EFI memmap entries if the memmap has already been torn down on x86, /* * If a driver calls this after efi_free_boot_services, * ->map will be NULL, and the target may also not be mapped. * So just always get our own virtual map on the CPU. * */ md = early_memremap(p, sizeof (*md)); There isn't a good reason for not providing a permanent EFI memory map for runtime queries, especially since the EFI regions are not mapped into the standard kernel page tables. Tested-by: Dave Young [kexec/kdump] Tested-by: Ard Biesheuvel [arm] Acked-by: Ard Biesheuvel Cc: Leif Lindholm Cc: Peter Jones Cc: Borislav Petkov Cc: Mark Rutland Signed-off-by: Matt Fleming

efi: Refactor efi_memmap_init_early() into arch-neutral code

2016-09-09T15:06:38Z

Every EFI architecture apart from ia64 needs to setup the EFI memory map at efi.memmap, and the code for doing that is essentially the same across all implementations. Therefore, it makes sense to factor this out into the common code under drivers/firmware/efi/. The only slight variation is the data structure out of which we pull the initial memory map information, such as physical address, memory descriptor size and version, etc. We can address this by passing a generic data structure (struct efi_memory_map_data) as the argument to efi_memmap_init_early() which contains the minimum info required for initialising the memory map. In the process, this patch also fixes a few undesirable implementation differences: - ARM and arm64 were failing to clear the EFI_MEMMAP bit when unmapping the early EFI memory map. EFI_MEMMAP indicates whether the EFI memory map is mapped (not the regions contained within) and can be traversed. It's more correct to set the bit as soon as we memremap() the passed in EFI memmap. - Rename efi_unmmap_memmap() to efi_memmap_unmap() to adhere to the regular naming scheme. This patch also uses a read-write mapping for the memory map instead of the read-only mapping currently used on ARM and arm64. x86 needs the ability to update the memory map in-place when assigning virtual addresses to regions (efi_map_region()) and tagging regions when reserving boot services (efi_reserve_boot_services()). There's no way for the generic fake_mem code to know which mapping to use without introducing some arch-specific constant/hook, so just use read-write since read-only is of dubious value for the EFI memory map. Tested-by: Dave Young [kexec/kdump] Tested-by: Ard Biesheuvel [arm] Acked-by: Ard Biesheuvel Cc: Leif Lindholm Cc: Peter Jones Cc: Borislav Petkov Cc: Mark Rutland Signed-off-by: Matt Fleming