License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
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>
|
2010-08-25 20:39:17 +00:00
|
|
|
#include <linux/memblock.h>
|
2018-10-30 22:09:49 +00:00
|
|
|
#include <linux/slab.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>
|
2017-05-08 22:58:11 +00:00
|
|
|
#include <asm/set_memory.h>
|
2008-01-30 12:33:55 +00:00
|
|
|
#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
|
2019-06-25 13:48:35 +00:00
|
|
|
{UV_SYSTEM_TABLE_GUID, "UVsystab", &uv_systab_phys},
|
2013-09-05 10:34:54 +00:00
|
|
|
#endif
|
2013-10-03 14:42:37 +00:00
|
|
|
{NULL_GUID, NULL, NULL},
|
2013-09-05 10:34:54 +00:00
|
|
|
};
|
|
|
|
|
2019-06-25 13:36:45 +00:00
|
|
|
static const unsigned long * const efi_tables[] = {
|
|
|
|
&efi.mps,
|
|
|
|
&efi.acpi,
|
|
|
|
&efi.acpi20,
|
|
|
|
&efi.smbios,
|
|
|
|
&efi.smbios3,
|
|
|
|
&efi.boot_info,
|
|
|
|
&efi.hcdp,
|
|
|
|
&efi.uga,
|
2019-06-25 13:48:35 +00:00
|
|
|
#ifdef CONFIG_X86_UV
|
|
|
|
&uv_systab_phys,
|
|
|
|
#endif
|
2019-06-25 13:36:45 +00:00
|
|
|
&efi.fw_vendor,
|
|
|
|
&efi.runtime,
|
|
|
|
&efi.config_table,
|
|
|
|
&efi.esrt,
|
|
|
|
&efi.properties_table,
|
|
|
|
&efi.mem_attr_table,
|
2019-07-10 18:59:15 +00:00
|
|
|
#ifdef CONFIG_EFI_RCI2_TABLE
|
|
|
|
&rci2_table_phys,
|
|
|
|
#endif
|
2019-06-25 13:36:45 +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();
|
2019-05-25 11:25:58 +00:00
|
|
|
if (!save_pgd)
|
|
|
|
return EFI_ABORTED;
|
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;
|
|
|
|
|
2019-11-07 01:43:05 +00:00
|
|
|
if (!efi_enabled(EFI_MEMMAP))
|
|
|
|
return;
|
|
|
|
|
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
|
2019-11-07 01:43:16 +00:00
|
|
|
* more than the max 128 entries that can fit in the passed in e820
|
|
|
|
* legacy (zeropage) memory map, but the kernel's e820 table can hold
|
|
|
|
* E820_MAX_ENTRIES.
|
2008-05-14 15:15:58 +00:00
|
|
|
*/
|
|
|
|
|
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
|
|
|
|
2019-11-07 01:43:16 +00:00
|
|
|
if (!efi_enabled(EFI_MEMMAP))
|
|
|
|
return;
|
|
|
|
|
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:
|
2019-11-07 01:43:16 +00:00
|
|
|
if (efi_soft_reserve_enabled()
|
|
|
|
&& (md->attribute & EFI_MEMORY_SP))
|
|
|
|
e820_type = E820_TYPE_SOFT_RESERVED;
|
|
|
|
else 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;
|
|
|
|
}
|
2019-11-07 01:43:16 +00:00
|
|
|
|
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
|
|
|
}
|
x86/boot/e820: Simplify the e820__update_table() interface
The e820__update_table() parameters are pretty complex:
arch/x86/include/asm/e820/api.h:extern int e820__update_table(struct e820_entry *biosmap, int max_nr_map, u32 *pnr_map);
But 90% of the usage is trivial:
arch/x86/kernel/e820.c: if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries))
arch/x86/kernel/e820.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/e820.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/e820.c: if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries) < 0)
arch/x86/kernel/e820.c: e820__update_table(boot_params.e820_table, ARRAY_SIZE(boot_params.e820_table), &new_nr);
arch/x86/kernel/early-quirks.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/platform/efi/efi.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/xen/setup.c: e820__update_table(xen_e820_table.entries, ARRAY_SIZE(xen_e820_table.entries),
arch/x86/xen/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/xen/setup.c: e820__update_table(xen_e820_table.entries, ARRAY_SIZE(xen_e820_table.entries),
as it only uses an exiting struct e820_table's entries array, its size and
its current number of entries as input and output arguments.
Only one use is non-trivial:
arch/x86/kernel/e820.c: e820__update_table(boot_params.e820_table, ARRAY_SIZE(boot_params.e820_table), &new_nr);
... which call updates the E820 table in the zeropage in-situ, and the layout there does not
match that of 'struct e820_table' (in particular nr_entries is at a different offset,
hardcoded by the boot protocol).
Simplify all this by introducing a low level __e820__update_table() API that
the zeropage update call can use, and simplifying the main e820__update_table()
call signature down to:
int e820__update_table(struct e820_table *table);
This visibly simplifies all the call sites:
arch/x86/include/asm/e820/api.h:extern int e820__update_table(struct e820_table *table);
arch/x86/include/asm/e820/types.h: * call to e820__update_table() to remove duplicates. The allowance
arch/x86/kernel/e820.c: * The return value from e820__update_table() is zero if it
arch/x86/kernel/e820.c:int __init e820__update_table(struct e820_table *table)
arch/x86/kernel/e820.c: if (e820__update_table(e820_table))
arch/x86/kernel/e820.c: e820__update_table(e820_table_firmware);
arch/x86/kernel/e820.c: e820__update_table(e820_table);
arch/x86/kernel/e820.c: e820__update_table(e820_table);
arch/x86/kernel/e820.c: if (e820__update_table(e820_table) < 0)
arch/x86/kernel/early-quirks.c: e820__update_table(e820_table);
arch/x86/kernel/setup.c: e820__update_table(e820_table);
arch/x86/kernel/setup.c: e820__update_table(e820_table);
arch/x86/platform/efi/efi.c: e820__update_table(e820_table);
arch/x86/xen/setup.c: e820__update_table(&xen_e820_table);
arch/x86/xen/setup.c: e820__update_table(e820_table);
arch/x86/xen/setup.c: e820__update_table(&xen_e820_table);
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 17:00:35 +00:00
|
|
|
e820__update_table(e820_table);
|
2008-05-14 15:15:58 +00:00
|
|
|
}
|
|
|
|
|
2019-11-07 01:43:16 +00:00
|
|
|
/*
|
|
|
|
* Given add_efi_memmap defaults to 0 and there there is no alternative
|
|
|
|
* e820 mechanism for soft-reserved memory, import the full EFI memory
|
|
|
|
* map if soft reservations are present and enabled. Otherwise, the
|
|
|
|
* mechanism to disable the kernel's consideration of EFI_MEMORY_SP is
|
|
|
|
* the efi=nosoftreserve option.
|
|
|
|
*/
|
|
|
|
static bool do_efi_soft_reserve(void)
|
|
|
|
{
|
|
|
|
efi_memory_desc_t *md;
|
|
|
|
|
|
|
|
if (!efi_enabled(EFI_MEMMAP))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!efi_soft_reserve_enabled())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
for_each_efi_memory_desc(md)
|
|
|
|
if (md->type == EFI_CONVENTIONAL_MEMORY &&
|
|
|
|
(md->attribute & EFI_MEMORY_SP))
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
|
2019-11-07 01:43:16 +00:00
|
|
|
if (add_efi_memmap || do_efi_soft_reserve())
|
2016-02-26 21:22:05 +00:00
|
|
|
do_add_efi_memmap();
|
2012-02-12 21:24:29 +00:00
|
|
|
|
2019-11-07 01:43:26 +00:00
|
|
|
efi_fake_memmap_early();
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
|
2019-11-07 01:43:16 +00:00
|
|
|
/*
|
|
|
|
* EFI specific purpose memory may be reserved by default
|
|
|
|
* depending on kernel config and boot options.
|
|
|
|
*/
|
|
|
|
if (md->type == EFI_CONVENTIONAL_MEMORY &&
|
|
|
|
efi_soft_reserve_enabled() &&
|
|
|
|
(md->attribute & EFI_MEMORY_SP))
|
|
|
|
return false;
|
|
|
|
|
2016-06-20 13:36:51 +00:00
|
|
|
/*
|
|
|
|
* 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
|
2017-05-26 11:36:49 +00:00
|
|
|
* non-native EFI. With efi=old_map, we don't do runtime services in
|
|
|
|
* kexec kernel because in the initial boot something else might
|
|
|
|
* have been mapped at these virtual addresses.
|
2014-01-18 11:48:18 +00:00
|
|
|
*/
|
2017-05-26 11:36:49 +00:00
|
|
|
if (!efi_is_native() || efi_enabled(EFI_OLD_MEMMAP)) {
|
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();
|
|
|
|
#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;
|
|
|
|
}
|
|
|
|
|
2017-01-31 13:21:41 +00:00
|
|
|
if (efi_enabled(EFI_DBG)) {
|
|
|
|
pr_info("EFI runtime memory map:\n");
|
|
|
|
efi_print_memmap();
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2018-11-29 17:12:25 +00:00
|
|
|
efi_free_boot_services();
|
|
|
|
|
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();
|
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();
|
2017-06-02 13:52:06 +00:00
|
|
|
|
|
|
|
efi_dump_pagetable();
|
2014-01-18 11:48:18 +00:00
|
|
|
}
|
|
|
|
|
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);
|
2019-06-25 13:36:45 +00:00
|
|
|
|
|
|
|
bool efi_is_table_address(unsigned long phys_addr)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
if (phys_addr == EFI_INVALID_TABLE_ADDR)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(efi_tables); i++)
|
|
|
|
if (*(efi_tables[i]) == phys_addr)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|