2008-01-30 12:31:19 +00:00
|
|
|
/*
|
|
|
|
* Common EFI (Extensible Firmware Interface) support functions
|
|
|
|
* Based on Extensible Firmware Interface Specification version 1.0
|
|
|
|
*
|
|
|
|
* Copyright (C) 1999 VA Linux Systems
|
|
|
|
* Copyright (C) 1999 Walt Drummond <drummond@valinux.com>
|
|
|
|
* Copyright (C) 1999-2002 Hewlett-Packard Co.
|
|
|
|
* David Mosberger-Tang <davidm@hpl.hp.com>
|
|
|
|
* Stephane Eranian <eranian@hpl.hp.com>
|
|
|
|
* Copyright (C) 2005-2008 Intel Co.
|
|
|
|
* Fenghua Yu <fenghua.yu@intel.com>
|
|
|
|
* Bibo Mao <bibo.mao@intel.com>
|
|
|
|
* Chandramouli Narayanan <mouli@linux.intel.com>
|
|
|
|
* Huang Ying <ying.huang@intel.com>
|
2013-10-31 16:25:08 +00:00
|
|
|
* Copyright (C) 2013 SuSE Labs
|
|
|
|
* Borislav Petkov <bp@suse.de> - runtime services VA mapping
|
2008-01-30 12:31:19 +00:00
|
|
|
*
|
|
|
|
* Copied from efi_32.c to eliminate the duplicated code between EFI
|
|
|
|
* 32/64 support code. --ying 2007-10-26
|
|
|
|
*
|
|
|
|
* All EFI Runtime Services are not implemented yet as EFI only
|
|
|
|
* supports physical mode addressing on SoftSDV. This is to be fixed
|
|
|
|
* in a future version. --drummond 1999-07-20
|
|
|
|
*
|
|
|
|
* Implemented EFI runtime services and virtual mode calls. --davidm
|
|
|
|
*
|
|
|
|
* Goutham Rao: <goutham.rao@intel.com>
|
|
|
|
* Skip non-WB memory and ignore empty memory ranges.
|
|
|
|
*/
|
|
|
|
|
2012-02-12 21:24:26 +00:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2008-01-30 12:31:19 +00:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/efi.h>
|
2012-09-29 00:57:05 +00:00
|
|
|
#include <linux/efi-bgrt.h>
|
2011-05-26 16:22:53 +00:00
|
|
|
#include <linux/export.h>
|
2008-01-30 12:31:19 +00:00
|
|
|
#include <linux/bootmem.h>
|
2013-04-11 22:51:01 +00:00
|
|
|
#include <linux/slab.h>
|
2010-08-25 20:39:17 +00:00
|
|
|
#include <linux/memblock.h>
|
2008-01-30 12:31:19 +00:00
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/uaccess.h>
|
|
|
|
#include <linux/time.h>
|
|
|
|
#include <linux/io.h>
|
|
|
|
#include <linux/reboot.h>
|
|
|
|
#include <linux/bcd.h>
|
|
|
|
|
|
|
|
#include <asm/setup.h>
|
|
|
|
#include <asm/efi.h>
|
2017-01-27 10:59:46 +00:00
|
|
|
#include <asm/e820/api.h>
|
2008-01-30 12:31:19 +00:00
|
|
|
#include <asm/time.h>
|
2008-01-30 12:33:55 +00:00
|
|
|
#include <asm/cacheflush.h>
|
|
|
|
#include <asm/tlbflush.h>
|
2009-09-10 02:48:56 +00:00
|
|
|
#include <asm/x86_init.h>
|
2014-03-04 16:02:17 +00:00
|
|
|
#include <asm/uv/uv.h>
|
2008-01-30 12:31:19 +00:00
|
|
|
|
2008-02-13 21:26:13 +00:00
|
|
|
static struct efi efi_phys __initdata;
|
2008-01-30 12:31:19 +00:00
|
|
|
static efi_system_table_t efi_systab __initdata;
|
|
|
|
|
2014-01-04 00:08:48 +00:00
|
|
|
static efi_config_table_type_t arch_tables[] __initdata = {
|
2013-09-05 10:34:54 +00:00
|
|
|
#ifdef CONFIG_X86_UV
|
|
|
|
{UV_SYSTEM_TABLE_GUID, "UVsystab", &efi.uv_systab},
|
|
|
|
#endif
|
2013-10-03 14:42:37 +00:00
|
|
|
{NULL_GUID, NULL, NULL},
|
2013-09-05 10:34:54 +00:00
|
|
|
};
|
|
|
|
|
2013-12-20 10:02:19 +00:00
|
|
|
u64 efi_setup; /* efi setup_data physical address */
|
2013-12-20 10:02:18 +00:00
|
|
|
|
2014-09-07 17:42:15 +00:00
|
|
|
static int add_efi_memmap __initdata;
|
2008-06-25 12:44:46 +00:00
|
|
|
static int __init setup_add_efi_memmap(char *arg)
|
|
|
|
{
|
|
|
|
add_efi_memmap = 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("add_efi_memmap", setup_add_efi_memmap);
|
|
|
|
|
2008-01-30 12:31:19 +00:00
|
|
|
static efi_status_t __init phys_efi_set_virtual_address_map(
|
|
|
|
unsigned long memory_map_size,
|
|
|
|
unsigned long descriptor_size,
|
|
|
|
u32 descriptor_version,
|
|
|
|
efi_memory_desc_t *virtual_map)
|
|
|
|
{
|
|
|
|
efi_status_t status;
|
2015-03-03 06:34:33 +00:00
|
|
|
unsigned long flags;
|
2015-03-03 06:48:50 +00:00
|
|
|
pgd_t *save_pgd;
|
2008-01-30 12:31:19 +00:00
|
|
|
|
2015-03-03 06:48:50 +00:00
|
|
|
save_pgd = efi_call_phys_prolog();
|
2015-03-03 06:34:33 +00:00
|
|
|
|
|
|
|
/* Disable interrupts around EFI calls: */
|
|
|
|
local_irq_save(flags);
|
2014-03-27 22:10:39 +00:00
|
|
|
status = efi_call_phys(efi_phys.set_virtual_address_map,
|
|
|
|
memory_map_size, descriptor_size,
|
|
|
|
descriptor_version, virtual_map);
|
2015-03-03 06:34:33 +00:00
|
|
|
local_irq_restore(flags);
|
|
|
|
|
2015-03-03 06:48:50 +00:00
|
|
|
efi_call_phys_epilog(save_pgd);
|
2015-03-03 06:34:33 +00:00
|
|
|
|
2008-01-30 12:31:19 +00:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2015-06-24 23:58:15 +00:00
|
|
|
void __init efi_find_mirror(void)
|
|
|
|
{
|
2016-04-25 20:06:38 +00:00
|
|
|
efi_memory_desc_t *md;
|
2015-06-24 23:58:15 +00:00
|
|
|
u64 mirror_size = 0, total_size = 0;
|
|
|
|
|
2016-04-25 20:06:38 +00:00
|
|
|
for_each_efi_memory_desc(md) {
|
2015-06-24 23:58:15 +00:00
|
|
|
unsigned long long start = md->phys_addr;
|
|
|
|
unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
|
|
|
|
|
|
|
|
total_size += size;
|
|
|
|
if (md->attribute & EFI_MEMORY_MORE_RELIABLE) {
|
|
|
|
memblock_mark_mirror(start, size);
|
|
|
|
mirror_size += size;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (mirror_size)
|
|
|
|
pr_info("Memory: %lldM/%lldM mirrored memory\n",
|
|
|
|
mirror_size>>20, total_size>>20);
|
|
|
|
}
|
|
|
|
|
2008-05-14 15:15:58 +00:00
|
|
|
/*
|
|
|
|
* Tell the kernel about the EFI memory map. This might include
|
|
|
|
* more than the max 128 entries that can fit in the e820 legacy
|
|
|
|
* (zeropage) memory map.
|
|
|
|
*/
|
|
|
|
|
2008-06-25 12:44:46 +00:00
|
|
|
static void __init do_add_efi_memmap(void)
|
2008-05-14 15:15:58 +00:00
|
|
|
{
|
2016-04-25 20:06:38 +00:00
|
|
|
efi_memory_desc_t *md;
|
2008-05-14 15:15:58 +00:00
|
|
|
|
2016-04-25 20:06:38 +00:00
|
|
|
for_each_efi_memory_desc(md) {
|
2008-05-14 15:15:58 +00:00
|
|
|
unsigned long long start = md->phys_addr;
|
|
|
|
unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
|
|
|
|
int e820_type;
|
|
|
|
|
2009-06-16 21:43:40 +00:00
|
|
|
switch (md->type) {
|
|
|
|
case EFI_LOADER_CODE:
|
|
|
|
case EFI_LOADER_DATA:
|
|
|
|
case EFI_BOOT_SERVICES_CODE:
|
|
|
|
case EFI_BOOT_SERVICES_DATA:
|
|
|
|
case EFI_CONVENTIONAL_MEMORY:
|
|
|
|
if (md->attribute & EFI_MEMORY_WB)
|
2017-01-28 16:09:33 +00:00
|
|
|
e820_type = E820_TYPE_RAM;
|
2009-06-16 21:43:40 +00:00
|
|
|
else
|
2017-01-28 16:09:33 +00:00
|
|
|
e820_type = E820_TYPE_RESERVED;
|
2009-06-16 21:43:40 +00:00
|
|
|
break;
|
|
|
|
case EFI_ACPI_RECLAIM_MEMORY:
|
2017-01-28 16:09:33 +00:00
|
|
|
e820_type = E820_TYPE_ACPI;
|
2009-06-16 21:43:40 +00:00
|
|
|
break;
|
|
|
|
case EFI_ACPI_MEMORY_NVS:
|
2017-01-28 16:09:33 +00:00
|
|
|
e820_type = E820_TYPE_NVS;
|
2009-06-16 21:43:40 +00:00
|
|
|
break;
|
|
|
|
case EFI_UNUSABLE_MEMORY:
|
2017-01-28 16:09:33 +00:00
|
|
|
e820_type = E820_TYPE_UNUSABLE;
|
2009-06-16 21:43:40 +00:00
|
|
|
break;
|
2015-04-03 16:05:28 +00:00
|
|
|
case EFI_PERSISTENT_MEMORY:
|
2017-01-28 16:09:33 +00:00
|
|
|
e820_type = E820_TYPE_PMEM;
|
2015-04-03 16:05:28 +00:00
|
|
|
break;
|
2009-06-16 21:43:40 +00:00
|
|
|
default:
|
|
|
|
/*
|
|
|
|
* EFI_RESERVED_TYPE EFI_RUNTIME_SERVICES_CODE
|
|
|
|
* EFI_RUNTIME_SERVICES_DATA EFI_MEMORY_MAPPED_IO
|
|
|
|
* EFI_MEMORY_MAPPED_IO_PORT_SPACE EFI_PAL_CODE
|
|
|
|
*/
|
2017-01-28 16:09:33 +00:00
|
|
|
e820_type = E820_TYPE_RESERVED;
|
2009-06-16 21:43:40 +00:00
|
|
|
break;
|
|
|
|
}
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_add(start, size, e820_type);
|
2008-05-14 15:15:58 +00:00
|
|
|
}
|
2017-01-28 13:09:20 +00:00
|
|
|
e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
|
2008-05-14 15:15:58 +00:00
|
|
|
}
|
|
|
|
|
2012-02-12 21:24:29 +00:00
|
|
|
int __init efi_memblock_x86_reserve_range(void)
|
2008-06-02 06:26:21 +00:00
|
|
|
{
|
2013-03-01 16:07:44 +00:00
|
|
|
struct efi_info *e = &boot_params.efi_info;
|
2016-02-26 21:22:05 +00:00
|
|
|
struct efi_memory_map_data data;
|
2015-10-23 09:48:16 +00:00
|
|
|
phys_addr_t pmap;
|
2016-02-26 21:22:05 +00:00
|
|
|
int rv;
|
2008-06-02 06:26:21 +00:00
|
|
|
|
2014-06-30 17:52:58 +00:00
|
|
|
if (efi_enabled(EFI_PARAVIRT))
|
|
|
|
return 0;
|
|
|
|
|
2008-06-22 14:22:02 +00:00
|
|
|
#ifdef CONFIG_X86_32
|
2012-02-12 21:24:29 +00:00
|
|
|
/* Can't handle data above 4GB at this time */
|
2013-03-01 16:07:44 +00:00
|
|
|
if (e->efi_memmap_hi) {
|
2012-02-12 21:24:29 +00:00
|
|
|
pr_err("Memory map is above 4GB, disabling EFI.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2013-03-01 16:07:44 +00:00
|
|
|
pmap = e->efi_memmap;
|
2008-06-22 14:22:02 +00:00
|
|
|
#else
|
2013-03-01 16:07:44 +00:00
|
|
|
pmap = (e->efi_memmap | ((__u64)e->efi_memmap_hi << 32));
|
2008-06-02 06:26:21 +00:00
|
|
|
#endif
|
2016-02-26 21:22:05 +00:00
|
|
|
data.phys_map = pmap;
|
|
|
|
data.size = e->efi_memmap_size;
|
|
|
|
data.desc_size = e->efi_memdesc_size;
|
|
|
|
data.desc_version = e->efi_memdesc_version;
|
|
|
|
|
|
|
|
rv = efi_memmap_init_early(&data);
|
|
|
|
if (rv)
|
|
|
|
return rv;
|
|
|
|
|
|
|
|
if (add_efi_memmap)
|
|
|
|
do_add_efi_memmap();
|
2012-02-12 21:24:29 +00:00
|
|
|
|
2016-04-25 20:06:40 +00:00
|
|
|
WARN(efi.memmap.desc_version != 1,
|
|
|
|
"Unexpected EFI_MEMORY_DESCRIPTOR version %ld",
|
|
|
|
efi.memmap.desc_version);
|
|
|
|
|
2016-04-25 20:06:39 +00:00
|
|
|
memblock_reserve(pmap, efi.memmap.nr_map * efi.memmap.desc_size);
|
2013-09-05 10:34:55 +00:00
|
|
|
|
2012-02-12 21:24:29 +00:00
|
|
|
return 0;
|
2008-06-02 06:26:21 +00:00
|
|
|
}
|
|
|
|
|
efi/x86: Prune invalid memory map entries and fix boot regression
Some machines, such as the Lenovo ThinkPad W541 with firmware GNET80WW
(2.28), include memory map entries with phys_addr=0x0 and num_pages=0.
These machines fail to boot after the following commit,
commit 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()")
Fix this by removing such bogus entries from the memory map.
Furthermore, currently the log output for this case (with efi=debug)
looks like:
[ 0.000000] efi: mem45: [Reserved | | | | | | | | | | | | ] range=[0x0000000000000000-0xffffffffffffffff] (0MB)
This is clearly wrong, and also not as informative as it could be. This
patch changes it so that if we find obviously invalid memory map
entries, we print an error and skip those entries. It also detects the
display of the address range calculation overflow, so the new output is:
[ 0.000000] efi: [Firmware Bug]: Invalid EFI memory map entries:
[ 0.000000] efi: mem45: [Reserved | | | | | | | | | | | | ] range=[0x0000000000000000-0x0000000000000000] (invalid)
It also detects memory map sizes that would overflow the physical
address, for example phys_addr=0xfffffffffffff000 and
num_pages=0x0200000000000001, and prints:
[ 0.000000] efi: [Firmware Bug]: Invalid EFI memory map entries:
[ 0.000000] efi: mem45: [Reserved | | | | | | | | | | | | ] range=[phys_addr=0xfffffffffffff000-0x20ffffffffffffffff] (invalid)
It then removes these entries from the memory map.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[ardb: refactor for clarity with no functional changes, avoid PAGE_SHIFT]
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
[Matt: Include bugzilla info in commit log]
Cc: <stable@vger.kernel.org> # v4.9+
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=191121
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-12-12 23:42:28 +00:00
|
|
|
#define OVERFLOW_ADDR_SHIFT (64 - EFI_PAGE_SHIFT)
|
|
|
|
#define OVERFLOW_ADDR_MASK (U64_MAX << OVERFLOW_ADDR_SHIFT)
|
|
|
|
#define U64_HIGH_BIT (~(U64_MAX >> 1))
|
|
|
|
|
|
|
|
static bool __init efi_memmap_entry_valid(const efi_memory_desc_t *md, int i)
|
|
|
|
{
|
|
|
|
u64 end = (md->num_pages << EFI_PAGE_SHIFT) + md->phys_addr - 1;
|
|
|
|
u64 end_hi = 0;
|
|
|
|
char buf[64];
|
|
|
|
|
|
|
|
if (md->num_pages == 0) {
|
|
|
|
end = 0;
|
|
|
|
} else if (md->num_pages > EFI_PAGES_MAX ||
|
|
|
|
EFI_PAGES_MAX - md->num_pages <
|
|
|
|
(md->phys_addr >> EFI_PAGE_SHIFT)) {
|
|
|
|
end_hi = (md->num_pages & OVERFLOW_ADDR_MASK)
|
|
|
|
>> OVERFLOW_ADDR_SHIFT;
|
|
|
|
|
|
|
|
if ((md->phys_addr & U64_HIGH_BIT) && !(end & U64_HIGH_BIT))
|
|
|
|
end_hi += 1;
|
|
|
|
} else {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
pr_warn_once(FW_BUG "Invalid EFI memory map entries:\n");
|
|
|
|
|
|
|
|
if (end_hi) {
|
|
|
|
pr_warn("mem%02u: %s range=[0x%016llx-0x%llx%016llx] (invalid)\n",
|
|
|
|
i, efi_md_typeattr_format(buf, sizeof(buf), md),
|
|
|
|
md->phys_addr, end_hi, end);
|
|
|
|
} else {
|
|
|
|
pr_warn("mem%02u: %s range=[0x%016llx-0x%016llx] (invalid)\n",
|
|
|
|
i, efi_md_typeattr_format(buf, sizeof(buf), md),
|
|
|
|
md->phys_addr, end);
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init efi_clean_memmap(void)
|
|
|
|
{
|
|
|
|
efi_memory_desc_t *out = efi.memmap.map;
|
|
|
|
const efi_memory_desc_t *in = out;
|
|
|
|
const efi_memory_desc_t *end = efi.memmap.map_end;
|
|
|
|
int i, n_removal;
|
|
|
|
|
|
|
|
for (i = n_removal = 0; in < end; i++) {
|
|
|
|
if (efi_memmap_entry_valid(in, i)) {
|
|
|
|
if (out != in)
|
|
|
|
memcpy(out, in, efi.memmap.desc_size);
|
|
|
|
out = (void *)out + efi.memmap.desc_size;
|
|
|
|
} else {
|
|
|
|
n_removal++;
|
|
|
|
}
|
|
|
|
in = (void *)in + efi.memmap.desc_size;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (n_removal > 0) {
|
|
|
|
u64 size = efi.memmap.nr_map - n_removal;
|
|
|
|
|
|
|
|
pr_warn("Removing %d invalid memory map entries.\n", n_removal);
|
|
|
|
efi_memmap_install(efi.memmap.phys_map, size);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-30 10:20:00 +00:00
|
|
|
void __init efi_print_memmap(void)
|
2008-01-30 12:31:19 +00:00
|
|
|
{
|
|
|
|
efi_memory_desc_t *md;
|
2016-04-25 20:06:38 +00:00
|
|
|
int i = 0;
|
2008-01-30 12:31:19 +00:00
|
|
|
|
2016-04-25 20:06:38 +00:00
|
|
|
for_each_efi_memory_desc(md) {
|
x86: efi: Format EFI memory type & attrs with efi_md_typeattr_format()
An example log excerpt demonstrating the change:
Before the patch:
> efi: mem00: type=7, attr=0xf, range=[0x0000000000000000-0x000000000009f000) (0MB)
> efi: mem01: type=2, attr=0xf, range=[0x000000000009f000-0x00000000000a0000) (0MB)
> efi: mem02: type=7, attr=0xf, range=[0x0000000000100000-0x0000000000400000) (3MB)
> efi: mem03: type=2, attr=0xf, range=[0x0000000000400000-0x0000000000800000) (4MB)
> efi: mem04: type=10, attr=0xf, range=[0x0000000000800000-0x0000000000808000) (0MB)
> efi: mem05: type=7, attr=0xf, range=[0x0000000000808000-0x0000000000810000) (0MB)
> efi: mem06: type=10, attr=0xf, range=[0x0000000000810000-0x0000000000900000) (0MB)
> efi: mem07: type=4, attr=0xf, range=[0x0000000000900000-0x0000000001100000) (8MB)
> efi: mem08: type=7, attr=0xf, range=[0x0000000001100000-0x0000000001400000) (3MB)
> efi: mem09: type=2, attr=0xf, range=[0x0000000001400000-0x0000000002613000) (18MB)
> efi: mem10: type=7, attr=0xf, range=[0x0000000002613000-0x0000000004000000) (25MB)
> efi: mem11: type=4, attr=0xf, range=[0x0000000004000000-0x0000000004020000) (0MB)
> efi: mem12: type=7, attr=0xf, range=[0x0000000004020000-0x00000000068ea000) (40MB)
> efi: mem13: type=2, attr=0xf, range=[0x00000000068ea000-0x00000000068f0000) (0MB)
> efi: mem14: type=3, attr=0xf, range=[0x00000000068f0000-0x0000000006c7b000) (3MB)
> efi: mem15: type=6, attr=0x800000000000000f, range=[0x0000000006c7b000-0x0000000006c7d000) (0MB)
> efi: mem16: type=5, attr=0x800000000000000f, range=[0x0000000006c7d000-0x0000000006c85000) (0MB)
> efi: mem17: type=6, attr=0x800000000000000f, range=[0x0000000006c85000-0x0000000006c87000) (0MB)
> efi: mem18: type=3, attr=0xf, range=[0x0000000006c87000-0x0000000006ca3000) (0MB)
> efi: mem19: type=6, attr=0x800000000000000f, range=[0x0000000006ca3000-0x0000000006ca6000) (0MB)
> efi: mem20: type=10, attr=0xf, range=[0x0000000006ca6000-0x0000000006cc6000) (0MB)
> efi: mem21: type=6, attr=0x800000000000000f, range=[0x0000000006cc6000-0x0000000006d95000) (0MB)
> efi: mem22: type=5, attr=0x800000000000000f, range=[0x0000000006d95000-0x0000000006e22000) (0MB)
> efi: mem23: type=7, attr=0xf, range=[0x0000000006e22000-0x0000000007165000) (3MB)
> efi: mem24: type=4, attr=0xf, range=[0x0000000007165000-0x0000000007d22000) (11MB)
> efi: mem25: type=7, attr=0xf, range=[0x0000000007d22000-0x0000000007d25000) (0MB)
> efi: mem26: type=3, attr=0xf, range=[0x0000000007d25000-0x0000000007ea2000) (1MB)
> efi: mem27: type=5, attr=0x800000000000000f, range=[0x0000000007ea2000-0x0000000007ed2000) (0MB)
> efi: mem28: type=6, attr=0x800000000000000f, range=[0x0000000007ed2000-0x0000000007ef6000) (0MB)
> efi: mem29: type=7, attr=0xf, range=[0x0000000007ef6000-0x0000000007f00000) (0MB)
> efi: mem30: type=9, attr=0xf, range=[0x0000000007f00000-0x0000000007f02000) (0MB)
> efi: mem31: type=10, attr=0xf, range=[0x0000000007f02000-0x0000000007f06000) (0MB)
> efi: mem32: type=4, attr=0xf, range=[0x0000000007f06000-0x0000000007fd0000) (0MB)
> efi: mem33: type=6, attr=0x800000000000000f, range=[0x0000000007fd0000-0x0000000007ff0000) (0MB)
> efi: mem34: type=7, attr=0xf, range=[0x0000000007ff0000-0x0000000008000000) (0MB)
After the patch:
> efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000000000000-0x000000000009f000) (0MB)
> efi: mem01: [Loader Data | | | | | |WB|WT|WC|UC] range=[0x000000000009f000-0x00000000000a0000) (0MB)
> efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000000100000-0x0000000000400000) (3MB)
> efi: mem03: [Loader Data | | | | | |WB|WT|WC|UC] range=[0x0000000000400000-0x0000000000800000) (4MB)
> efi: mem04: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x0000000000800000-0x0000000000808000) (0MB)
> efi: mem05: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000000808000-0x0000000000810000) (0MB)
> efi: mem06: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x0000000000810000-0x0000000000900000) (0MB)
> efi: mem07: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0000000000900000-0x0000000001100000) (8MB)
> efi: mem08: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000001100000-0x0000000001400000) (3MB)
> efi: mem09: [Loader Data | | | | | |WB|WT|WC|UC] range=[0x0000000001400000-0x0000000002613000) (18MB)
> efi: mem10: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000002613000-0x0000000004000000) (25MB)
> efi: mem11: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0000000004000000-0x0000000004020000) (0MB)
> efi: mem12: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000004020000-0x00000000068ea000) (40MB)
> efi: mem13: [Loader Data | | | | | |WB|WT|WC|UC] range=[0x00000000068ea000-0x00000000068f0000) (0MB)
> efi: mem14: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x00000000068f0000-0x0000000006c7b000) (3MB)
> efi: mem15: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006c7b000-0x0000000006c7d000) (0MB)
> efi: mem16: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006c7d000-0x0000000006c85000) (0MB)
> efi: mem17: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006c85000-0x0000000006c87000) (0MB)
> efi: mem18: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x0000000006c87000-0x0000000006ca3000) (0MB)
> efi: mem19: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006ca3000-0x0000000006ca6000) (0MB)
> efi: mem20: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x0000000006ca6000-0x0000000006cc6000) (0MB)
> efi: mem21: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006cc6000-0x0000000006d95000) (0MB)
> efi: mem22: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006d95000-0x0000000006e22000) (0MB)
> efi: mem23: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000006e22000-0x0000000007165000) (3MB)
> efi: mem24: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0000000007165000-0x0000000007d22000) (11MB)
> efi: mem25: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000007d22000-0x0000000007d25000) (0MB)
> efi: mem26: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x0000000007d25000-0x0000000007ea2000) (1MB)
> efi: mem27: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x0000000007ea2000-0x0000000007ed2000) (0MB)
> efi: mem28: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000007ed2000-0x0000000007ef6000) (0MB)
> efi: mem29: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000007ef6000-0x0000000007f00000) (0MB)
> efi: mem30: [ACPI Reclaim Memory| | | | | |WB|WT|WC|UC] range=[0x0000000007f00000-0x0000000007f02000) (0MB)
> efi: mem31: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x0000000007f02000-0x0000000007f06000) (0MB)
> efi: mem32: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0000000007f06000-0x0000000007fd0000) (0MB)
> efi: mem33: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000007fd0000-0x0000000007ff0000) (0MB)
> efi: mem34: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000007ff0000-0x0000000008000000) (0MB)
Both the type enum and the attribute bitmap are decoded, with the
additional benefit that the memory ranges line up as well.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2014-09-03 11:32:21 +00:00
|
|
|
char buf[64];
|
|
|
|
|
2016-02-01 22:07:05 +00:00
|
|
|
pr_info("mem%02u: %s range=[0x%016llx-0x%016llx] (%lluMB)\n",
|
2016-04-25 20:06:38 +00:00
|
|
|
i++, efi_md_typeattr_format(buf, sizeof(buf), md),
|
x86: efi: Format EFI memory type & attrs with efi_md_typeattr_format()
An example log excerpt demonstrating the change:
Before the patch:
> efi: mem00: type=7, attr=0xf, range=[0x0000000000000000-0x000000000009f000) (0MB)
> efi: mem01: type=2, attr=0xf, range=[0x000000000009f000-0x00000000000a0000) (0MB)
> efi: mem02: type=7, attr=0xf, range=[0x0000000000100000-0x0000000000400000) (3MB)
> efi: mem03: type=2, attr=0xf, range=[0x0000000000400000-0x0000000000800000) (4MB)
> efi: mem04: type=10, attr=0xf, range=[0x0000000000800000-0x0000000000808000) (0MB)
> efi: mem05: type=7, attr=0xf, range=[0x0000000000808000-0x0000000000810000) (0MB)
> efi: mem06: type=10, attr=0xf, range=[0x0000000000810000-0x0000000000900000) (0MB)
> efi: mem07: type=4, attr=0xf, range=[0x0000000000900000-0x0000000001100000) (8MB)
> efi: mem08: type=7, attr=0xf, range=[0x0000000001100000-0x0000000001400000) (3MB)
> efi: mem09: type=2, attr=0xf, range=[0x0000000001400000-0x0000000002613000) (18MB)
> efi: mem10: type=7, attr=0xf, range=[0x0000000002613000-0x0000000004000000) (25MB)
> efi: mem11: type=4, attr=0xf, range=[0x0000000004000000-0x0000000004020000) (0MB)
> efi: mem12: type=7, attr=0xf, range=[0x0000000004020000-0x00000000068ea000) (40MB)
> efi: mem13: type=2, attr=0xf, range=[0x00000000068ea000-0x00000000068f0000) (0MB)
> efi: mem14: type=3, attr=0xf, range=[0x00000000068f0000-0x0000000006c7b000) (3MB)
> efi: mem15: type=6, attr=0x800000000000000f, range=[0x0000000006c7b000-0x0000000006c7d000) (0MB)
> efi: mem16: type=5, attr=0x800000000000000f, range=[0x0000000006c7d000-0x0000000006c85000) (0MB)
> efi: mem17: type=6, attr=0x800000000000000f, range=[0x0000000006c85000-0x0000000006c87000) (0MB)
> efi: mem18: type=3, attr=0xf, range=[0x0000000006c87000-0x0000000006ca3000) (0MB)
> efi: mem19: type=6, attr=0x800000000000000f, range=[0x0000000006ca3000-0x0000000006ca6000) (0MB)
> efi: mem20: type=10, attr=0xf, range=[0x0000000006ca6000-0x0000000006cc6000) (0MB)
> efi: mem21: type=6, attr=0x800000000000000f, range=[0x0000000006cc6000-0x0000000006d95000) (0MB)
> efi: mem22: type=5, attr=0x800000000000000f, range=[0x0000000006d95000-0x0000000006e22000) (0MB)
> efi: mem23: type=7, attr=0xf, range=[0x0000000006e22000-0x0000000007165000) (3MB)
> efi: mem24: type=4, attr=0xf, range=[0x0000000007165000-0x0000000007d22000) (11MB)
> efi: mem25: type=7, attr=0xf, range=[0x0000000007d22000-0x0000000007d25000) (0MB)
> efi: mem26: type=3, attr=0xf, range=[0x0000000007d25000-0x0000000007ea2000) (1MB)
> efi: mem27: type=5, attr=0x800000000000000f, range=[0x0000000007ea2000-0x0000000007ed2000) (0MB)
> efi: mem28: type=6, attr=0x800000000000000f, range=[0x0000000007ed2000-0x0000000007ef6000) (0MB)
> efi: mem29: type=7, attr=0xf, range=[0x0000000007ef6000-0x0000000007f00000) (0MB)
> efi: mem30: type=9, attr=0xf, range=[0x0000000007f00000-0x0000000007f02000) (0MB)
> efi: mem31: type=10, attr=0xf, range=[0x0000000007f02000-0x0000000007f06000) (0MB)
> efi: mem32: type=4, attr=0xf, range=[0x0000000007f06000-0x0000000007fd0000) (0MB)
> efi: mem33: type=6, attr=0x800000000000000f, range=[0x0000000007fd0000-0x0000000007ff0000) (0MB)
> efi: mem34: type=7, attr=0xf, range=[0x0000000007ff0000-0x0000000008000000) (0MB)
After the patch:
> efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000000000000-0x000000000009f000) (0MB)
> efi: mem01: [Loader Data | | | | | |WB|WT|WC|UC] range=[0x000000000009f000-0x00000000000a0000) (0MB)
> efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000000100000-0x0000000000400000) (3MB)
> efi: mem03: [Loader Data | | | | | |WB|WT|WC|UC] range=[0x0000000000400000-0x0000000000800000) (4MB)
> efi: mem04: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x0000000000800000-0x0000000000808000) (0MB)
> efi: mem05: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000000808000-0x0000000000810000) (0MB)
> efi: mem06: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x0000000000810000-0x0000000000900000) (0MB)
> efi: mem07: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0000000000900000-0x0000000001100000) (8MB)
> efi: mem08: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000001100000-0x0000000001400000) (3MB)
> efi: mem09: [Loader Data | | | | | |WB|WT|WC|UC] range=[0x0000000001400000-0x0000000002613000) (18MB)
> efi: mem10: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000002613000-0x0000000004000000) (25MB)
> efi: mem11: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0000000004000000-0x0000000004020000) (0MB)
> efi: mem12: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000004020000-0x00000000068ea000) (40MB)
> efi: mem13: [Loader Data | | | | | |WB|WT|WC|UC] range=[0x00000000068ea000-0x00000000068f0000) (0MB)
> efi: mem14: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x00000000068f0000-0x0000000006c7b000) (3MB)
> efi: mem15: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006c7b000-0x0000000006c7d000) (0MB)
> efi: mem16: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006c7d000-0x0000000006c85000) (0MB)
> efi: mem17: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006c85000-0x0000000006c87000) (0MB)
> efi: mem18: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x0000000006c87000-0x0000000006ca3000) (0MB)
> efi: mem19: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006ca3000-0x0000000006ca6000) (0MB)
> efi: mem20: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x0000000006ca6000-0x0000000006cc6000) (0MB)
> efi: mem21: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006cc6000-0x0000000006d95000) (0MB)
> efi: mem22: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006d95000-0x0000000006e22000) (0MB)
> efi: mem23: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000006e22000-0x0000000007165000) (3MB)
> efi: mem24: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0000000007165000-0x0000000007d22000) (11MB)
> efi: mem25: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000007d22000-0x0000000007d25000) (0MB)
> efi: mem26: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x0000000007d25000-0x0000000007ea2000) (1MB)
> efi: mem27: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x0000000007ea2000-0x0000000007ed2000) (0MB)
> efi: mem28: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000007ed2000-0x0000000007ef6000) (0MB)
> efi: mem29: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000007ef6000-0x0000000007f00000) (0MB)
> efi: mem30: [ACPI Reclaim Memory| | | | | |WB|WT|WC|UC] range=[0x0000000007f00000-0x0000000007f02000) (0MB)
> efi: mem31: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x0000000007f02000-0x0000000007f06000) (0MB)
> efi: mem32: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0000000007f06000-0x0000000007fd0000) (0MB)
> efi: mem33: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000007fd0000-0x0000000007ff0000) (0MB)
> efi: mem34: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000007ff0000-0x0000000008000000) (0MB)
Both the type enum and the attribute bitmap are decoded, with the
additional benefit that the memory ranges line up as well.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2014-09-03 11:32:21 +00:00
|
|
|
md->phys_addr,
|
2016-02-01 22:07:05 +00:00
|
|
|
md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT) - 1,
|
2008-01-30 12:31:19 +00:00
|
|
|
(md->num_pages >> (20 - EFI_PAGE_SHIFT)));
|
|
|
|
}
|
2013-10-31 16:24:59 +00:00
|
|
|
}
|
2008-01-30 12:31:19 +00:00
|
|
|
|
2012-02-12 21:24:28 +00:00
|
|
|
static int __init efi_systab_init(void *phys)
|
2008-01-30 12:31:19 +00:00
|
|
|
{
|
2012-11-14 09:42:35 +00:00
|
|
|
if (efi_enabled(EFI_64BIT)) {
|
2012-02-12 21:24:29 +00:00
|
|
|
efi_system_table_64_t *systab64;
|
2013-12-20 10:02:19 +00:00
|
|
|
struct efi_setup_data *data = NULL;
|
2012-02-12 21:24:29 +00:00
|
|
|
u64 tmp = 0;
|
|
|
|
|
2013-12-20 10:02:19 +00:00
|
|
|
if (efi_setup) {
|
|
|
|
data = early_memremap(efi_setup, sizeof(*data));
|
|
|
|
if (!data)
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
2014-06-30 17:52:56 +00:00
|
|
|
systab64 = early_memremap((unsigned long)phys,
|
2012-02-12 21:24:29 +00:00
|
|
|
sizeof(*systab64));
|
|
|
|
if (systab64 == NULL) {
|
|
|
|
pr_err("Couldn't map the system table!\n");
|
2013-12-20 10:02:19 +00:00
|
|
|
if (data)
|
2014-06-30 17:52:56 +00:00
|
|
|
early_memunmap(data, sizeof(*data));
|
2012-02-12 21:24:29 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
efi_systab.hdr = systab64->hdr;
|
2013-12-20 10:02:19 +00:00
|
|
|
efi_systab.fw_vendor = data ? (unsigned long)data->fw_vendor :
|
|
|
|
systab64->fw_vendor;
|
|
|
|
tmp |= data ? data->fw_vendor : systab64->fw_vendor;
|
2012-02-12 21:24:29 +00:00
|
|
|
efi_systab.fw_revision = systab64->fw_revision;
|
|
|
|
efi_systab.con_in_handle = systab64->con_in_handle;
|
|
|
|
tmp |= systab64->con_in_handle;
|
|
|
|
efi_systab.con_in = systab64->con_in;
|
|
|
|
tmp |= systab64->con_in;
|
|
|
|
efi_systab.con_out_handle = systab64->con_out_handle;
|
|
|
|
tmp |= systab64->con_out_handle;
|
|
|
|
efi_systab.con_out = systab64->con_out;
|
|
|
|
tmp |= systab64->con_out;
|
|
|
|
efi_systab.stderr_handle = systab64->stderr_handle;
|
|
|
|
tmp |= systab64->stderr_handle;
|
|
|
|
efi_systab.stderr = systab64->stderr;
|
|
|
|
tmp |= systab64->stderr;
|
2013-12-20 10:02:19 +00:00
|
|
|
efi_systab.runtime = data ?
|
|
|
|
(void *)(unsigned long)data->runtime :
|
|
|
|
(void *)(unsigned long)systab64->runtime;
|
|
|
|
tmp |= data ? data->runtime : systab64->runtime;
|
2012-02-12 21:24:29 +00:00
|
|
|
efi_systab.boottime = (void *)(unsigned long)systab64->boottime;
|
|
|
|
tmp |= systab64->boottime;
|
|
|
|
efi_systab.nr_tables = systab64->nr_tables;
|
2013-12-20 10:02:19 +00:00
|
|
|
efi_systab.tables = data ? (unsigned long)data->tables :
|
|
|
|
systab64->tables;
|
|
|
|
tmp |= data ? data->tables : systab64->tables;
|
2012-02-12 21:24:29 +00:00
|
|
|
|
2014-06-30 17:52:56 +00:00
|
|
|
early_memunmap(systab64, sizeof(*systab64));
|
2013-12-20 10:02:19 +00:00
|
|
|
if (data)
|
2014-06-30 17:52:56 +00:00
|
|
|
early_memunmap(data, sizeof(*data));
|
2012-02-12 21:24:29 +00:00
|
|
|
#ifdef CONFIG_X86_32
|
|
|
|
if (tmp >> 32) {
|
|
|
|
pr_err("EFI data located above 4GB, disabling EFI.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
} else {
|
|
|
|
efi_system_table_32_t *systab32;
|
|
|
|
|
2014-06-30 17:52:56 +00:00
|
|
|
systab32 = early_memremap((unsigned long)phys,
|
2012-02-12 21:24:29 +00:00
|
|
|
sizeof(*systab32));
|
|
|
|
if (systab32 == NULL) {
|
|
|
|
pr_err("Couldn't map the system table!\n");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
efi_systab.hdr = systab32->hdr;
|
|
|
|
efi_systab.fw_vendor = systab32->fw_vendor;
|
|
|
|
efi_systab.fw_revision = systab32->fw_revision;
|
|
|
|
efi_systab.con_in_handle = systab32->con_in_handle;
|
|
|
|
efi_systab.con_in = systab32->con_in;
|
|
|
|
efi_systab.con_out_handle = systab32->con_out_handle;
|
|
|
|
efi_systab.con_out = systab32->con_out;
|
|
|
|
efi_systab.stderr_handle = systab32->stderr_handle;
|
|
|
|
efi_systab.stderr = systab32->stderr;
|
|
|
|
efi_systab.runtime = (void *)(unsigned long)systab32->runtime;
|
|
|
|
efi_systab.boottime = (void *)(unsigned long)systab32->boottime;
|
|
|
|
efi_systab.nr_tables = systab32->nr_tables;
|
|
|
|
efi_systab.tables = systab32->tables;
|
|
|
|
|
2014-06-30 17:52:56 +00:00
|
|
|
early_memunmap(systab32, sizeof(*systab32));
|
2012-02-12 21:24:28 +00:00
|
|
|
}
|
2012-02-12 21:24:29 +00:00
|
|
|
|
2008-01-30 12:31:19 +00:00
|
|
|
efi.systab = &efi_systab;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Verify the EFI Table
|
|
|
|
*/
|
2012-02-12 21:24:28 +00:00
|
|
|
if (efi.systab->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE) {
|
2012-02-12 21:24:26 +00:00
|
|
|
pr_err("System table signature incorrect!\n");
|
2012-02-12 21:24:28 +00:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
2008-01-30 12:31:19 +00:00
|
|
|
if ((efi.systab->hdr.revision >> 16) == 0)
|
2014-01-04 00:08:48 +00:00
|
|
|
pr_err("Warning: System table version %d.%02d, expected 1.00 or greater!\n",
|
2008-01-30 12:31:19 +00:00
|
|
|
efi.systab->hdr.revision >> 16,
|
|
|
|
efi.systab->hdr.revision & 0xffff);
|
2012-02-12 21:24:28 +00:00
|
|
|
|
|
|
|
return 0;
|
2012-02-12 21:24:25 +00:00
|
|
|
}
|
2008-01-30 12:31:19 +00:00
|
|
|
|
2014-01-10 18:48:30 +00:00
|
|
|
static int __init efi_runtime_init32(void)
|
2012-02-12 21:24:25 +00:00
|
|
|
{
|
2014-01-10 18:48:30 +00:00
|
|
|
efi_runtime_services_32_t *runtime;
|
|
|
|
|
2014-06-30 17:52:56 +00:00
|
|
|
runtime = early_memremap((unsigned long)efi.systab->runtime,
|
2014-01-10 18:48:30 +00:00
|
|
|
sizeof(efi_runtime_services_32_t));
|
|
|
|
if (!runtime) {
|
|
|
|
pr_err("Could not map the runtime service table!\n");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
2008-01-30 12:31:19 +00:00
|
|
|
|
|
|
|
/*
|
2014-09-07 17:42:16 +00:00
|
|
|
* We will only need *early* access to the SetVirtualAddressMap
|
|
|
|
* EFI runtime service. All other runtime services will be called
|
|
|
|
* via the virtual mapping.
|
2008-01-30 12:31:19 +00:00
|
|
|
*/
|
2014-01-10 18:48:30 +00:00
|
|
|
efi_phys.set_virtual_address_map =
|
|
|
|
(efi_set_virtual_address_map_t *)
|
|
|
|
(unsigned long)runtime->set_virtual_address_map;
|
2014-06-30 17:52:56 +00:00
|
|
|
early_memunmap(runtime, sizeof(efi_runtime_services_32_t));
|
2014-01-10 18:48:30 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __init efi_runtime_init64(void)
|
|
|
|
{
|
|
|
|
efi_runtime_services_64_t *runtime;
|
|
|
|
|
2014-06-30 17:52:56 +00:00
|
|
|
runtime = early_memremap((unsigned long)efi.systab->runtime,
|
2014-01-10 18:48:30 +00:00
|
|
|
sizeof(efi_runtime_services_64_t));
|
2012-02-12 21:24:28 +00:00
|
|
|
if (!runtime) {
|
2012-02-12 21:24:26 +00:00
|
|
|
pr_err("Could not map the runtime service table!\n");
|
2012-02-12 21:24:28 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
2014-01-10 18:48:30 +00:00
|
|
|
|
2012-02-12 21:24:28 +00:00
|
|
|
/*
|
2014-09-07 17:42:16 +00:00
|
|
|
* We will only need *early* access to the SetVirtualAddressMap
|
|
|
|
* EFI runtime service. All other runtime services will be called
|
|
|
|
* via the virtual mapping.
|
2012-02-12 21:24:28 +00:00
|
|
|
*/
|
|
|
|
efi_phys.set_virtual_address_map =
|
2014-01-10 18:48:30 +00:00
|
|
|
(efi_set_virtual_address_map_t *)
|
|
|
|
(unsigned long)runtime->set_virtual_address_map;
|
2014-06-30 17:52:56 +00:00
|
|
|
early_memunmap(runtime, sizeof(efi_runtime_services_64_t));
|
2014-01-10 18:48:30 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __init efi_runtime_init(void)
|
|
|
|
{
|
|
|
|
int rv;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check out the runtime services table. We need to map
|
|
|
|
* the runtime services table so that we can grab the physical
|
|
|
|
* address of several of the EFI runtime functions, needed to
|
|
|
|
* set the firmware into virtual mode.
|
2014-06-30 17:52:58 +00:00
|
|
|
*
|
|
|
|
* When EFI_PARAVIRT is in force then we could not map runtime
|
|
|
|
* service memory region because we do not have direct access to it.
|
|
|
|
* However, runtime services are available through proxy functions
|
|
|
|
* (e.g. in case of Xen dom0 EFI implementation they call special
|
|
|
|
* hypercall which executes relevant EFI functions) and that is why
|
|
|
|
* they are always enabled.
|
2014-01-10 18:48:30 +00:00
|
|
|
*/
|
|
|
|
|
2014-06-30 17:52:58 +00:00
|
|
|
if (!efi_enabled(EFI_PARAVIRT)) {
|
|
|
|
if (efi_enabled(EFI_64BIT))
|
|
|
|
rv = efi_runtime_init64();
|
|
|
|
else
|
|
|
|
rv = efi_runtime_init32();
|
|
|
|
|
|
|
|
if (rv)
|
|
|
|
return rv;
|
|
|
|
}
|
2012-02-12 21:24:28 +00:00
|
|
|
|
2014-01-15 13:36:33 +00:00
|
|
|
set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
|
|
|
|
2012-02-12 21:24:28 +00:00
|
|
|
return 0;
|
2012-02-12 21:24:25 +00:00
|
|
|
}
|
2008-01-30 12:31:19 +00:00
|
|
|
|
2012-02-12 21:24:25 +00:00
|
|
|
void __init efi_init(void)
|
|
|
|
{
|
|
|
|
efi_char16_t *c16;
|
|
|
|
char vendor[100] = "unknown";
|
|
|
|
int i = 0;
|
|
|
|
void *tmp;
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86_32
|
2012-02-12 21:24:29 +00:00
|
|
|
if (boot_params.efi_info.efi_systab_hi ||
|
|
|
|
boot_params.efi_info.efi_memmap_hi) {
|
|
|
|
pr_info("Table located above 4GB, disabling EFI.\n");
|
|
|
|
return;
|
|
|
|
}
|
2012-02-12 21:24:25 +00:00
|
|
|
efi_phys.systab = (efi_system_table_t *)boot_params.efi_info.efi_systab;
|
|
|
|
#else
|
|
|
|
efi_phys.systab = (efi_system_table_t *)
|
2012-02-12 21:24:29 +00:00
|
|
|
(boot_params.efi_info.efi_systab |
|
|
|
|
((__u64)boot_params.efi_info.efi_systab_hi<<32));
|
2012-02-12 21:24:25 +00:00
|
|
|
#endif
|
|
|
|
|
2012-11-14 09:42:35 +00:00
|
|
|
if (efi_systab_init(efi_phys.systab))
|
2012-02-12 21:24:28 +00:00
|
|
|
return;
|
2012-11-14 09:42:35 +00:00
|
|
|
|
2013-12-20 10:02:17 +00:00
|
|
|
efi.config_table = (unsigned long)efi.systab->tables;
|
|
|
|
efi.fw_vendor = (unsigned long)efi.systab->fw_vendor;
|
|
|
|
efi.runtime = (unsigned long)efi.systab->runtime;
|
|
|
|
|
2012-02-12 21:24:25 +00:00
|
|
|
/*
|
|
|
|
* Show what we know for posterity
|
|
|
|
*/
|
2014-06-30 17:52:56 +00:00
|
|
|
c16 = tmp = early_memremap(efi.systab->fw_vendor, 2);
|
2012-02-12 21:24:25 +00:00
|
|
|
if (c16) {
|
|
|
|
for (i = 0; i < sizeof(vendor) - 1 && *c16; ++i)
|
|
|
|
vendor[i] = *c16++;
|
|
|
|
vendor[i] = '\0';
|
|
|
|
} else
|
2012-02-12 21:24:26 +00:00
|
|
|
pr_err("Could not map the firmware vendor!\n");
|
2014-06-30 17:52:56 +00:00
|
|
|
early_memunmap(tmp, 2);
|
2012-02-12 21:24:25 +00:00
|
|
|
|
2012-02-12 21:24:26 +00:00
|
|
|
pr_info("EFI v%u.%.02u by %s\n",
|
|
|
|
efi.systab->hdr.revision >> 16,
|
|
|
|
efi.systab->hdr.revision & 0xffff, vendor);
|
2012-02-12 21:24:25 +00:00
|
|
|
|
2013-12-20 10:02:19 +00:00
|
|
|
if (efi_reuse_config(efi.systab->tables, efi.systab->nr_tables))
|
|
|
|
return;
|
|
|
|
|
2013-09-05 10:34:54 +00:00
|
|
|
if (efi_config_init(arch_tables))
|
2012-02-12 21:24:28 +00:00
|
|
|
return;
|
2012-11-14 09:42:35 +00:00
|
|
|
|
2012-02-12 21:24:29 +00:00
|
|
|
/*
|
|
|
|
* Note: We currently don't support runtime services on an EFI
|
|
|
|
* that doesn't match the kernel 32/64-bit mode.
|
|
|
|
*/
|
|
|
|
|
2014-01-10 18:52:06 +00:00
|
|
|
if (!efi_runtime_supported())
|
2012-02-12 21:24:29 +00:00
|
|
|
pr_info("No EFI runtime due to 32/64-bit mismatch with kernel\n");
|
2012-11-14 09:42:35 +00:00
|
|
|
else {
|
2016-02-26 21:22:05 +00:00
|
|
|
if (efi_runtime_disabled() || efi_runtime_init()) {
|
|
|
|
efi_memmap_unmap();
|
2012-11-14 09:42:35 +00:00
|
|
|
return;
|
2016-02-26 21:22:05 +00:00
|
|
|
}
|
2012-02-12 21:24:28 +00:00
|
|
|
}
|
2012-11-14 09:42:35 +00:00
|
|
|
|
efi/x86: Prune invalid memory map entries and fix boot regression
Some machines, such as the Lenovo ThinkPad W541 with firmware GNET80WW
(2.28), include memory map entries with phys_addr=0x0 and num_pages=0.
These machines fail to boot after the following commit,
commit 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()")
Fix this by removing such bogus entries from the memory map.
Furthermore, currently the log output for this case (with efi=debug)
looks like:
[ 0.000000] efi: mem45: [Reserved | | | | | | | | | | | | ] range=[0x0000000000000000-0xffffffffffffffff] (0MB)
This is clearly wrong, and also not as informative as it could be. This
patch changes it so that if we find obviously invalid memory map
entries, we print an error and skip those entries. It also detects the
display of the address range calculation overflow, so the new output is:
[ 0.000000] efi: [Firmware Bug]: Invalid EFI memory map entries:
[ 0.000000] efi: mem45: [Reserved | | | | | | | | | | | | ] range=[0x0000000000000000-0x0000000000000000] (invalid)
It also detects memory map sizes that would overflow the physical
address, for example phys_addr=0xfffffffffffff000 and
num_pages=0x0200000000000001, and prints:
[ 0.000000] efi: [Firmware Bug]: Invalid EFI memory map entries:
[ 0.000000] efi: mem45: [Reserved | | | | | | | | | | | | ] range=[phys_addr=0xfffffffffffff000-0x20ffffffffffffffff] (invalid)
It then removes these entries from the memory map.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[ardb: refactor for clarity with no functional changes, avoid PAGE_SHIFT]
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
[Matt: Include bugzilla info in commit log]
Cc: <stable@vger.kernel.org> # v4.9+
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=191121
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-12-12 23:42:28 +00:00
|
|
|
efi_clean_memmap();
|
|
|
|
|
2015-02-05 10:44:41 +00:00
|
|
|
if (efi_enabled(EFI_DBG))
|
2015-09-30 10:20:00 +00:00
|
|
|
efi_print_memmap();
|
2008-01-30 12:31:19 +00:00
|
|
|
}
|
|
|
|
|
2012-09-29 00:57:05 +00:00
|
|
|
void __init efi_late_init(void)
|
|
|
|
{
|
|
|
|
efi_bgrt_init();
|
|
|
|
}
|
|
|
|
|
2011-05-05 19:19:43 +00:00
|
|
|
void __init efi_set_executable(efi_memory_desc_t *md, bool executable)
|
|
|
|
{
|
|
|
|
u64 addr, npages;
|
|
|
|
|
|
|
|
addr = md->virt_addr;
|
|
|
|
npages = md->num_pages;
|
|
|
|
|
|
|
|
memrange_efi_to_native(&addr, &npages);
|
|
|
|
|
|
|
|
if (executable)
|
|
|
|
set_memory_x(addr, npages);
|
|
|
|
else
|
|
|
|
set_memory_nx(addr, npages);
|
|
|
|
}
|
|
|
|
|
2014-02-14 07:24:24 +00:00
|
|
|
void __init runtime_code_page_mkexec(void)
|
2008-01-30 12:33:55 +00:00
|
|
|
{
|
|
|
|
efi_memory_desc_t *md;
|
|
|
|
|
|
|
|
/* Make EFI runtime service code area executable */
|
2016-04-25 20:06:38 +00:00
|
|
|
for_each_efi_memory_desc(md) {
|
2008-02-04 15:48:06 +00:00
|
|
|
if (md->type != EFI_RUNTIME_SERVICES_CODE)
|
|
|
|
continue;
|
|
|
|
|
2011-05-05 19:19:43 +00:00
|
|
|
efi_set_executable(md, true);
|
2008-01-30 12:33:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-09-07 17:42:17 +00:00
|
|
|
void __init efi_memory_uc(u64 addr, unsigned long size)
|
2012-10-19 12:25:46 +00:00
|
|
|
{
|
|
|
|
unsigned long page_shift = 1UL << EFI_PAGE_SHIFT;
|
|
|
|
u64 npages;
|
|
|
|
|
|
|
|
npages = round_up(size, page_shift) / page_shift;
|
|
|
|
memrange_efi_to_native(&addr, &npages);
|
|
|
|
set_memory_uc(addr, npages);
|
|
|
|
}
|
|
|
|
|
2013-10-31 16:25:08 +00:00
|
|
|
void __init old_map_region(efi_memory_desc_t *md)
|
|
|
|
{
|
|
|
|
u64 start_pfn, end_pfn, end;
|
|
|
|
unsigned long size;
|
|
|
|
void *va;
|
|
|
|
|
|
|
|
start_pfn = PFN_DOWN(md->phys_addr);
|
|
|
|
size = md->num_pages << PAGE_SHIFT;
|
|
|
|
end = md->phys_addr + size;
|
|
|
|
end_pfn = PFN_UP(end);
|
|
|
|
|
|
|
|
if (pfn_range_is_mapped(start_pfn, end_pfn)) {
|
|
|
|
va = __va(md->phys_addr);
|
|
|
|
|
|
|
|
if (!(md->attribute & EFI_MEMORY_WB))
|
|
|
|
efi_memory_uc((u64)(unsigned long)va, size);
|
|
|
|
} else
|
|
|
|
va = efi_ioremap(md->phys_addr, size,
|
|
|
|
md->type, md->attribute);
|
|
|
|
|
|
|
|
md->virt_addr = (u64) (unsigned long) va;
|
|
|
|
if (!va)
|
|
|
|
pr_err("ioremap of 0x%llX failed!\n",
|
|
|
|
(unsigned long long)md->phys_addr);
|
|
|
|
}
|
|
|
|
|
2013-12-20 10:02:16 +00:00
|
|
|
/* Merge contiguous regions of the same type and attribute */
|
|
|
|
static void __init efi_merge_regions(void)
|
2008-01-30 12:31:19 +00:00
|
|
|
{
|
2011-05-05 19:19:44 +00:00
|
|
|
efi_memory_desc_t *md, *prev_md = NULL;
|
|
|
|
|
2016-04-25 20:06:38 +00:00
|
|
|
for_each_efi_memory_desc(md) {
|
2011-05-05 19:19:44 +00:00
|
|
|
u64 prev_size;
|
|
|
|
|
|
|
|
if (!prev_md) {
|
|
|
|
prev_md = md;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (prev_md->type != md->type ||
|
|
|
|
prev_md->attribute != md->attribute) {
|
|
|
|
prev_md = md;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
prev_size = prev_md->num_pages << EFI_PAGE_SHIFT;
|
|
|
|
|
|
|
|
if (md->phys_addr == (prev_md->phys_addr + prev_size)) {
|
|
|
|
prev_md->num_pages += md->num_pages;
|
|
|
|
md->type = EFI_RESERVED_TYPE;
|
|
|
|
md->attribute = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
prev_md = md;
|
2013-12-20 10:02:16 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init get_systab_virt_addr(efi_memory_desc_t *md)
|
|
|
|
{
|
|
|
|
unsigned long size;
|
|
|
|
u64 end, systab;
|
2013-10-31 16:25:08 +00:00
|
|
|
|
2013-12-20 10:02:16 +00:00
|
|
|
size = md->num_pages << EFI_PAGE_SHIFT;
|
|
|
|
end = md->phys_addr + size;
|
|
|
|
systab = (u64)(unsigned long)efi_phys.systab;
|
|
|
|
if (md->phys_addr <= systab && systab < end) {
|
|
|
|
systab += md->virt_addr - md->phys_addr;
|
|
|
|
efi.systab = (efi_system_table_t *)(unsigned long)systab;
|
2011-05-05 19:19:44 +00:00
|
|
|
}
|
2013-12-20 10:02:16 +00:00
|
|
|
}
|
|
|
|
|
2014-01-18 11:48:17 +00:00
|
|
|
static void *realloc_pages(void *old_memmap, int old_shift)
|
|
|
|
{
|
|
|
|
void *ret;
|
|
|
|
|
|
|
|
ret = (void *)__get_free_pages(GFP_KERNEL, old_shift + 1);
|
|
|
|
if (!ret)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A first-time allocation doesn't have anything to copy.
|
|
|
|
*/
|
|
|
|
if (!old_memmap)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
memcpy(ret, old_memmap, PAGE_SIZE << old_shift);
|
|
|
|
|
|
|
|
out:
|
|
|
|
free_pages((unsigned long)old_memmap, old_shift);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down
Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
that signals that the firmware PE/COFF loader supports splitting
code and data sections of PE/COFF images into separate EFI
memory map entries. This allows the kernel to map those regions
with strict memory protections, e.g. EFI_MEMORY_RO for code,
EFI_MEMORY_XP for data, etc.
Unfortunately, an unwritten requirement of this new feature is
that the regions need to be mapped with the same offsets
relative to each other as observed in the EFI memory map. If
this is not done crashes like this may occur,
BUG: unable to handle kernel paging request at fffffffefe6086dd
IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
Call Trace:
[<ffffffff8104c90e>] efi_call+0x7e/0x100
[<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
[<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
[<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
[<ffffffff81f37e1b>] start_kernel+0x38a/0x417
[<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef
Here 0xfffffffefe6086dd refers to an address the firmware
expects to be mapped but which the OS never claimed was mapped.
The issue is that included in these regions are relative
addresses to other regions which were emitted by the firmware
toolchain before the "splitting" of sections occurred at
runtime.
Needless to say, we don't satisfy this unwritten requirement on
x86_64 and instead map the EFI memory map entries in reverse
order. The above crash is almost certainly triggerable with any
kernel newer than v3.13 because that's when we rewrote the EFI
runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi:
Runtime services virtual mapping"). For kernel versions before
v3.13 things may work by pure luck depending on the
fragmentation of the kernel virtual address space at the time we
map the EFI regions.
Instead of mapping the EFI memory map entries in reverse order,
where entry N has a higher virtual address than entry N+1, map
them in the same order as they appear in the EFI memory map to
preserve this relative offset between regions.
This patch has been kept as small as possible with the intention
that it should be applied aggressively to stable and
distribution kernels. It is very much a bugfix rather than
support for a new feature, since when EFI_PROPERTIES_TABLE is
enabled we must map things as outlined above to even boot - we
have no way of asking the firmware not to split the code/data
regions.
In fact, this patch doesn't even make use of the more strict
memory protections available in UEFI v2.5. That will come later.
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Chun-Yi <jlee@suse.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: James Bottomley <JBottomley@Odin.com>
Cc: Lee, Chun-Yi <jlee@suse.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-09-25 22:02:18 +00:00
|
|
|
/*
|
|
|
|
* Iterate the EFI memory map in reverse order because the regions
|
|
|
|
* will be mapped top-down. The end result is the same as if we had
|
|
|
|
* mapped things forward, but doesn't require us to change the
|
|
|
|
* existing implementation of efi_map_region().
|
|
|
|
*/
|
|
|
|
static inline void *efi_map_next_entry_reverse(void *entry)
|
|
|
|
{
|
|
|
|
/* Initial call */
|
|
|
|
if (!entry)
|
2016-04-25 20:06:39 +00:00
|
|
|
return efi.memmap.map_end - efi.memmap.desc_size;
|
x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down
Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
that signals that the firmware PE/COFF loader supports splitting
code and data sections of PE/COFF images into separate EFI
memory map entries. This allows the kernel to map those regions
with strict memory protections, e.g. EFI_MEMORY_RO for code,
EFI_MEMORY_XP for data, etc.
Unfortunately, an unwritten requirement of this new feature is
that the regions need to be mapped with the same offsets
relative to each other as observed in the EFI memory map. If
this is not done crashes like this may occur,
BUG: unable to handle kernel paging request at fffffffefe6086dd
IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
Call Trace:
[<ffffffff8104c90e>] efi_call+0x7e/0x100
[<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
[<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
[<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
[<ffffffff81f37e1b>] start_kernel+0x38a/0x417
[<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef
Here 0xfffffffefe6086dd refers to an address the firmware
expects to be mapped but which the OS never claimed was mapped.
The issue is that included in these regions are relative
addresses to other regions which were emitted by the firmware
toolchain before the "splitting" of sections occurred at
runtime.
Needless to say, we don't satisfy this unwritten requirement on
x86_64 and instead map the EFI memory map entries in reverse
order. The above crash is almost certainly triggerable with any
kernel newer than v3.13 because that's when we rewrote the EFI
runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi:
Runtime services virtual mapping"). For kernel versions before
v3.13 things may work by pure luck depending on the
fragmentation of the kernel virtual address space at the time we
map the EFI regions.
Instead of mapping the EFI memory map entries in reverse order,
where entry N has a higher virtual address than entry N+1, map
them in the same order as they appear in the EFI memory map to
preserve this relative offset between regions.
This patch has been kept as small as possible with the intention
that it should be applied aggressively to stable and
distribution kernels. It is very much a bugfix rather than
support for a new feature, since when EFI_PROPERTIES_TABLE is
enabled we must map things as outlined above to even boot - we
have no way of asking the firmware not to split the code/data
regions.
In fact, this patch doesn't even make use of the more strict
memory protections available in UEFI v2.5. That will come later.
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Chun-Yi <jlee@suse.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: James Bottomley <JBottomley@Odin.com>
Cc: Lee, Chun-Yi <jlee@suse.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-09-25 22:02:18 +00:00
|
|
|
|
2016-04-25 20:06:39 +00:00
|
|
|
entry -= efi.memmap.desc_size;
|
|
|
|
if (entry < efi.memmap.map)
|
x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down
Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
that signals that the firmware PE/COFF loader supports splitting
code and data sections of PE/COFF images into separate EFI
memory map entries. This allows the kernel to map those regions
with strict memory protections, e.g. EFI_MEMORY_RO for code,
EFI_MEMORY_XP for data, etc.
Unfortunately, an unwritten requirement of this new feature is
that the regions need to be mapped with the same offsets
relative to each other as observed in the EFI memory map. If
this is not done crashes like this may occur,
BUG: unable to handle kernel paging request at fffffffefe6086dd
IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
Call Trace:
[<ffffffff8104c90e>] efi_call+0x7e/0x100
[<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
[<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
[<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
[<ffffffff81f37e1b>] start_kernel+0x38a/0x417
[<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef
Here 0xfffffffefe6086dd refers to an address the firmware
expects to be mapped but which the OS never claimed was mapped.
The issue is that included in these regions are relative
addresses to other regions which were emitted by the firmware
toolchain before the "splitting" of sections occurred at
runtime.
Needless to say, we don't satisfy this unwritten requirement on
x86_64 and instead map the EFI memory map entries in reverse
order. The above crash is almost certainly triggerable with any
kernel newer than v3.13 because that's when we rewrote the EFI
runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi:
Runtime services virtual mapping"). For kernel versions before
v3.13 things may work by pure luck depending on the
fragmentation of the kernel virtual address space at the time we
map the EFI regions.
Instead of mapping the EFI memory map entries in reverse order,
where entry N has a higher virtual address than entry N+1, map
them in the same order as they appear in the EFI memory map to
preserve this relative offset between regions.
This patch has been kept as small as possible with the intention
that it should be applied aggressively to stable and
distribution kernels. It is very much a bugfix rather than
support for a new feature, since when EFI_PROPERTIES_TABLE is
enabled we must map things as outlined above to even boot - we
have no way of asking the firmware not to split the code/data
regions.
In fact, this patch doesn't even make use of the more strict
memory protections available in UEFI v2.5. That will come later.
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Chun-Yi <jlee@suse.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: James Bottomley <JBottomley@Odin.com>
Cc: Lee, Chun-Yi <jlee@suse.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-09-25 22:02:18 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* efi_map_next_entry - Return the next EFI memory map descriptor
|
|
|
|
* @entry: Previous EFI memory map descriptor
|
|
|
|
*
|
|
|
|
* This is a helper function to iterate over the EFI memory map, which
|
|
|
|
* we do in different orders depending on the current configuration.
|
|
|
|
*
|
|
|
|
* To begin traversing the memory map @entry must be %NULL.
|
|
|
|
*
|
|
|
|
* Returns %NULL when we reach the end of the memory map.
|
|
|
|
*/
|
|
|
|
static void *efi_map_next_entry(void *entry)
|
|
|
|
{
|
|
|
|
if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
|
|
|
|
/*
|
|
|
|
* Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE
|
|
|
|
* config table feature requires us to map all entries
|
|
|
|
* in the same order as they appear in the EFI memory
|
|
|
|
* map. That is to say, entry N must have a lower
|
|
|
|
* virtual address than entry N+1. This is because the
|
|
|
|
* firmware toolchain leaves relative references in
|
|
|
|
* the code/data sections, which are split and become
|
|
|
|
* separate EFI memory regions. Mapping things
|
|
|
|
* out-of-order leads to the firmware accessing
|
|
|
|
* unmapped addresses.
|
|
|
|
*
|
|
|
|
* Since we need to map things this way whether or not
|
|
|
|
* the kernel actually makes use of
|
|
|
|
* EFI_PROPERTIES_TABLE, let's just switch to this
|
|
|
|
* scheme by default for 64-bit.
|
|
|
|
*/
|
|
|
|
return efi_map_next_entry_reverse(entry);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Initial call */
|
|
|
|
if (!entry)
|
2016-04-25 20:06:39 +00:00
|
|
|
return efi.memmap.map;
|
x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down
Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
that signals that the firmware PE/COFF loader supports splitting
code and data sections of PE/COFF images into separate EFI
memory map entries. This allows the kernel to map those regions
with strict memory protections, e.g. EFI_MEMORY_RO for code,
EFI_MEMORY_XP for data, etc.
Unfortunately, an unwritten requirement of this new feature is
that the regions need to be mapped with the same offsets
relative to each other as observed in the EFI memory map. If
this is not done crashes like this may occur,
BUG: unable to handle kernel paging request at fffffffefe6086dd
IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
Call Trace:
[<ffffffff8104c90e>] efi_call+0x7e/0x100
[<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
[<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
[<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
[<ffffffff81f37e1b>] start_kernel+0x38a/0x417
[<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef
Here 0xfffffffefe6086dd refers to an address the firmware
expects to be mapped but which the OS never claimed was mapped.
The issue is that included in these regions are relative
addresses to other regions which were emitted by the firmware
toolchain before the "splitting" of sections occurred at
runtime.
Needless to say, we don't satisfy this unwritten requirement on
x86_64 and instead map the EFI memory map entries in reverse
order. The above crash is almost certainly triggerable with any
kernel newer than v3.13 because that's when we rewrote the EFI
runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi:
Runtime services virtual mapping"). For kernel versions before
v3.13 things may work by pure luck depending on the
fragmentation of the kernel virtual address space at the time we
map the EFI regions.
Instead of mapping the EFI memory map entries in reverse order,
where entry N has a higher virtual address than entry N+1, map
them in the same order as they appear in the EFI memory map to
preserve this relative offset between regions.
This patch has been kept as small as possible with the intention
that it should be applied aggressively to stable and
distribution kernels. It is very much a bugfix rather than
support for a new feature, since when EFI_PROPERTIES_TABLE is
enabled we must map things as outlined above to even boot - we
have no way of asking the firmware not to split the code/data
regions.
In fact, this patch doesn't even make use of the more strict
memory protections available in UEFI v2.5. That will come later.
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Chun-Yi <jlee@suse.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: James Bottomley <JBottomley@Odin.com>
Cc: Lee, Chun-Yi <jlee@suse.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-09-25 22:02:18 +00:00
|
|
|
|
2016-04-25 20:06:39 +00:00
|
|
|
entry += efi.memmap.desc_size;
|
|
|
|
if (entry >= efi.memmap.map_end)
|
x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down
Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
that signals that the firmware PE/COFF loader supports splitting
code and data sections of PE/COFF images into separate EFI
memory map entries. This allows the kernel to map those regions
with strict memory protections, e.g. EFI_MEMORY_RO for code,
EFI_MEMORY_XP for data, etc.
Unfortunately, an unwritten requirement of this new feature is
that the regions need to be mapped with the same offsets
relative to each other as observed in the EFI memory map. If
this is not done crashes like this may occur,
BUG: unable to handle kernel paging request at fffffffefe6086dd
IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
Call Trace:
[<ffffffff8104c90e>] efi_call+0x7e/0x100
[<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
[<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
[<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
[<ffffffff81f37e1b>] start_kernel+0x38a/0x417
[<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef
Here 0xfffffffefe6086dd refers to an address the firmware
expects to be mapped but which the OS never claimed was mapped.
The issue is that included in these regions are relative
addresses to other regions which were emitted by the firmware
toolchain before the "splitting" of sections occurred at
runtime.
Needless to say, we don't satisfy this unwritten requirement on
x86_64 and instead map the EFI memory map entries in reverse
order. The above crash is almost certainly triggerable with any
kernel newer than v3.13 because that's when we rewrote the EFI
runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi:
Runtime services virtual mapping"). For kernel versions before
v3.13 things may work by pure luck depending on the
fragmentation of the kernel virtual address space at the time we
map the EFI regions.
Instead of mapping the EFI memory map entries in reverse order,
where entry N has a higher virtual address than entry N+1, map
them in the same order as they appear in the EFI memory map to
preserve this relative offset between regions.
This patch has been kept as small as possible with the intention
that it should be applied aggressively to stable and
distribution kernels. It is very much a bugfix rather than
support for a new feature, since when EFI_PROPERTIES_TABLE is
enabled we must map things as outlined above to even boot - we
have no way of asking the firmware not to split the code/data
regions.
In fact, this patch doesn't even make use of the more strict
memory protections available in UEFI v2.5. That will come later.
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Chun-Yi <jlee@suse.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: James Bottomley <JBottomley@Odin.com>
Cc: Lee, Chun-Yi <jlee@suse.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-09-25 22:02:18 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return entry;
|
|
|
|
}
|
|
|
|
|
2016-06-20 13:36:51 +00:00
|
|
|
static bool should_map_region(efi_memory_desc_t *md)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Runtime regions always require runtime mappings (obviously).
|
|
|
|
*/
|
|
|
|
if (md->attribute & EFI_MEMORY_RUNTIME)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 32-bit EFI doesn't suffer from the bug that requires us to
|
|
|
|
* reserve boot services regions, and mixed mode support
|
|
|
|
* doesn't exist for 32-bit kernels.
|
|
|
|
*/
|
|
|
|
if (IS_ENABLED(CONFIG_X86_32))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Map all of RAM so that we can access arguments in the 1:1
|
|
|
|
* mapping when making EFI runtime calls.
|
|
|
|
*/
|
|
|
|
if (IS_ENABLED(CONFIG_EFI_MIXED) && !efi_is_native()) {
|
|
|
|
if (md->type == EFI_CONVENTIONAL_MEMORY ||
|
|
|
|
md->type == EFI_LOADER_DATA ||
|
|
|
|
md->type == EFI_LOADER_CODE)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Map boot services regions as a workaround for buggy
|
|
|
|
* firmware that accesses them even when they shouldn't.
|
|
|
|
*
|
|
|
|
* See efi_{reserve,free}_boot_services().
|
|
|
|
*/
|
|
|
|
if (md->type == EFI_BOOT_SERVICES_CODE ||
|
|
|
|
md->type == EFI_BOOT_SERVICES_DATA)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-12-20 10:02:16 +00:00
|
|
|
/*
|
2014-01-18 11:48:17 +00:00
|
|
|
* Map the efi memory ranges of the runtime services and update new_mmap with
|
|
|
|
* virtual addresses.
|
2013-12-20 10:02:16 +00:00
|
|
|
*/
|
2014-01-18 11:48:17 +00:00
|
|
|
static void * __init efi_map_regions(int *count, int *pg_shift)
|
2013-12-20 10:02:16 +00:00
|
|
|
{
|
2014-01-18 11:48:17 +00:00
|
|
|
void *p, *new_memmap = NULL;
|
|
|
|
unsigned long left = 0;
|
2016-04-25 20:06:39 +00:00
|
|
|
unsigned long desc_size;
|
2013-12-20 10:02:16 +00:00
|
|
|
efi_memory_desc_t *md;
|
2011-05-05 19:19:44 +00:00
|
|
|
|
2016-04-25 20:06:39 +00:00
|
|
|
desc_size = efi.memmap.desc_size;
|
|
|
|
|
x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down
Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
that signals that the firmware PE/COFF loader supports splitting
code and data sections of PE/COFF images into separate EFI
memory map entries. This allows the kernel to map those regions
with strict memory protections, e.g. EFI_MEMORY_RO for code,
EFI_MEMORY_XP for data, etc.
Unfortunately, an unwritten requirement of this new feature is
that the regions need to be mapped with the same offsets
relative to each other as observed in the EFI memory map. If
this is not done crashes like this may occur,
BUG: unable to handle kernel paging request at fffffffefe6086dd
IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
Call Trace:
[<ffffffff8104c90e>] efi_call+0x7e/0x100
[<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
[<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
[<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
[<ffffffff81f37e1b>] start_kernel+0x38a/0x417
[<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef
Here 0xfffffffefe6086dd refers to an address the firmware
expects to be mapped but which the OS never claimed was mapped.
The issue is that included in these regions are relative
addresses to other regions which were emitted by the firmware
toolchain before the "splitting" of sections occurred at
runtime.
Needless to say, we don't satisfy this unwritten requirement on
x86_64 and instead map the EFI memory map entries in reverse
order. The above crash is almost certainly triggerable with any
kernel newer than v3.13 because that's when we rewrote the EFI
runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi:
Runtime services virtual mapping"). For kernel versions before
v3.13 things may work by pure luck depending on the
fragmentation of the kernel virtual address space at the time we
map the EFI regions.
Instead of mapping the EFI memory map entries in reverse order,
where entry N has a higher virtual address than entry N+1, map
them in the same order as they appear in the EFI memory map to
preserve this relative offset between regions.
This patch has been kept as small as possible with the intention
that it should be applied aggressively to stable and
distribution kernels. It is very much a bugfix rather than
support for a new feature, since when EFI_PROPERTIES_TABLE is
enabled we must map things as outlined above to even boot - we
have no way of asking the firmware not to split the code/data
regions.
In fact, this patch doesn't even make use of the more strict
memory protections available in UEFI v2.5. That will come later.
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Chun-Yi <jlee@suse.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: James Bottomley <JBottomley@Odin.com>
Cc: Lee, Chun-Yi <jlee@suse.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-09-25 22:02:18 +00:00
|
|
|
p = NULL;
|
|
|
|
while ((p = efi_map_next_entry(p))) {
|
2008-01-30 12:31:19 +00:00
|
|
|
md = p;
|
2016-06-20 13:36:51 +00:00
|
|
|
|
|
|
|
if (!should_map_region(md))
|
|
|
|
continue;
|
2008-02-04 15:48:06 +00:00
|
|
|
|
2013-10-31 16:25:08 +00:00
|
|
|
efi_map_region(md);
|
2013-12-20 10:02:16 +00:00
|
|
|
get_systab_virt_addr(md);
|
|
|
|
|
2016-04-25 20:06:39 +00:00
|
|
|
if (left < desc_size) {
|
2014-01-18 11:48:17 +00:00
|
|
|
new_memmap = realloc_pages(new_memmap, *pg_shift);
|
|
|
|
if (!new_memmap)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
left += PAGE_SIZE << *pg_shift;
|
|
|
|
(*pg_shift)++;
|
|
|
|
}
|
|
|
|
|
2016-04-25 20:06:39 +00:00
|
|
|
memcpy(new_memmap + (*count * desc_size), md, desc_size);
|
2014-01-18 11:48:17 +00:00
|
|
|
|
2016-04-25 20:06:39 +00:00
|
|
|
left -= desc_size;
|
2013-12-20 10:02:16 +00:00
|
|
|
(*count)++;
|
|
|
|
}
|
2013-10-31 16:25:08 +00:00
|
|
|
|
2013-12-20 10:02:16 +00:00
|
|
|
return new_memmap;
|
|
|
|
}
|
|
|
|
|
2014-01-18 11:48:18 +00:00
|
|
|
static void __init kexec_enter_virtual_mode(void)
|
|
|
|
{
|
2015-09-09 22:38:55 +00:00
|
|
|
#ifdef CONFIG_KEXEC_CORE
|
2014-01-18 11:48:18 +00:00
|
|
|
efi_memory_desc_t *md;
|
2016-01-21 14:11:59 +00:00
|
|
|
unsigned int num_pages;
|
2014-01-18 11:48:18 +00:00
|
|
|
|
|
|
|
efi.systab = NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't do virtual mode, since we don't do runtime services, on
|
|
|
|
* non-native EFI
|
|
|
|
*/
|
|
|
|
if (!efi_is_native()) {
|
2016-02-26 21:22:05 +00:00
|
|
|
efi_memmap_unmap();
|
2014-08-14 09:15:31 +00:00
|
|
|
clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
2014-01-18 11:48:18 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-01-21 14:11:59 +00:00
|
|
|
if (efi_alloc_page_tables()) {
|
|
|
|
pr_err("Failed to allocate EFI page tables\n");
|
|
|
|
clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-01-18 11:48:18 +00:00
|
|
|
/*
|
|
|
|
* Map efi regions which were passed via setup_data. The virt_addr is a
|
|
|
|
* fixed addr which was used in first kernel of a kexec boot.
|
|
|
|
*/
|
2016-04-25 20:06:38 +00:00
|
|
|
for_each_efi_memory_desc(md) {
|
2014-01-18 11:48:18 +00:00
|
|
|
efi_map_region_fixed(md); /* FIXME: add error handling */
|
|
|
|
get_systab_virt_addr(md);
|
|
|
|
}
|
|
|
|
|
2016-02-27 15:52:50 +00:00
|
|
|
/*
|
|
|
|
* Unregister the early EFI memmap from efi_init() and install
|
|
|
|
* the new EFI memory map.
|
|
|
|
*/
|
|
|
|
efi_memmap_unmap();
|
|
|
|
|
|
|
|
if (efi_memmap_init_late(efi.memmap.phys_map,
|
|
|
|
efi.memmap.desc_size * efi.memmap.nr_map)) {
|
|
|
|
pr_err("Failed to remap late EFI memory map\n");
|
|
|
|
clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-01-18 11:48:18 +00:00
|
|
|
BUG_ON(!efi.systab);
|
|
|
|
|
2016-04-25 20:06:39 +00:00
|
|
|
num_pages = ALIGN(efi.memmap.nr_map * efi.memmap.desc_size, PAGE_SIZE);
|
2016-01-21 14:11:59 +00:00
|
|
|
num_pages >>= PAGE_SHIFT;
|
|
|
|
|
2016-04-25 20:06:39 +00:00
|
|
|
if (efi_setup_page_tables(efi.memmap.phys_map, num_pages)) {
|
2016-01-21 14:11:59 +00:00
|
|
|
clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-01-18 11:48:18 +00:00
|
|
|
efi_sync_low_kernel_mappings();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now that EFI is in virtual mode, update the function
|
|
|
|
* pointers in the runtime service table to the new virtual addresses.
|
|
|
|
*
|
|
|
|
* Call EFI services through wrapper functions.
|
|
|
|
*/
|
|
|
|
efi.runtime_version = efi_systab.hdr.revision;
|
2014-03-05 18:15:37 +00:00
|
|
|
|
2014-06-26 10:09:05 +00:00
|
|
|
efi_native_runtime_setup();
|
2014-03-05 18:15:37 +00:00
|
|
|
|
2014-01-18 11:48:18 +00:00
|
|
|
efi.set_virtual_address_map = NULL;
|
|
|
|
|
|
|
|
if (efi_enabled(EFI_OLD_MEMMAP) && (__supported_pte_mask & _PAGE_NX))
|
|
|
|
runtime_code_page_mkexec();
|
|
|
|
|
|
|
|
/* clean DUMMY object */
|
2014-06-02 12:18:35 +00:00
|
|
|
efi_delete_dummy_variable();
|
2014-01-18 11:48:18 +00:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2013-12-20 10:02:16 +00:00
|
|
|
/*
|
|
|
|
* This function will switch the EFI runtime services to virtual mode.
|
|
|
|
* Essentially, we look through the EFI memmap and map every region that
|
|
|
|
* has the runtime attribute bit set in its memory descriptor into the
|
2015-11-27 21:09:34 +00:00
|
|
|
* efi_pgd page table.
|
2013-12-20 10:02:16 +00:00
|
|
|
*
|
|
|
|
* The old method which used to update that memory descriptor with the
|
|
|
|
* virtual address obtained from ioremap() is still supported when the
|
|
|
|
* kernel is booted with efi=old_map on its command line. Same old
|
|
|
|
* method enabled the runtime services to be called without having to
|
|
|
|
* thunk back into physical mode for every invocation.
|
|
|
|
*
|
|
|
|
* The new method does a pagetable switch in a preemption-safe manner
|
|
|
|
* so that we're in a different address space when calling a runtime
|
2015-11-27 21:09:34 +00:00
|
|
|
* function. For function arguments passing we do copy the PUDs of the
|
|
|
|
* kernel page table into efi_pgd prior to each call.
|
2013-12-20 10:02:19 +00:00
|
|
|
*
|
|
|
|
* Specially for kexec boot, efi runtime maps in previous kernel should
|
|
|
|
* be passed in via setup_data. In that case runtime ranges will be mapped
|
2014-01-18 11:48:18 +00:00
|
|
|
* to the same virtual addresses as the first kernel, see
|
|
|
|
* kexec_enter_virtual_mode().
|
2013-12-20 10:02:16 +00:00
|
|
|
*/
|
2014-01-18 11:48:18 +00:00
|
|
|
static void __init __efi_enter_virtual_mode(void)
|
2013-12-20 10:02:16 +00:00
|
|
|
{
|
2014-01-18 11:48:18 +00:00
|
|
|
int count = 0, pg_shift = 0;
|
2013-12-20 10:02:16 +00:00
|
|
|
void *new_memmap = NULL;
|
2014-01-18 11:48:17 +00:00
|
|
|
efi_status_t status;
|
2016-11-12 21:04:23 +00:00
|
|
|
unsigned long pa;
|
2008-02-04 15:48:06 +00:00
|
|
|
|
2013-12-20 10:02:16 +00:00
|
|
|
efi.systab = NULL;
|
2013-10-31 16:25:08 +00:00
|
|
|
|
2015-11-27 21:09:34 +00:00
|
|
|
if (efi_alloc_page_tables()) {
|
|
|
|
pr_err("Failed to allocate EFI page tables\n");
|
|
|
|
clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-01-18 11:48:18 +00:00
|
|
|
efi_merge_regions();
|
|
|
|
new_memmap = efi_map_regions(&count, &pg_shift);
|
|
|
|
if (!new_memmap) {
|
|
|
|
pr_err("Error reallocating memory, EFI runtime non-functional!\n");
|
2014-08-14 09:15:31 +00:00
|
|
|
clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
2014-01-18 11:48:18 +00:00
|
|
|
return;
|
2014-01-18 11:48:17 +00:00
|
|
|
}
|
2013-12-20 10:02:18 +00:00
|
|
|
|
2016-02-27 15:52:50 +00:00
|
|
|
pa = __pa(new_memmap);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Unregister the early EFI memmap from efi_init() and install
|
|
|
|
* the new EFI memory map that we are about to pass to the
|
|
|
|
* firmware via SetVirtualAddressMap().
|
|
|
|
*/
|
|
|
|
efi_memmap_unmap();
|
|
|
|
|
|
|
|
if (efi_memmap_init_late(pa, efi.memmap.desc_size * count)) {
|
|
|
|
pr_err("Failed to remap late EFI memory map\n");
|
|
|
|
clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2008-01-30 12:31:19 +00:00
|
|
|
BUG_ON(!efi.systab);
|
|
|
|
|
2016-02-27 15:52:50 +00:00
|
|
|
if (efi_setup_page_tables(pa, 1 << pg_shift)) {
|
2014-08-14 09:15:31 +00:00
|
|
|
clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
2014-01-18 11:48:18 +00:00
|
|
|
return;
|
2014-08-14 09:15:31 +00:00
|
|
|
}
|
2014-01-18 11:48:17 +00:00
|
|
|
|
2013-10-31 16:25:08 +00:00
|
|
|
efi_sync_low_kernel_mappings();
|
|
|
|
|
2014-03-05 18:15:37 +00:00
|
|
|
if (efi_is_native()) {
|
|
|
|
status = phys_efi_set_virtual_address_map(
|
2016-04-25 20:06:39 +00:00
|
|
|
efi.memmap.desc_size * count,
|
|
|
|
efi.memmap.desc_size,
|
|
|
|
efi.memmap.desc_version,
|
2016-02-27 15:52:50 +00:00
|
|
|
(efi_memory_desc_t *)pa);
|
2014-03-05 18:15:37 +00:00
|
|
|
} else {
|
|
|
|
status = efi_thunk_set_virtual_address_map(
|
|
|
|
efi_phys.set_virtual_address_map,
|
2016-04-25 20:06:39 +00:00
|
|
|
efi.memmap.desc_size * count,
|
|
|
|
efi.memmap.desc_size,
|
|
|
|
efi.memmap.desc_version,
|
2016-02-27 15:52:50 +00:00
|
|
|
(efi_memory_desc_t *)pa);
|
2014-03-05 18:15:37 +00:00
|
|
|
}
|
2013-12-20 10:02:19 +00:00
|
|
|
|
2014-01-18 11:48:18 +00:00
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
pr_alert("Unable to switch EFI into virtual mode (status=%lx)!\n",
|
|
|
|
status);
|
|
|
|
panic("EFI call to SetVirtualAddressMap() failed!");
|
2008-01-30 12:31:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now that EFI is in virtual mode, update the function
|
|
|
|
* pointers in the runtime service table to the new virtual addresses.
|
|
|
|
*
|
|
|
|
* Call EFI services through wrapper functions.
|
|
|
|
*/
|
2013-01-25 10:07:25 +00:00
|
|
|
efi.runtime_version = efi_systab.hdr.revision;
|
2014-01-10 18:48:30 +00:00
|
|
|
|
|
|
|
if (efi_is_native())
|
2014-06-26 10:09:05 +00:00
|
|
|
efi_native_runtime_setup();
|
2014-01-10 18:48:30 +00:00
|
|
|
else
|
|
|
|
efi_thunk_runtime_setup();
|
|
|
|
|
2011-05-05 19:19:42 +00:00
|
|
|
efi.set_virtual_address_map = NULL;
|
2013-10-31 16:25:08 +00:00
|
|
|
|
2016-02-17 12:36:05 +00:00
|
|
|
/*
|
|
|
|
* Apply more restrictive page table mapping attributes now that
|
|
|
|
* SVAM() has been called and the firmware has performed all
|
|
|
|
* necessary relocation fixups for the new virtual addresses.
|
|
|
|
*/
|
|
|
|
efi_runtime_update_mappings();
|
|
|
|
efi_dump_pagetable();
|
2012-02-12 21:24:29 +00:00
|
|
|
|
2013-06-01 20:06:20 +00:00
|
|
|
/* clean DUMMY object */
|
2014-06-02 12:18:35 +00:00
|
|
|
efi_delete_dummy_variable();
|
2008-01-30 12:31:19 +00:00
|
|
|
}
|
|
|
|
|
2014-01-18 11:48:18 +00:00
|
|
|
void __init efi_enter_virtual_mode(void)
|
|
|
|
{
|
2014-06-30 17:52:58 +00:00
|
|
|
if (efi_enabled(EFI_PARAVIRT))
|
|
|
|
return;
|
|
|
|
|
2014-01-18 11:48:18 +00:00
|
|
|
if (efi_setup)
|
|
|
|
kexec_enter_virtual_mode();
|
|
|
|
else
|
|
|
|
__efi_enter_virtual_mode();
|
|
|
|
}
|
|
|
|
|
2008-01-30 12:31:19 +00:00
|
|
|
/*
|
|
|
|
* Convenience functions to obtain memory types and attributes
|
|
|
|
*/
|
|
|
|
u32 efi_mem_type(unsigned long phys_addr)
|
|
|
|
{
|
|
|
|
efi_memory_desc_t *md;
|
|
|
|
|
2012-11-14 09:42:35 +00:00
|
|
|
if (!efi_enabled(EFI_MEMMAP))
|
|
|
|
return 0;
|
|
|
|
|
2016-04-25 20:06:38 +00:00
|
|
|
for_each_efi_memory_desc(md) {
|
2008-01-30 12:31:19 +00:00
|
|
|
if ((md->phys_addr <= phys_addr) &&
|
|
|
|
(phys_addr < (md->phys_addr +
|
|
|
|
(md->num_pages << EFI_PAGE_SHIFT))))
|
|
|
|
return md->type;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-08-14 09:15:28 +00:00
|
|
|
static int __init arch_parse_efi_cmdline(char *str)
|
2013-10-31 16:25:08 +00:00
|
|
|
{
|
2015-07-16 02:36:03 +00:00
|
|
|
if (!str) {
|
|
|
|
pr_warn("need at least one option\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2014-08-14 09:15:27 +00:00
|
|
|
if (parse_option_str(str, "old_map"))
|
|
|
|
set_bit(EFI_OLD_MEMMAP, &efi.flags);
|
2013-10-31 16:25:08 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2014-08-14 09:15:28 +00:00
|
|
|
early_param("efi", arch_parse_efi_cmdline);
|