2019-05-19 20:08:55 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2015-10-25 18:26:35 +08:00
|
|
|
#define pr_fmt(fmt) "efi: " fmt
|
|
|
|
|
2014-06-02 20:18:35 +08:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/time.h>
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/efi.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/memblock.h>
|
2014-06-13 19:39:55 +08:00
|
|
|
#include <linux/acpi.h>
|
2015-12-12 04:59:45 +08:00
|
|
|
#include <linux/dmi.h>
|
2017-01-27 18:59:46 +08:00
|
|
|
|
|
|
|
#include <asm/e820/api.h>
|
2014-06-02 20:18:35 +08:00
|
|
|
#include <asm/efi.h>
|
|
|
|
#include <asm/uv/uv.h>
|
2017-06-02 21:52:04 +08:00
|
|
|
#include <asm/cpu_device_id.h>
|
2019-11-27 00:54:06 +08:00
|
|
|
#include <asm/realmode.h>
|
2018-09-12 03:15:22 +08:00
|
|
|
#include <asm/reboot.h>
|
2014-06-02 20:18:35 +08:00
|
|
|
|
|
|
|
#define EFI_MIN_RESERVE 5120
|
|
|
|
|
|
|
|
#define EFI_DUMMY_GUID \
|
|
|
|
EFI_GUID(0x4424ac57, 0xbe4b, 0x47dd, 0x9e, 0x97, 0xed, 0x50, 0xf0, 0x9f, 0x92, 0xa9)
|
|
|
|
|
2017-06-02 21:52:04 +08:00
|
|
|
#define QUARK_CSH_SIGNATURE 0x5f435348 /* _CSH */
|
|
|
|
#define QUARK_SECURITY_HEADER_SIZE 0x400
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Header prepended to the standard EFI capsule on Quark systems the are based
|
|
|
|
* on Intel firmware BSP.
|
|
|
|
* @csh_signature: Unique identifier to sanity check signed module
|
|
|
|
* presence ("_CSH").
|
|
|
|
* @version: Current version of CSH used. Should be one for Quark A0.
|
|
|
|
* @modulesize: Size of the entire module including the module header
|
|
|
|
* and payload.
|
|
|
|
* @security_version_number_index: Index of SVN to use for validation of signed
|
|
|
|
* module.
|
|
|
|
* @security_version_number: Used to prevent against roll back of modules.
|
|
|
|
* @rsvd_module_id: Currently unused for Clanton (Quark).
|
|
|
|
* @rsvd_module_vendor: Vendor Identifier. For Intel products value is
|
|
|
|
* 0x00008086.
|
|
|
|
* @rsvd_date: BCD representation of build date as yyyymmdd, where
|
|
|
|
* yyyy=4 digit year, mm=1-12, dd=1-31.
|
|
|
|
* @headersize: Total length of the header including including any
|
|
|
|
* padding optionally added by the signing tool.
|
|
|
|
* @hash_algo: What Hash is used in the module signing.
|
|
|
|
* @cryp_algo: What Crypto is used in the module signing.
|
|
|
|
* @keysize: Total length of the key data including including any
|
|
|
|
* padding optionally added by the signing tool.
|
|
|
|
* @signaturesize: Total length of the signature including including any
|
|
|
|
* padding optionally added by the signing tool.
|
|
|
|
* @rsvd_next_header: 32-bit pointer to the next Secure Boot Module in the
|
|
|
|
* chain, if there is a next header.
|
|
|
|
* @rsvd: Reserved, padding structure to required size.
|
|
|
|
*
|
|
|
|
* See also QuartSecurityHeader_t in
|
|
|
|
* Quark_EDKII_v1.2.1.1/QuarkPlatformPkg/Include/QuarkBootRom.h
|
|
|
|
* from https://downloadcenter.intel.com/download/23197/Intel-Quark-SoC-X1000-Board-Support-Package-BSP
|
|
|
|
*/
|
|
|
|
struct quark_security_header {
|
|
|
|
u32 csh_signature;
|
|
|
|
u32 version;
|
|
|
|
u32 modulesize;
|
|
|
|
u32 security_version_number_index;
|
|
|
|
u32 security_version_number;
|
|
|
|
u32 rsvd_module_id;
|
|
|
|
u32 rsvd_module_vendor;
|
|
|
|
u32 rsvd_date;
|
|
|
|
u32 headersize;
|
|
|
|
u32 hash_algo;
|
|
|
|
u32 cryp_algo;
|
|
|
|
u32 keysize;
|
|
|
|
u32 signaturesize;
|
|
|
|
u32 rsvd_next_header;
|
|
|
|
u32 rsvd[2];
|
|
|
|
};
|
|
|
|
|
2018-03-12 16:45:00 +08:00
|
|
|
static const efi_char16_t efi_dummy_name[] = L"DUMMY";
|
2014-06-02 20:18:35 +08:00
|
|
|
|
|
|
|
static bool efi_no_storage_paranoia;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Some firmware implementations refuse to boot if there's insufficient
|
|
|
|
* space in the variable store. The implementation of garbage collection
|
|
|
|
* in some FW versions causes stale (deleted) variables to take up space
|
|
|
|
* longer than intended and space is only freed once the store becomes
|
|
|
|
* almost completely full.
|
|
|
|
*
|
|
|
|
* Enabling this option disables the space checks in
|
|
|
|
* efi_query_variable_store() and forces garbage collection.
|
|
|
|
*
|
|
|
|
* Only enable this option if deleting EFI variables does not free up
|
|
|
|
* space in your variable store, e.g. if despite deleting variables
|
|
|
|
* you're unable to create new ones.
|
|
|
|
*/
|
|
|
|
static int __init setup_storage_paranoia(char *arg)
|
|
|
|
{
|
|
|
|
efi_no_storage_paranoia = true;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("efi_no_storage_paranoia", setup_storage_paranoia);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Deleting the dummy variable which kicks off garbage collection
|
|
|
|
*/
|
|
|
|
void efi_delete_dummy_variable(void)
|
|
|
|
{
|
2018-07-11 17:40:34 +08:00
|
|
|
efi.set_variable_nonblocking((efi_char16_t *)efi_dummy_name,
|
|
|
|
&EFI_DUMMY_GUID,
|
|
|
|
EFI_VARIABLE_NON_VOLATILE |
|
|
|
|
EFI_VARIABLE_BOOTSERVICE_ACCESS |
|
|
|
|
EFI_VARIABLE_RUNTIME_ACCESS, 0, NULL);
|
2014-06-02 20:18:35 +08:00
|
|
|
}
|
|
|
|
|
2016-02-02 06:06:58 +08:00
|
|
|
/*
|
|
|
|
* In the nonblocking case we do not attempt to perform garbage
|
|
|
|
* collection if we do not have enough free space. Rather, we do the
|
|
|
|
* bare minimum check and give up immediately if the available space
|
|
|
|
* is below EFI_MIN_RESERVE.
|
|
|
|
*
|
|
|
|
* This function is intended to be small and simple because it is
|
|
|
|
* invoked from crash handler paths.
|
|
|
|
*/
|
|
|
|
static efi_status_t
|
|
|
|
query_variable_store_nonblocking(u32 attributes, unsigned long size)
|
|
|
|
{
|
|
|
|
efi_status_t status;
|
|
|
|
u64 storage_size, remaining_size, max_size;
|
|
|
|
|
|
|
|
status = efi.query_variable_info_nonblocking(attributes, &storage_size,
|
|
|
|
&remaining_size,
|
|
|
|
&max_size);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
if (remaining_size - size < EFI_MIN_RESERVE)
|
|
|
|
return EFI_OUT_OF_RESOURCES;
|
|
|
|
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2014-06-02 20:18:35 +08:00
|
|
|
/*
|
|
|
|
* Some firmware implementations refuse to boot if there's insufficient space
|
|
|
|
* in the variable store. Ensure that we never use more than a safe limit.
|
|
|
|
*
|
|
|
|
* Return EFI_SUCCESS if it is safe to write 'size' bytes to the variable
|
|
|
|
* store.
|
|
|
|
*/
|
2016-02-02 06:06:58 +08:00
|
|
|
efi_status_t efi_query_variable_store(u32 attributes, unsigned long size,
|
|
|
|
bool nonblocking)
|
2014-06-02 20:18:35 +08:00
|
|
|
{
|
|
|
|
efi_status_t status;
|
|
|
|
u64 storage_size, remaining_size, max_size;
|
|
|
|
|
|
|
|
if (!(attributes & EFI_VARIABLE_NON_VOLATILE))
|
|
|
|
return 0;
|
|
|
|
|
2016-02-02 06:06:58 +08:00
|
|
|
if (nonblocking)
|
|
|
|
return query_variable_store_nonblocking(attributes, size);
|
|
|
|
|
2014-06-02 20:18:35 +08:00
|
|
|
status = efi.query_variable_info(attributes, &storage_size,
|
|
|
|
&remaining_size, &max_size);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We account for that by refusing the write if permitting it would
|
|
|
|
* reduce the available space to under 5KB. This figure was provided by
|
|
|
|
* Samsung, so should be safe.
|
|
|
|
*/
|
|
|
|
if ((remaining_size - size < EFI_MIN_RESERVE) &&
|
|
|
|
!efi_no_storage_paranoia) {
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Triggering garbage collection may require that the firmware
|
|
|
|
* generate a real EFI_OUT_OF_RESOURCES error. We can force
|
|
|
|
* that by attempting to use more space than is available.
|
|
|
|
*/
|
|
|
|
unsigned long dummy_size = remaining_size + 1024;
|
2018-03-08 16:00:14 +08:00
|
|
|
void *dummy = kzalloc(dummy_size, GFP_KERNEL);
|
2014-06-02 20:18:35 +08:00
|
|
|
|
|
|
|
if (!dummy)
|
|
|
|
return EFI_OUT_OF_RESOURCES;
|
|
|
|
|
2018-03-12 16:45:00 +08:00
|
|
|
status = efi.set_variable((efi_char16_t *)efi_dummy_name,
|
|
|
|
&EFI_DUMMY_GUID,
|
2014-06-02 20:18:35 +08:00
|
|
|
EFI_VARIABLE_NON_VOLATILE |
|
|
|
|
EFI_VARIABLE_BOOTSERVICE_ACCESS |
|
|
|
|
EFI_VARIABLE_RUNTIME_ACCESS,
|
|
|
|
dummy_size, dummy);
|
|
|
|
|
|
|
|
if (status == EFI_SUCCESS) {
|
|
|
|
/*
|
|
|
|
* This should have failed, so if it didn't make sure
|
|
|
|
* that we delete it...
|
|
|
|
*/
|
|
|
|
efi_delete_dummy_variable();
|
|
|
|
}
|
|
|
|
|
|
|
|
kfree(dummy);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The runtime code may now have triggered a garbage collection
|
|
|
|
* run, so check the variable info again
|
|
|
|
*/
|
|
|
|
status = efi.query_variable_info(attributes, &storage_size,
|
|
|
|
&remaining_size, &max_size);
|
|
|
|
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* There still isn't enough room, so return an error
|
|
|
|
*/
|
|
|
|
if (remaining_size - size < EFI_MIN_RESERVE)
|
|
|
|
return EFI_OUT_OF_RESOURCES;
|
|
|
|
}
|
|
|
|
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efi_query_variable_store);
|
|
|
|
|
2016-03-01 05:22:52 +08:00
|
|
|
/*
|
|
|
|
* The UEFI specification makes it clear that the operating system is
|
|
|
|
* free to do whatever it wants with boot services code after
|
|
|
|
* ExitBootServices() has been called. Ignoring this recommendation a
|
|
|
|
* significant bunch of EFI implementations continue calling into boot
|
|
|
|
* services code (SetVirtualAddressMap). In order to work around such
|
|
|
|
* buggy implementations we reserve boot services region during EFI
|
|
|
|
* init and make sure it stays executable. Then, after
|
|
|
|
* SetVirtualAddressMap(), it is discarded.
|
|
|
|
*
|
|
|
|
* However, some boot services regions contain data that is required
|
|
|
|
* by drivers, so we need to track which memory ranges can never be
|
|
|
|
* freed. This is done by tagging those regions with the
|
|
|
|
* EFI_MEMORY_RUNTIME attribute.
|
|
|
|
*
|
|
|
|
* Any driver that wants to mark a region as reserved must use
|
|
|
|
* efi_mem_reserve() which will insert a new EFI memory descriptor
|
|
|
|
* into efi.memmap (splitting existing regions if necessary) and tag
|
|
|
|
* it with EFI_MEMORY_RUNTIME.
|
|
|
|
*/
|
|
|
|
void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
|
|
|
|
{
|
2020-01-14 01:22:43 +08:00
|
|
|
struct efi_memory_map_data data = { 0 };
|
2016-03-01 05:22:52 +08:00
|
|
|
struct efi_mem_range mr;
|
|
|
|
efi_memory_desc_t md;
|
|
|
|
int num_entries;
|
|
|
|
void *new;
|
|
|
|
|
efi: Drop type and attribute checks in efi_mem_desc_lookup()
The current implementation of efi_mem_desc_lookup() includes the
following check on the memory descriptor it returns:
if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
md->type != EFI_BOOT_SERVICES_DATA &&
md->type != EFI_RUNTIME_SERVICES_DATA) {
continue;
}
This means that only EfiBootServicesData or EfiRuntimeServicesData
regions are considered, or any other region type provided that it
has the EFI_MEMORY_RUNTIME attribute set.
Given what the name of the function implies, and the fact that any
physical address can be described in the UEFI memory map only a single
time, it does not make sense to impose this condition in the body of the
loop, but instead, should be imposed by the caller depending on the value
that is returned to it.
Two such callers exist at the moment:
- The BGRT code when running on x86, via efi_mem_reserve() and
efi_arch_mem_reserve(). In this case, the region is already known to
be EfiBootServicesData, and so the check is redundant.
- The ESRT handling code which introduced this function, which calls it
both directly from efi_esrt_init() and again via efi_mem_reserve() and
efi_arch_mem_reserve() [on x86].
So let's move this check into the callers instead. This preserves the
current behavior both for BGRT and ESRT handling, and allows the lookup
routine to be reused by other [upcoming] users that don't have this
limitation.
In the ESRT case, keep the entire condition, so that platforms that
deviate from the UEFI spec and use something other than
EfiBootServicesData for the ESRT table will keep working as before.
For x86's efi_arch_mem_reserve() implementation, limit the type to
EfiBootServicesData, since it is the only type the reservation code
expects to operate on in the first place.
While we're at it, drop the __init annotation so that drivers can use it
as well.
Tested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-8-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:39 +08:00
|
|
|
if (efi_mem_desc_lookup(addr, &md) ||
|
|
|
|
md.type != EFI_BOOT_SERVICES_DATA) {
|
2016-03-01 05:22:52 +08:00
|
|
|
pr_err("Failed to lookup EFI memory descriptor for %pa\n", &addr);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (addr + size > md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT)) {
|
|
|
|
pr_err("Region spans EFI memory descriptors, %pa\n", &addr);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-09-16 22:12:47 +08:00
|
|
|
size += addr % EFI_PAGE_SIZE;
|
|
|
|
size = round_up(size, EFI_PAGE_SIZE);
|
|
|
|
addr = round_down(addr, EFI_PAGE_SIZE);
|
|
|
|
|
2016-03-01 05:22:52 +08:00
|
|
|
mr.range.start = addr;
|
2016-09-16 22:12:47 +08:00
|
|
|
mr.range.end = addr + size - 1;
|
2016-03-01 05:22:52 +08:00
|
|
|
mr.attribute = md.attribute | EFI_MEMORY_RUNTIME;
|
|
|
|
|
|
|
|
num_entries = efi_memmap_split_count(&md, &mr.range);
|
|
|
|
num_entries += efi.memmap.nr_map;
|
|
|
|
|
2020-01-14 01:22:43 +08:00
|
|
|
if (efi_memmap_alloc(num_entries, &data) != 0) {
|
2016-03-01 05:22:52 +08:00
|
|
|
pr_err("Could not allocate boot services memmap\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-01-14 01:22:43 +08:00
|
|
|
new = early_memremap(data.phys_map, data.size);
|
2016-03-01 05:22:52 +08:00
|
|
|
if (!new) {
|
|
|
|
pr_err("Failed to map new boot services memmap\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
efi_memmap_insert(&efi.memmap, new, &mr);
|
2020-01-14 01:22:43 +08:00
|
|
|
early_memunmap(new, data.size);
|
2016-03-01 05:22:52 +08:00
|
|
|
|
2020-01-14 01:22:43 +08:00
|
|
|
efi_memmap_install(&data);
|
2019-12-04 15:52:33 +08:00
|
|
|
e820__range_update(addr, size, E820_TYPE_RAM, E820_TYPE_RESERVED);
|
|
|
|
e820__update_table(e820_table);
|
2016-03-01 05:22:52 +08:00
|
|
|
}
|
|
|
|
|
x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables
Some machines have EFI regions in page zero (physical address
0x00000000) and historically that region has been added to the e820
map via trim_bios_range(), and ultimately mapped into the kernel page
tables. It was not mapped via efi_map_regions() as one would expect.
Alexis reports that with the new separate EFI page tables some boot
services regions, such as page zero, are not mapped. This triggers an
oops during the SetVirtualAddressMap() runtime call.
For the EFI boot services quirk on x86 we need to memblock_reserve()
boot services regions until after SetVirtualAddressMap(). Doing that
while respecting the ownership of regions that may have already been
reserved by the kernel was the motivation behind this commit:
7d68dc3f1003 ("x86, efi: Do not reserve boot services regions within reserved areas")
That patch was merged at a time when the EFI runtime virtual mappings
were inserted into the kernel page tables as described above, and the
trick of setting ->numpages (and hence the region size) to zero to
track regions that should not be freed in efi_free_boot_services()
meant that we never mapped those regions in efi_map_regions(). Instead
we were relying solely on the existing kernel mappings.
Now that we have separate page tables we need to make sure the EFI
boot services regions are mapped correctly, even if someone else has
already called memblock_reserve(). Instead of stashing a tag in
->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
generally makes no sense to mark a boot services region as required at
runtime, it's pretty much guaranteed the firmware will not have
already set this bit.
For the record, the specific circumstances under which Alexis
triggered this bug was that an EFI runtime driver on his machine was
responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
SetVirtualAddressMap().
The event handler for this driver looks like this,
sub rsp,0x28
lea rdx,[rip+0x2445] # 0xaa948720
mov ecx,0x4
call func_aa9447c0 ; call to ConvertPointer(4, & 0xaa948720)
mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
xor eax,eax
mov BYTE PTR [r11+0x1],0x1
add rsp,0x28
ret
Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
instruction because ConvertPointer() was being called to convert the
address 0x0000000000000000, which when converted is left unchanged and
remains 0x0000000000000000.
The output of the oops trace gave the impression of a standard NULL
pointer dereference bug, but because we're accessing physical
addresses during ConvertPointer(), it wasn't. EFI boot services code
is stored at that address on Alexis' machine.
Reported-by: Alexis Murzeau <amurzeau@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-03-11 19:19:23 +08:00
|
|
|
/*
|
|
|
|
* Helper function for efi_reserve_boot_services() to figure out if we
|
|
|
|
* can free regions in efi_free_boot_services().
|
|
|
|
*
|
|
|
|
* Use this function to ensure we do not free regions owned by somebody
|
|
|
|
* else. We must only reserve (and then free) regions:
|
|
|
|
*
|
|
|
|
* - Not within any part of the kernel
|
2017-01-29 00:09:33 +08:00
|
|
|
* - Not the BIOS reserved area (E820_TYPE_RESERVED, E820_TYPE_NVS, etc)
|
x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables
Some machines have EFI regions in page zero (physical address
0x00000000) and historically that region has been added to the e820
map via trim_bios_range(), and ultimately mapped into the kernel page
tables. It was not mapped via efi_map_regions() as one would expect.
Alexis reports that with the new separate EFI page tables some boot
services regions, such as page zero, are not mapped. This triggers an
oops during the SetVirtualAddressMap() runtime call.
For the EFI boot services quirk on x86 we need to memblock_reserve()
boot services regions until after SetVirtualAddressMap(). Doing that
while respecting the ownership of regions that may have already been
reserved by the kernel was the motivation behind this commit:
7d68dc3f1003 ("x86, efi: Do not reserve boot services regions within reserved areas")
That patch was merged at a time when the EFI runtime virtual mappings
were inserted into the kernel page tables as described above, and the
trick of setting ->numpages (and hence the region size) to zero to
track regions that should not be freed in efi_free_boot_services()
meant that we never mapped those regions in efi_map_regions(). Instead
we were relying solely on the existing kernel mappings.
Now that we have separate page tables we need to make sure the EFI
boot services regions are mapped correctly, even if someone else has
already called memblock_reserve(). Instead of stashing a tag in
->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
generally makes no sense to mark a boot services region as required at
runtime, it's pretty much guaranteed the firmware will not have
already set this bit.
For the record, the specific circumstances under which Alexis
triggered this bug was that an EFI runtime driver on his machine was
responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
SetVirtualAddressMap().
The event handler for this driver looks like this,
sub rsp,0x28
lea rdx,[rip+0x2445] # 0xaa948720
mov ecx,0x4
call func_aa9447c0 ; call to ConvertPointer(4, & 0xaa948720)
mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
xor eax,eax
mov BYTE PTR [r11+0x1],0x1
add rsp,0x28
ret
Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
instruction because ConvertPointer() was being called to convert the
address 0x0000000000000000, which when converted is left unchanged and
remains 0x0000000000000000.
The output of the oops trace gave the impression of a standard NULL
pointer dereference bug, but because we're accessing physical
addresses during ConvertPointer(), it wasn't. EFI boot services code
is stored at that address on Alexis' machine.
Reported-by: Alexis Murzeau <amurzeau@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-03-11 19:19:23 +08:00
|
|
|
*/
|
2019-02-02 17:41:10 +08:00
|
|
|
static __init bool can_free_region(u64 start, u64 size)
|
x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables
Some machines have EFI regions in page zero (physical address
0x00000000) and historically that region has been added to the e820
map via trim_bios_range(), and ultimately mapped into the kernel page
tables. It was not mapped via efi_map_regions() as one would expect.
Alexis reports that with the new separate EFI page tables some boot
services regions, such as page zero, are not mapped. This triggers an
oops during the SetVirtualAddressMap() runtime call.
For the EFI boot services quirk on x86 we need to memblock_reserve()
boot services regions until after SetVirtualAddressMap(). Doing that
while respecting the ownership of regions that may have already been
reserved by the kernel was the motivation behind this commit:
7d68dc3f1003 ("x86, efi: Do not reserve boot services regions within reserved areas")
That patch was merged at a time when the EFI runtime virtual mappings
were inserted into the kernel page tables as described above, and the
trick of setting ->numpages (and hence the region size) to zero to
track regions that should not be freed in efi_free_boot_services()
meant that we never mapped those regions in efi_map_regions(). Instead
we were relying solely on the existing kernel mappings.
Now that we have separate page tables we need to make sure the EFI
boot services regions are mapped correctly, even if someone else has
already called memblock_reserve(). Instead of stashing a tag in
->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
generally makes no sense to mark a boot services region as required at
runtime, it's pretty much guaranteed the firmware will not have
already set this bit.
For the record, the specific circumstances under which Alexis
triggered this bug was that an EFI runtime driver on his machine was
responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
SetVirtualAddressMap().
The event handler for this driver looks like this,
sub rsp,0x28
lea rdx,[rip+0x2445] # 0xaa948720
mov ecx,0x4
call func_aa9447c0 ; call to ConvertPointer(4, & 0xaa948720)
mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
xor eax,eax
mov BYTE PTR [r11+0x1],0x1
add rsp,0x28
ret
Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
instruction because ConvertPointer() was being called to convert the
address 0x0000000000000000, which when converted is left unchanged and
remains 0x0000000000000000.
The output of the oops trace gave the impression of a standard NULL
pointer dereference bug, but because we're accessing physical
addresses during ConvertPointer(), it wasn't. EFI boot services code
is stored at that address on Alexis' machine.
Reported-by: Alexis Murzeau <amurzeau@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-03-11 19:19:23 +08:00
|
|
|
{
|
|
|
|
if (start + size > __pa_symbol(_text) && start <= __pa_symbol(_end))
|
|
|
|
return false;
|
|
|
|
|
2017-01-29 00:09:33 +08:00
|
|
|
if (!e820__mapped_all(start, start+size, E820_TYPE_RAM))
|
x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables
Some machines have EFI regions in page zero (physical address
0x00000000) and historically that region has been added to the e820
map via trim_bios_range(), and ultimately mapped into the kernel page
tables. It was not mapped via efi_map_regions() as one would expect.
Alexis reports that with the new separate EFI page tables some boot
services regions, such as page zero, are not mapped. This triggers an
oops during the SetVirtualAddressMap() runtime call.
For the EFI boot services quirk on x86 we need to memblock_reserve()
boot services regions until after SetVirtualAddressMap(). Doing that
while respecting the ownership of regions that may have already been
reserved by the kernel was the motivation behind this commit:
7d68dc3f1003 ("x86, efi: Do not reserve boot services regions within reserved areas")
That patch was merged at a time when the EFI runtime virtual mappings
were inserted into the kernel page tables as described above, and the
trick of setting ->numpages (and hence the region size) to zero to
track regions that should not be freed in efi_free_boot_services()
meant that we never mapped those regions in efi_map_regions(). Instead
we were relying solely on the existing kernel mappings.
Now that we have separate page tables we need to make sure the EFI
boot services regions are mapped correctly, even if someone else has
already called memblock_reserve(). Instead of stashing a tag in
->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
generally makes no sense to mark a boot services region as required at
runtime, it's pretty much guaranteed the firmware will not have
already set this bit.
For the record, the specific circumstances under which Alexis
triggered this bug was that an EFI runtime driver on his machine was
responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
SetVirtualAddressMap().
The event handler for this driver looks like this,
sub rsp,0x28
lea rdx,[rip+0x2445] # 0xaa948720
mov ecx,0x4
call func_aa9447c0 ; call to ConvertPointer(4, & 0xaa948720)
mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
xor eax,eax
mov BYTE PTR [r11+0x1],0x1
add rsp,0x28
ret
Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
instruction because ConvertPointer() was being called to convert the
address 0x0000000000000000, which when converted is left unchanged and
remains 0x0000000000000000.
The output of the oops trace gave the impression of a standard NULL
pointer dereference bug, but because we're accessing physical
addresses during ConvertPointer(), it wasn't. EFI boot services code
is stored at that address on Alexis' machine.
Reported-by: Alexis Murzeau <amurzeau@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-03-11 19:19:23 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-06-02 20:18:35 +08:00
|
|
|
void __init efi_reserve_boot_services(void)
|
|
|
|
{
|
2016-04-26 04:06:38 +08:00
|
|
|
efi_memory_desc_t *md;
|
2014-06-02 20:18:35 +08:00
|
|
|
|
2019-11-07 09:43:05 +08:00
|
|
|
if (!efi_enabled(EFI_MEMMAP))
|
|
|
|
return;
|
|
|
|
|
2016-04-26 04:06:38 +08:00
|
|
|
for_each_efi_memory_desc(md) {
|
2014-06-02 20:18:35 +08:00
|
|
|
u64 start = md->phys_addr;
|
|
|
|
u64 size = md->num_pages << EFI_PAGE_SHIFT;
|
x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables
Some machines have EFI regions in page zero (physical address
0x00000000) and historically that region has been added to the e820
map via trim_bios_range(), and ultimately mapped into the kernel page
tables. It was not mapped via efi_map_regions() as one would expect.
Alexis reports that with the new separate EFI page tables some boot
services regions, such as page zero, are not mapped. This triggers an
oops during the SetVirtualAddressMap() runtime call.
For the EFI boot services quirk on x86 we need to memblock_reserve()
boot services regions until after SetVirtualAddressMap(). Doing that
while respecting the ownership of regions that may have already been
reserved by the kernel was the motivation behind this commit:
7d68dc3f1003 ("x86, efi: Do not reserve boot services regions within reserved areas")
That patch was merged at a time when the EFI runtime virtual mappings
were inserted into the kernel page tables as described above, and the
trick of setting ->numpages (and hence the region size) to zero to
track regions that should not be freed in efi_free_boot_services()
meant that we never mapped those regions in efi_map_regions(). Instead
we were relying solely on the existing kernel mappings.
Now that we have separate page tables we need to make sure the EFI
boot services regions are mapped correctly, even if someone else has
already called memblock_reserve(). Instead of stashing a tag in
->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
generally makes no sense to mark a boot services region as required at
runtime, it's pretty much guaranteed the firmware will not have
already set this bit.
For the record, the specific circumstances under which Alexis
triggered this bug was that an EFI runtime driver on his machine was
responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
SetVirtualAddressMap().
The event handler for this driver looks like this,
sub rsp,0x28
lea rdx,[rip+0x2445] # 0xaa948720
mov ecx,0x4
call func_aa9447c0 ; call to ConvertPointer(4, & 0xaa948720)
mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
xor eax,eax
mov BYTE PTR [r11+0x1],0x1
add rsp,0x28
ret
Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
instruction because ConvertPointer() was being called to convert the
address 0x0000000000000000, which when converted is left unchanged and
remains 0x0000000000000000.
The output of the oops trace gave the impression of a standard NULL
pointer dereference bug, but because we're accessing physical
addresses during ConvertPointer(), it wasn't. EFI boot services code
is stored at that address on Alexis' machine.
Reported-by: Alexis Murzeau <amurzeau@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-03-11 19:19:23 +08:00
|
|
|
bool already_reserved;
|
2014-06-02 20:18:35 +08:00
|
|
|
|
|
|
|
if (md->type != EFI_BOOT_SERVICES_CODE &&
|
|
|
|
md->type != EFI_BOOT_SERVICES_DATA)
|
|
|
|
continue;
|
x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables
Some machines have EFI regions in page zero (physical address
0x00000000) and historically that region has been added to the e820
map via trim_bios_range(), and ultimately mapped into the kernel page
tables. It was not mapped via efi_map_regions() as one would expect.
Alexis reports that with the new separate EFI page tables some boot
services regions, such as page zero, are not mapped. This triggers an
oops during the SetVirtualAddressMap() runtime call.
For the EFI boot services quirk on x86 we need to memblock_reserve()
boot services regions until after SetVirtualAddressMap(). Doing that
while respecting the ownership of regions that may have already been
reserved by the kernel was the motivation behind this commit:
7d68dc3f1003 ("x86, efi: Do not reserve boot services regions within reserved areas")
That patch was merged at a time when the EFI runtime virtual mappings
were inserted into the kernel page tables as described above, and the
trick of setting ->numpages (and hence the region size) to zero to
track regions that should not be freed in efi_free_boot_services()
meant that we never mapped those regions in efi_map_regions(). Instead
we were relying solely on the existing kernel mappings.
Now that we have separate page tables we need to make sure the EFI
boot services regions are mapped correctly, even if someone else has
already called memblock_reserve(). Instead of stashing a tag in
->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
generally makes no sense to mark a boot services region as required at
runtime, it's pretty much guaranteed the firmware will not have
already set this bit.
For the record, the specific circumstances under which Alexis
triggered this bug was that an EFI runtime driver on his machine was
responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
SetVirtualAddressMap().
The event handler for this driver looks like this,
sub rsp,0x28
lea rdx,[rip+0x2445] # 0xaa948720
mov ecx,0x4
call func_aa9447c0 ; call to ConvertPointer(4, & 0xaa948720)
mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
xor eax,eax
mov BYTE PTR [r11+0x1],0x1
add rsp,0x28
ret
Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
instruction because ConvertPointer() was being called to convert the
address 0x0000000000000000, which when converted is left unchanged and
remains 0x0000000000000000.
The output of the oops trace gave the impression of a standard NULL
pointer dereference bug, but because we're accessing physical
addresses during ConvertPointer(), it wasn't. EFI boot services code
is stored at that address on Alexis' machine.
Reported-by: Alexis Murzeau <amurzeau@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-03-11 19:19:23 +08:00
|
|
|
|
|
|
|
already_reserved = memblock_is_region_reserved(start, size);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Because the following memblock_reserve() is paired
|
2018-10-31 06:09:25 +08:00
|
|
|
* with memblock_free_late() for this region in
|
x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables
Some machines have EFI regions in page zero (physical address
0x00000000) and historically that region has been added to the e820
map via trim_bios_range(), and ultimately mapped into the kernel page
tables. It was not mapped via efi_map_regions() as one would expect.
Alexis reports that with the new separate EFI page tables some boot
services regions, such as page zero, are not mapped. This triggers an
oops during the SetVirtualAddressMap() runtime call.
For the EFI boot services quirk on x86 we need to memblock_reserve()
boot services regions until after SetVirtualAddressMap(). Doing that
while respecting the ownership of regions that may have already been
reserved by the kernel was the motivation behind this commit:
7d68dc3f1003 ("x86, efi: Do not reserve boot services regions within reserved areas")
That patch was merged at a time when the EFI runtime virtual mappings
were inserted into the kernel page tables as described above, and the
trick of setting ->numpages (and hence the region size) to zero to
track regions that should not be freed in efi_free_boot_services()
meant that we never mapped those regions in efi_map_regions(). Instead
we were relying solely on the existing kernel mappings.
Now that we have separate page tables we need to make sure the EFI
boot services regions are mapped correctly, even if someone else has
already called memblock_reserve(). Instead of stashing a tag in
->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
generally makes no sense to mark a boot services region as required at
runtime, it's pretty much guaranteed the firmware will not have
already set this bit.
For the record, the specific circumstances under which Alexis
triggered this bug was that an EFI runtime driver on his machine was
responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
SetVirtualAddressMap().
The event handler for this driver looks like this,
sub rsp,0x28
lea rdx,[rip+0x2445] # 0xaa948720
mov ecx,0x4
call func_aa9447c0 ; call to ConvertPointer(4, & 0xaa948720)
mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
xor eax,eax
mov BYTE PTR [r11+0x1],0x1
add rsp,0x28
ret
Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
instruction because ConvertPointer() was being called to convert the
address 0x0000000000000000, which when converted is left unchanged and
remains 0x0000000000000000.
The output of the oops trace gave the impression of a standard NULL
pointer dereference bug, but because we're accessing physical
addresses during ConvertPointer(), it wasn't. EFI boot services code
is stored at that address on Alexis' machine.
Reported-by: Alexis Murzeau <amurzeau@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-03-11 19:19:23 +08:00
|
|
|
* efi_free_boot_services(), we must be extremely
|
|
|
|
* careful not to reserve, and subsequently free,
|
|
|
|
* critical regions of memory (like the kernel image) or
|
|
|
|
* those regions that somebody else has already
|
|
|
|
* reserved.
|
|
|
|
*
|
|
|
|
* A good example of a critical region that must not be
|
|
|
|
* freed is page zero (first 4Kb of memory), which may
|
|
|
|
* contain boot services code/data but is marked
|
2017-01-29 00:09:33 +08:00
|
|
|
* E820_TYPE_RESERVED by trim_bios_range().
|
x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables
Some machines have EFI regions in page zero (physical address
0x00000000) and historically that region has been added to the e820
map via trim_bios_range(), and ultimately mapped into the kernel page
tables. It was not mapped via efi_map_regions() as one would expect.
Alexis reports that with the new separate EFI page tables some boot
services regions, such as page zero, are not mapped. This triggers an
oops during the SetVirtualAddressMap() runtime call.
For the EFI boot services quirk on x86 we need to memblock_reserve()
boot services regions until after SetVirtualAddressMap(). Doing that
while respecting the ownership of regions that may have already been
reserved by the kernel was the motivation behind this commit:
7d68dc3f1003 ("x86, efi: Do not reserve boot services regions within reserved areas")
That patch was merged at a time when the EFI runtime virtual mappings
were inserted into the kernel page tables as described above, and the
trick of setting ->numpages (and hence the region size) to zero to
track regions that should not be freed in efi_free_boot_services()
meant that we never mapped those regions in efi_map_regions(). Instead
we were relying solely on the existing kernel mappings.
Now that we have separate page tables we need to make sure the EFI
boot services regions are mapped correctly, even if someone else has
already called memblock_reserve(). Instead of stashing a tag in
->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
generally makes no sense to mark a boot services region as required at
runtime, it's pretty much guaranteed the firmware will not have
already set this bit.
For the record, the specific circumstances under which Alexis
triggered this bug was that an EFI runtime driver on his machine was
responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
SetVirtualAddressMap().
The event handler for this driver looks like this,
sub rsp,0x28
lea rdx,[rip+0x2445] # 0xaa948720
mov ecx,0x4
call func_aa9447c0 ; call to ConvertPointer(4, & 0xaa948720)
mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
xor eax,eax
mov BYTE PTR [r11+0x1],0x1
add rsp,0x28
ret
Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
instruction because ConvertPointer() was being called to convert the
address 0x0000000000000000, which when converted is left unchanged and
remains 0x0000000000000000.
The output of the oops trace gave the impression of a standard NULL
pointer dereference bug, but because we're accessing physical
addresses during ConvertPointer(), it wasn't. EFI boot services code
is stored at that address on Alexis' machine.
Reported-by: Alexis Murzeau <amurzeau@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-03-11 19:19:23 +08:00
|
|
|
*/
|
|
|
|
if (!already_reserved) {
|
2014-06-02 20:18:35 +08:00
|
|
|
memblock_reserve(start, size);
|
x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables
Some machines have EFI regions in page zero (physical address
0x00000000) and historically that region has been added to the e820
map via trim_bios_range(), and ultimately mapped into the kernel page
tables. It was not mapped via efi_map_regions() as one would expect.
Alexis reports that with the new separate EFI page tables some boot
services regions, such as page zero, are not mapped. This triggers an
oops during the SetVirtualAddressMap() runtime call.
For the EFI boot services quirk on x86 we need to memblock_reserve()
boot services regions until after SetVirtualAddressMap(). Doing that
while respecting the ownership of regions that may have already been
reserved by the kernel was the motivation behind this commit:
7d68dc3f1003 ("x86, efi: Do not reserve boot services regions within reserved areas")
That patch was merged at a time when the EFI runtime virtual mappings
were inserted into the kernel page tables as described above, and the
trick of setting ->numpages (and hence the region size) to zero to
track regions that should not be freed in efi_free_boot_services()
meant that we never mapped those regions in efi_map_regions(). Instead
we were relying solely on the existing kernel mappings.
Now that we have separate page tables we need to make sure the EFI
boot services regions are mapped correctly, even if someone else has
already called memblock_reserve(). Instead of stashing a tag in
->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
generally makes no sense to mark a boot services region as required at
runtime, it's pretty much guaranteed the firmware will not have
already set this bit.
For the record, the specific circumstances under which Alexis
triggered this bug was that an EFI runtime driver on his machine was
responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
SetVirtualAddressMap().
The event handler for this driver looks like this,
sub rsp,0x28
lea rdx,[rip+0x2445] # 0xaa948720
mov ecx,0x4
call func_aa9447c0 ; call to ConvertPointer(4, & 0xaa948720)
mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
xor eax,eax
mov BYTE PTR [r11+0x1],0x1
add rsp,0x28
ret
Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
instruction because ConvertPointer() was being called to convert the
address 0x0000000000000000, which when converted is left unchanged and
remains 0x0000000000000000.
The output of the oops trace gave the impression of a standard NULL
pointer dereference bug, but because we're accessing physical
addresses during ConvertPointer(), it wasn't. EFI boot services code
is stored at that address on Alexis' machine.
Reported-by: Alexis Murzeau <amurzeau@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-03-11 19:19:23 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we are the first to reserve the region, no
|
|
|
|
* one else cares about it. We own it and can
|
|
|
|
* free it later.
|
|
|
|
*/
|
|
|
|
if (can_free_region(start, size))
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't own the region. We must not free it.
|
|
|
|
*
|
|
|
|
* Setting this bit for a boot services region really
|
|
|
|
* doesn't make sense as far as the firmware is
|
|
|
|
* concerned, but it does provide us with a way to tag
|
|
|
|
* those regions that must not be paired with
|
2018-10-31 06:09:25 +08:00
|
|
|
* memblock_free_late().
|
x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables
Some machines have EFI regions in page zero (physical address
0x00000000) and historically that region has been added to the e820
map via trim_bios_range(), and ultimately mapped into the kernel page
tables. It was not mapped via efi_map_regions() as one would expect.
Alexis reports that with the new separate EFI page tables some boot
services regions, such as page zero, are not mapped. This triggers an
oops during the SetVirtualAddressMap() runtime call.
For the EFI boot services quirk on x86 we need to memblock_reserve()
boot services regions until after SetVirtualAddressMap(). Doing that
while respecting the ownership of regions that may have already been
reserved by the kernel was the motivation behind this commit:
7d68dc3f1003 ("x86, efi: Do not reserve boot services regions within reserved areas")
That patch was merged at a time when the EFI runtime virtual mappings
were inserted into the kernel page tables as described above, and the
trick of setting ->numpages (and hence the region size) to zero to
track regions that should not be freed in efi_free_boot_services()
meant that we never mapped those regions in efi_map_regions(). Instead
we were relying solely on the existing kernel mappings.
Now that we have separate page tables we need to make sure the EFI
boot services regions are mapped correctly, even if someone else has
already called memblock_reserve(). Instead of stashing a tag in
->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
generally makes no sense to mark a boot services region as required at
runtime, it's pretty much guaranteed the firmware will not have
already set this bit.
For the record, the specific circumstances under which Alexis
triggered this bug was that an EFI runtime driver on his machine was
responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
SetVirtualAddressMap().
The event handler for this driver looks like this,
sub rsp,0x28
lea rdx,[rip+0x2445] # 0xaa948720
mov ecx,0x4
call func_aa9447c0 ; call to ConvertPointer(4, & 0xaa948720)
mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
xor eax,eax
mov BYTE PTR [r11+0x1],0x1
add rsp,0x28
ret
Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
instruction because ConvertPointer() was being called to convert the
address 0x0000000000000000, which when converted is left unchanged and
remains 0x0000000000000000.
The output of the oops trace gave the impression of a standard NULL
pointer dereference bug, but because we're accessing physical
addresses during ConvertPointer(), it wasn't. EFI boot services code
is stored at that address on Alexis' machine.
Reported-by: Alexis Murzeau <amurzeau@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-03-11 19:19:23 +08:00
|
|
|
*/
|
|
|
|
md->attribute |= EFI_MEMORY_RUNTIME;
|
2014-06-02 20:18:35 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-11-30 01:12:24 +08:00
|
|
|
/*
|
|
|
|
* Apart from having VA mappings for EFI boot services code/data regions,
|
|
|
|
* (duplicate) 1:1 mappings were also created as a quirk for buggy firmware. So,
|
|
|
|
* unmap both 1:1 and VA mappings.
|
|
|
|
*/
|
|
|
|
static void __init efi_unmap_pages(efi_memory_desc_t *md)
|
|
|
|
{
|
|
|
|
pgd_t *pgd = efi_mm.pgd;
|
|
|
|
u64 pa = md->phys_addr;
|
|
|
|
u64 va = md->virt_addr;
|
|
|
|
|
2018-12-22 10:22:34 +08:00
|
|
|
/*
|
|
|
|
* To Do: Remove this check after adding functionality to unmap EFI boot
|
efi/x86: Limit EFI old memory map to SGI UV machines
We carry a quirk in the x86 EFI code to switch back to an older
method of mapping the EFI runtime services memory regions, because
it was deemed risky at the time to implement a new method without
providing a fallback to the old method in case problems arose.
Such problems did arise, but they appear to be limited to SGI UV1
machines, and so these are the only ones for which the fallback gets
enabled automatically (via a DMI quirk). The fallback can be enabled
manually as well, by passing efi=old_map, but there is very little
evidence that suggests that this is something that is being relied
upon in the field.
Given that UV1 support is not enabled by default by the distros
(Ubuntu, Fedora), there is no point in carrying this fallback code
all the time if there are no other users. So let's move it into the
UV support code, and document that efi=old_map now requires this
support code to be enabled.
Note that efi=old_map has been used in the past on other SGI UV
machines to work around kernel regressions in production, so we
keep the option to enable it by hand, but only if the kernel was
built with UV support.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-8-ardb@kernel.org
2020-01-14 01:22:39 +08:00
|
|
|
* services code/data regions from direct mapping area because the UV1
|
|
|
|
* memory map maps EFI regions in swapper_pg_dir.
|
2018-12-22 10:22:34 +08:00
|
|
|
*/
|
efi/x86: Limit EFI old memory map to SGI UV machines
We carry a quirk in the x86 EFI code to switch back to an older
method of mapping the EFI runtime services memory regions, because
it was deemed risky at the time to implement a new method without
providing a fallback to the old method in case problems arose.
Such problems did arise, but they appear to be limited to SGI UV1
machines, and so these are the only ones for which the fallback gets
enabled automatically (via a DMI quirk). The fallback can be enabled
manually as well, by passing efi=old_map, but there is very little
evidence that suggests that this is something that is being relied
upon in the field.
Given that UV1 support is not enabled by default by the distros
(Ubuntu, Fedora), there is no point in carrying this fallback code
all the time if there are no other users. So let's move it into the
UV support code, and document that efi=old_map now requires this
support code to be enabled.
Note that efi=old_map has been used in the past on other SGI UV
machines to work around kernel regressions in production, so we
keep the option to enable it by hand, but only if the kernel was
built with UV support.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-8-ardb@kernel.org
2020-01-14 01:22:39 +08:00
|
|
|
if (efi_have_uv1_memmap())
|
2018-12-22 10:22:34 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* EFI mixed mode has all RAM mapped to access arguments while making
|
|
|
|
* EFI runtime calls, hence don't unmap EFI boot services code/data
|
|
|
|
* regions.
|
|
|
|
*/
|
2019-12-24 23:10:06 +08:00
|
|
|
if (efi_is_mixed())
|
2018-12-22 10:22:34 +08:00
|
|
|
return;
|
|
|
|
|
2018-11-30 01:12:24 +08:00
|
|
|
if (kernel_unmap_pages_in_pgd(pgd, pa, md->num_pages))
|
|
|
|
pr_err("Failed to unmap 1:1 mapping for 0x%llx\n", pa);
|
|
|
|
|
|
|
|
if (kernel_unmap_pages_in_pgd(pgd, va, md->num_pages))
|
|
|
|
pr_err("Failed to unmap VA mapping for 0x%llx\n", va);
|
|
|
|
}
|
|
|
|
|
2014-06-02 20:18:35 +08:00
|
|
|
void __init efi_free_boot_services(void)
|
|
|
|
{
|
2020-01-14 01:22:43 +08:00
|
|
|
struct efi_memory_map_data data = { 0 };
|
2016-04-26 04:06:38 +08:00
|
|
|
efi_memory_desc_t *md;
|
2016-03-01 05:22:52 +08:00
|
|
|
int num_entries = 0;
|
|
|
|
void *new, *new_md;
|
2014-06-02 20:18:35 +08:00
|
|
|
|
2020-01-16 00:35:45 +08:00
|
|
|
/* Keep all regions for /sys/kernel/debug/efi */
|
|
|
|
if (efi_enabled(EFI_DBG))
|
|
|
|
return;
|
|
|
|
|
2016-04-26 04:06:38 +08:00
|
|
|
for_each_efi_memory_desc(md) {
|
2014-06-02 20:18:35 +08:00
|
|
|
unsigned long long start = md->phys_addr;
|
|
|
|
unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
|
2016-08-10 17:29:17 +08:00
|
|
|
size_t rm_size;
|
2014-06-02 20:18:35 +08:00
|
|
|
|
|
|
|
if (md->type != EFI_BOOT_SERVICES_CODE &&
|
2016-03-01 05:22:52 +08:00
|
|
|
md->type != EFI_BOOT_SERVICES_DATA) {
|
|
|
|
num_entries++;
|
2014-06-02 20:18:35 +08:00
|
|
|
continue;
|
2016-03-01 05:22:52 +08:00
|
|
|
}
|
2014-06-02 20:18:35 +08:00
|
|
|
|
x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables
Some machines have EFI regions in page zero (physical address
0x00000000) and historically that region has been added to the e820
map via trim_bios_range(), and ultimately mapped into the kernel page
tables. It was not mapped via efi_map_regions() as one would expect.
Alexis reports that with the new separate EFI page tables some boot
services regions, such as page zero, are not mapped. This triggers an
oops during the SetVirtualAddressMap() runtime call.
For the EFI boot services quirk on x86 we need to memblock_reserve()
boot services regions until after SetVirtualAddressMap(). Doing that
while respecting the ownership of regions that may have already been
reserved by the kernel was the motivation behind this commit:
7d68dc3f1003 ("x86, efi: Do not reserve boot services regions within reserved areas")
That patch was merged at a time when the EFI runtime virtual mappings
were inserted into the kernel page tables as described above, and the
trick of setting ->numpages (and hence the region size) to zero to
track regions that should not be freed in efi_free_boot_services()
meant that we never mapped those regions in efi_map_regions(). Instead
we were relying solely on the existing kernel mappings.
Now that we have separate page tables we need to make sure the EFI
boot services regions are mapped correctly, even if someone else has
already called memblock_reserve(). Instead of stashing a tag in
->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
generally makes no sense to mark a boot services region as required at
runtime, it's pretty much guaranteed the firmware will not have
already set this bit.
For the record, the specific circumstances under which Alexis
triggered this bug was that an EFI runtime driver on his machine was
responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
SetVirtualAddressMap().
The event handler for this driver looks like this,
sub rsp,0x28
lea rdx,[rip+0x2445] # 0xaa948720
mov ecx,0x4
call func_aa9447c0 ; call to ConvertPointer(4, & 0xaa948720)
mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
xor eax,eax
mov BYTE PTR [r11+0x1],0x1
add rsp,0x28
ret
Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
instruction because ConvertPointer() was being called to convert the
address 0x0000000000000000, which when converted is left unchanged and
remains 0x0000000000000000.
The output of the oops trace gave the impression of a standard NULL
pointer dereference bug, but because we're accessing physical
addresses during ConvertPointer(), it wasn't. EFI boot services code
is stored at that address on Alexis' machine.
Reported-by: Alexis Murzeau <amurzeau@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-03-11 19:19:23 +08:00
|
|
|
/* Do not free, someone else owns it: */
|
2016-03-01 05:22:52 +08:00
|
|
|
if (md->attribute & EFI_MEMORY_RUNTIME) {
|
|
|
|
num_entries++;
|
2014-06-02 20:18:35 +08:00
|
|
|
continue;
|
2016-03-01 05:22:52 +08:00
|
|
|
}
|
2014-06-02 20:18:35 +08:00
|
|
|
|
2018-11-30 01:12:24 +08:00
|
|
|
/*
|
|
|
|
* Before calling set_virtual_address_map(), EFI boot services
|
|
|
|
* code/data regions were mapped as a quirk for buggy firmware.
|
|
|
|
* Unmap them from efi_pgd before freeing them up.
|
|
|
|
*/
|
|
|
|
efi_unmap_pages(md);
|
|
|
|
|
2016-08-10 17:29:17 +08:00
|
|
|
/*
|
|
|
|
* Nasty quirk: if all sub-1MB memory is used for boot
|
|
|
|
* services, we can get here without having allocated the
|
|
|
|
* real mode trampoline. It's too late to hand boot services
|
|
|
|
* memory back to the memblock allocator, so instead
|
|
|
|
* try to manually allocate the trampoline if needed.
|
|
|
|
*
|
|
|
|
* I've seen this on a Dell XPS 13 9350 with firmware
|
|
|
|
* 1.4.4 with SGX enabled booting Linux via Fedora 24's
|
|
|
|
* grub2-efi on a hard disk. (And no, I don't know why
|
|
|
|
* this happened, but Linux should still try to boot rather
|
|
|
|
* panicing early.)
|
|
|
|
*/
|
|
|
|
rm_size = real_mode_size_needed();
|
|
|
|
if (rm_size && (start + rm_size) < (1<<20) && size >= rm_size) {
|
2019-03-28 19:42:33 +08:00
|
|
|
set_real_mode_mem(start);
|
2016-08-10 17:29:17 +08:00
|
|
|
start += rm_size;
|
|
|
|
size -= rm_size;
|
|
|
|
}
|
|
|
|
|
2018-10-31 06:09:25 +08:00
|
|
|
memblock_free_late(start, size);
|
2014-06-02 20:18:35 +08:00
|
|
|
}
|
2016-03-01 05:22:52 +08:00
|
|
|
|
2017-05-26 19:36:47 +08:00
|
|
|
if (!num_entries)
|
|
|
|
return;
|
|
|
|
|
2020-01-14 01:22:43 +08:00
|
|
|
if (efi_memmap_alloc(num_entries, &data) != 0) {
|
2016-03-01 05:22:52 +08:00
|
|
|
pr_err("Failed to allocate new EFI memmap\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-01-14 01:22:43 +08:00
|
|
|
new = memremap(data.phys_map, data.size, MEMREMAP_WB);
|
2016-03-01 05:22:52 +08:00
|
|
|
if (!new) {
|
|
|
|
pr_err("Failed to map new EFI memmap\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Build a new EFI memmap that excludes any boot services
|
|
|
|
* regions that are not tagged EFI_MEMORY_RUNTIME, since those
|
|
|
|
* regions have now been freed.
|
|
|
|
*/
|
|
|
|
new_md = new;
|
|
|
|
for_each_efi_memory_desc(md) {
|
|
|
|
if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
|
|
|
|
(md->type == EFI_BOOT_SERVICES_CODE ||
|
|
|
|
md->type == EFI_BOOT_SERVICES_DATA))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
memcpy(new_md, md, efi.memmap.desc_size);
|
|
|
|
new_md += efi.memmap.desc_size;
|
|
|
|
}
|
|
|
|
|
|
|
|
memunmap(new);
|
|
|
|
|
2020-01-14 01:22:43 +08:00
|
|
|
if (efi_memmap_install(&data) != 0) {
|
2016-03-01 05:22:52 +08:00
|
|
|
pr_err("Could not install new EFI memmap\n");
|
|
|
|
return;
|
|
|
|
}
|
2014-06-02 20:18:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A number of config table entries get remapped to virtual addresses
|
|
|
|
* after entering EFI virtual mode. However, the kexec kernel requires
|
|
|
|
* their physical addresses therefore we pass them via setup_data and
|
|
|
|
* correct those entries to their respective physical addresses here.
|
|
|
|
*
|
|
|
|
* Currently only handles smbios which is necessary for some firmware
|
|
|
|
* implementation.
|
|
|
|
*/
|
|
|
|
int __init efi_reuse_config(u64 tables, int nr_tables)
|
|
|
|
{
|
|
|
|
int i, sz, ret = 0;
|
|
|
|
void *p, *tablep;
|
|
|
|
struct efi_setup_data *data;
|
|
|
|
|
2019-05-25 19:25:59 +08:00
|
|
|
if (nr_tables == 0)
|
|
|
|
return 0;
|
|
|
|
|
2014-06-02 20:18:35 +08:00
|
|
|
if (!efi_setup)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!efi_enabled(EFI_64BIT))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
data = early_memremap(efi_setup, sizeof(*data));
|
|
|
|
if (!data) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!data->smbios)
|
|
|
|
goto out_memremap;
|
|
|
|
|
|
|
|
sz = sizeof(efi_config_table_64_t);
|
|
|
|
|
|
|
|
p = tablep = early_memremap(tables, nr_tables * sz);
|
|
|
|
if (!p) {
|
|
|
|
pr_err("Could not map Configuration table!\n");
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out_memremap;
|
|
|
|
}
|
|
|
|
|
2020-01-21 00:23:21 +08:00
|
|
|
for (i = 0; i < nr_tables; i++) {
|
2014-06-02 20:18:35 +08:00
|
|
|
efi_guid_t guid;
|
|
|
|
|
|
|
|
guid = ((efi_config_table_64_t *)p)->guid;
|
|
|
|
|
|
|
|
if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
|
|
|
|
((efi_config_table_64_t *)p)->table = data->smbios;
|
|
|
|
p += sz;
|
|
|
|
}
|
2014-06-09 20:41:26 +08:00
|
|
|
early_memunmap(tablep, nr_tables * sz);
|
2014-06-02 20:18:35 +08:00
|
|
|
|
|
|
|
out_memremap:
|
2014-06-09 20:41:26 +08:00
|
|
|
early_memunmap(data, sizeof(*data));
|
2014-06-02 20:18:35 +08:00
|
|
|
out:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
efi/x86: Limit EFI old memory map to SGI UV machines
We carry a quirk in the x86 EFI code to switch back to an older
method of mapping the EFI runtime services memory regions, because
it was deemed risky at the time to implement a new method without
providing a fallback to the old method in case problems arose.
Such problems did arise, but they appear to be limited to SGI UV1
machines, and so these are the only ones for which the fallback gets
enabled automatically (via a DMI quirk). The fallback can be enabled
manually as well, by passing efi=old_map, but there is very little
evidence that suggests that this is something that is being relied
upon in the field.
Given that UV1 support is not enabled by default by the distros
(Ubuntu, Fedora), there is no point in carrying this fallback code
all the time if there are no other users. So let's move it into the
UV support code, and document that efi=old_map now requires this
support code to be enabled.
Note that efi=old_map has been used in the past on other SGI UV
machines to work around kernel regressions in production, so we
keep the option to enable it by hand, but only if the kernel was
built with UV support.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-8-ardb@kernel.org
2020-01-14 01:22:39 +08:00
|
|
|
static const struct dmi_system_id sgi_uv1_dmi[] __initconst = {
|
2015-12-12 04:59:45 +08:00
|
|
|
{ NULL, "SGI UV1",
|
|
|
|
{ DMI_MATCH(DMI_PRODUCT_NAME, "Stoutland Platform"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_VERSION, "1.0"),
|
|
|
|
DMI_MATCH(DMI_BIOS_VENDOR, "SGI.COM"),
|
|
|
|
}
|
|
|
|
},
|
|
|
|
{ } /* NULL entry stops DMI scanning */
|
|
|
|
};
|
|
|
|
|
2014-06-02 20:18:35 +08:00
|
|
|
void __init efi_apply_memmap_quirks(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Once setup is done earlier, unmap the EFI memory map on mismatched
|
|
|
|
* firmware/kernel architectures since there is no support for runtime
|
|
|
|
* services.
|
|
|
|
*/
|
|
|
|
if (!efi_runtime_supported()) {
|
2015-10-25 18:26:35 +08:00
|
|
|
pr_info("Setup done, disabling due to 32/64-bit mismatch\n");
|
2016-02-27 05:22:05 +08:00
|
|
|
efi_memmap_unmap();
|
2014-06-02 20:18:35 +08:00
|
|
|
}
|
|
|
|
|
2015-12-12 04:59:45 +08:00
|
|
|
/* UV2+ BIOS has a fix for this issue. UV1 still needs the quirk. */
|
efi/x86: Limit EFI old memory map to SGI UV machines
We carry a quirk in the x86 EFI code to switch back to an older
method of mapping the EFI runtime services memory regions, because
it was deemed risky at the time to implement a new method without
providing a fallback to the old method in case problems arose.
Such problems did arise, but they appear to be limited to SGI UV1
machines, and so these are the only ones for which the fallback gets
enabled automatically (via a DMI quirk). The fallback can be enabled
manually as well, by passing efi=old_map, but there is very little
evidence that suggests that this is something that is being relied
upon in the field.
Given that UV1 support is not enabled by default by the distros
(Ubuntu, Fedora), there is no point in carrying this fallback code
all the time if there are no other users. So let's move it into the
UV support code, and document that efi=old_map now requires this
support code to be enabled.
Note that efi=old_map has been used in the past on other SGI UV
machines to work around kernel regressions in production, so we
keep the option to enable it by hand, but only if the kernel was
built with UV support.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-8-ardb@kernel.org
2020-01-14 01:22:39 +08:00
|
|
|
if (dmi_check_system(sgi_uv1_dmi)) {
|
|
|
|
if (IS_ENABLED(CONFIG_X86_UV)) {
|
|
|
|
set_bit(EFI_UV1_MEMMAP, &efi.flags);
|
|
|
|
} else {
|
|
|
|
pr_warn("EFI runtime disabled, needs CONFIG_X86_UV=y on UV1\n");
|
|
|
|
clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
|
|
|
efi_memmap_unmap();
|
|
|
|
}
|
|
|
|
}
|
2014-06-02 20:18:35 +08:00
|
|
|
}
|
2014-06-13 19:39:55 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* For most modern platforms the preferred method of powering off is via
|
|
|
|
* ACPI. However, there are some that are known to require the use of
|
|
|
|
* EFI runtime services and for which ACPI does not work at all.
|
|
|
|
*
|
|
|
|
* Using EFI is a last resort, to be used only if no other option
|
|
|
|
* exists.
|
|
|
|
*/
|
|
|
|
bool efi_reboot_required(void)
|
|
|
|
{
|
|
|
|
if (!acpi_gbl_reduced_hardware)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
efi_reboot_quirk_mode = EFI_RESET_WARM;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool efi_poweroff_required(void)
|
|
|
|
{
|
2016-03-22 08:51:10 +08:00
|
|
|
return acpi_gbl_reduced_hardware || acpi_no_s5;
|
2014-06-13 19:39:55 +08:00
|
|
|
}
|
2017-06-02 21:52:04 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_EFI_CAPSULE_QUIRK_QUARK_CSH
|
|
|
|
|
|
|
|
static int qrk_capsule_setup_info(struct capsule_info *cap_info, void **pkbuff,
|
|
|
|
size_t hdr_bytes)
|
|
|
|
{
|
|
|
|
struct quark_security_header *csh = *pkbuff;
|
|
|
|
|
|
|
|
/* Only process data block that is larger than the security header */
|
|
|
|
if (hdr_bytes < sizeof(struct quark_security_header))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (csh->csh_signature != QUARK_CSH_SIGNATURE ||
|
|
|
|
csh->headersize != QUARK_SECURITY_HEADER_SIZE)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
/* Only process data block if EFI header is included */
|
|
|
|
if (hdr_bytes < QUARK_SECURITY_HEADER_SIZE +
|
|
|
|
sizeof(efi_capsule_header_t))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
pr_debug("Quark security header detected\n");
|
|
|
|
|
|
|
|
if (csh->rsvd_next_header != 0) {
|
|
|
|
pr_err("multiple Quark security headers not supported\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
*pkbuff += csh->headersize;
|
|
|
|
cap_info->total_size = csh->headersize;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Update the first page pointer to skip over the CSH header.
|
|
|
|
*/
|
efi/capsule-loader: Reinstate virtual capsule mapping
Commit:
82c3768b8d68 ("efi/capsule-loader: Use a cached copy of the capsule header")
... refactored the capsule loading code that maps the capsule header,
to avoid having to map it several times.
However, as it turns out, the vmap() call we ended up removing did not
just map the header, but the entire capsule image, and dropping this
virtual mapping breaks capsules that are processed by the firmware
immediately (i.e., without a reboot).
Unfortunately, that change was part of a larger refactor that allowed
a quirk to be implemented for Quark, which has a non-standard memory
layout for capsules, and we have slightly painted ourselves into a
corner by allowing quirk code to mangle the capsule header and memory
layout.
So we need to fix this without breaking Quark. Fortunately, Quark does
not appear to care about the virtual mapping, and so we can simply
do a partial revert of commit:
2a457fb31df6 ("efi/capsule-loader: Use page addresses rather than struct page pointers")
... and create a vmap() mapping of the entire capsule (including header)
based on the reinstated struct page array, unless running on Quark, in
which case we pass the capsule header copy as before.
Reported-by: Ge Song <ge.song@hxt-semitech.com>
Tested-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Tested-by: Ge Song <ge.song@hxt-semitech.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: <stable@vger.kernel.org>
Cc: Dave Young <dyoung@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Fixes: 82c3768b8d68 ("efi/capsule-loader: Use a cached copy of the capsule header")
Link: http://lkml.kernel.org/r/20180102172110.17018-3-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-01-03 01:21:10 +08:00
|
|
|
cap_info->phys[0] += csh->headersize;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* cap_info->capsule should point at a virtual mapping of the entire
|
|
|
|
* capsule, starting at the capsule header. Our image has the Quark
|
|
|
|
* security header prepended, so we cannot rely on the default vmap()
|
|
|
|
* mapping created by the generic capsule code.
|
|
|
|
* Given that the Quark firmware does not appear to care about the
|
|
|
|
* virtual mapping, let's just point cap_info->capsule at our copy
|
|
|
|
* of the capsule header.
|
|
|
|
*/
|
|
|
|
cap_info->capsule = &cap_info->header;
|
2017-06-02 21:52:04 +08:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct x86_cpu_id efi_capsule_quirk_ids[] = {
|
2020-03-20 21:13:52 +08:00
|
|
|
X86_MATCH_VENDOR_FAM_MODEL(INTEL, 5, INTEL_FAM5_QUARK_X1000,
|
|
|
|
&qrk_capsule_setup_info),
|
2017-06-02 21:52:04 +08:00
|
|
|
{ }
|
|
|
|
};
|
|
|
|
|
|
|
|
int efi_capsule_setup_info(struct capsule_info *cap_info, void *kbuff,
|
|
|
|
size_t hdr_bytes)
|
|
|
|
{
|
|
|
|
int (*quirk_handler)(struct capsule_info *, void **, size_t);
|
|
|
|
const struct x86_cpu_id *id;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (hdr_bytes < sizeof(efi_capsule_header_t))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
cap_info->total_size = 0;
|
|
|
|
|
|
|
|
id = x86_match_cpu(efi_capsule_quirk_ids);
|
|
|
|
if (id) {
|
|
|
|
/*
|
|
|
|
* The quirk handler is supposed to return
|
|
|
|
* - a value > 0 if the setup should continue, after advancing
|
|
|
|
* kbuff as needed
|
|
|
|
* - 0 if not enough hdr_bytes are available yet
|
|
|
|
* - a negative error code otherwise
|
|
|
|
*/
|
|
|
|
quirk_handler = (typeof(quirk_handler))id->driver_data;
|
|
|
|
ret = quirk_handler(cap_info, &kbuff, hdr_bytes);
|
|
|
|
if (ret <= 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
memcpy(&cap_info->header, kbuff, sizeof(cap_info->header));
|
|
|
|
|
|
|
|
cap_info->total_size += cap_info->header.imagesize;
|
|
|
|
|
|
|
|
return __efi_capsule_setup_info(cap_info);
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
2018-09-12 03:15:22 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If any access by any efi runtime service causes a page fault, then,
|
|
|
|
* 1. If it's efi_reset_system(), reboot through BIOS.
|
|
|
|
* 2. If any other efi runtime service, then
|
|
|
|
* a. Return error status to the efi caller process.
|
|
|
|
* b. Disable EFI Runtime Services forever and
|
|
|
|
* c. Freeze efi_rts_wq and schedule new process.
|
|
|
|
*
|
|
|
|
* @return: Returns, if the page fault is not handled. This function
|
|
|
|
* will never return if the page fault is handled successfully.
|
|
|
|
*/
|
|
|
|
void efi_recover_from_page_fault(unsigned long phys_addr)
|
|
|
|
{
|
|
|
|
if (!IS_ENABLED(CONFIG_X86_64))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure that an efi runtime service caused the page fault.
|
|
|
|
* "efi_mm" cannot be used to check if the page fault had occurred
|
efi/x86: Limit EFI old memory map to SGI UV machines
We carry a quirk in the x86 EFI code to switch back to an older
method of mapping the EFI runtime services memory regions, because
it was deemed risky at the time to implement a new method without
providing a fallback to the old method in case problems arose.
Such problems did arise, but they appear to be limited to SGI UV1
machines, and so these are the only ones for which the fallback gets
enabled automatically (via a DMI quirk). The fallback can be enabled
manually as well, by passing efi=old_map, but there is very little
evidence that suggests that this is something that is being relied
upon in the field.
Given that UV1 support is not enabled by default by the distros
(Ubuntu, Fedora), there is no point in carrying this fallback code
all the time if there are no other users. So let's move it into the
UV support code, and document that efi=old_map now requires this
support code to be enabled.
Note that efi=old_map has been used in the past on other SGI UV
machines to work around kernel regressions in production, so we
keep the option to enable it by hand, but only if the kernel was
built with UV support.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-8-ardb@kernel.org
2020-01-14 01:22:39 +08:00
|
|
|
* in the firmware context because the UV1 memmap doesn't use efi_pgd.
|
2018-09-12 03:15:22 +08:00
|
|
|
*/
|
2019-02-16 00:55:51 +08:00
|
|
|
if (efi_rts_work.efi_rts_id == EFI_NONE)
|
2018-09-12 03:15:22 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Address range 0x0000 - 0x0fff is always mapped in the efi_pgd, so
|
|
|
|
* page faulting on these addresses isn't expected.
|
|
|
|
*/
|
2019-06-20 01:47:44 +08:00
|
|
|
if (phys_addr <= 0x0fff)
|
2018-09-12 03:15:22 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Print stack trace as it might be useful to know which EFI Runtime
|
|
|
|
* Service is buggy.
|
|
|
|
*/
|
|
|
|
WARN(1, FW_BUG "Page fault caused by firmware at PA: 0x%lx\n",
|
|
|
|
phys_addr);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Buggy efi_reset_system() is handled differently from other EFI
|
|
|
|
* Runtime Services as it doesn't use efi_rts_wq. Although,
|
|
|
|
* native_machine_emergency_restart() says that machine_real_restart()
|
|
|
|
* could fail, it's better not to compilcate this fault handler
|
|
|
|
* because this case occurs *very* rarely and hence could be improved
|
|
|
|
* on a need by basis.
|
|
|
|
*/
|
2019-02-16 00:55:51 +08:00
|
|
|
if (efi_rts_work.efi_rts_id == EFI_RESET_SYSTEM) {
|
2018-09-12 03:15:22 +08:00
|
|
|
pr_info("efi_reset_system() buggy! Reboot through BIOS\n");
|
|
|
|
machine_real_restart(MRR_BIOS);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Before calling EFI Runtime Service, the kernel has switched the
|
|
|
|
* calling process to efi_mm. Hence, switch back to task_mm.
|
|
|
|
*/
|
|
|
|
arch_efi_call_virt_teardown();
|
|
|
|
|
|
|
|
/* Signal error status to the efi caller process */
|
|
|
|
efi_rts_work.status = EFI_ABORTED;
|
|
|
|
complete(&efi_rts_work.efi_rts_comp);
|
|
|
|
|
|
|
|
clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
|
|
|
pr_info("Froze efi_rts_wq and disabled EFI Runtime Services\n");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Call schedule() in an infinite loop, so that any spurious wake ups
|
|
|
|
* will never run efi_rts_wq again.
|
|
|
|
*/
|
|
|
|
for (;;) {
|
|
|
|
set_current_state(TASK_IDLE);
|
|
|
|
schedule();
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|