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 15:07:57 +01:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2008-01-30 13:31:19 +01: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 17:25:08 +01:00
|
|
|
* Copyright (C) 2013 SuSE Labs
|
|
|
|
* Borislav Petkov <bp@suse.de> - runtime services VA mapping
|
2008-01-30 13:31:19 +01: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 13:24:26 -08:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2008-01-30 13:31:19 +01:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/efi.h>
|
2012-09-28 17:57:05 -07:00
|
|
|
#include <linux/efi-bgrt.h>
|
2011-05-26 12:22:53 -04:00
|
|
|
#include <linux/export.h>
|
2010-08-25 13:39:17 -07:00
|
|
|
#include <linux/memblock.h>
|
2018-10-30 15:09:49 -07:00
|
|
|
#include <linux/slab.h>
|
2008-01-30 13:31:19 +01: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 11:59:46 +01:00
|
|
|
#include <asm/e820/api.h>
|
2008-01-30 13:31:19 +01:00
|
|
|
#include <asm/time.h>
|
2008-01-30 13:33:55 +01:00
|
|
|
#include <asm/tlbflush.h>
|
2009-09-10 10:48:56 +08:00
|
|
|
#include <asm/x86_init.h>
|
2014-03-04 17:02:17 +01:00
|
|
|
#include <asm/uv/uv.h>
|
2008-01-30 13:31:19 +01:00
|
|
|
|
2020-01-21 09:44:43 +01:00
|
|
|
static unsigned long efi_systab_phys __initdata;
|
2020-01-19 16:17:59 +01:00
|
|
|
static unsigned long prop_phys = EFI_INVALID_TABLE_ADDR;
|
|
|
|
static unsigned long uga_phys = EFI_INVALID_TABLE_ADDR;
|
2020-01-20 17:23:21 +01:00
|
|
|
static unsigned long efi_runtime, efi_nr_tables;
|
|
|
|
|
|
|
|
unsigned long efi_fw_vendor, efi_config_table;
|
2020-01-19 16:17:59 +01:00
|
|
|
|
2020-01-22 14:40:57 +01:00
|
|
|
static const efi_config_table_type_t arch_tables[] __initconst = {
|
2020-03-26 09:24:14 +01:00
|
|
|
{EFI_PROPERTIES_TABLE_GUID, &prop_phys, "PROP" },
|
|
|
|
{UGA_IO_PROTOCOL_GUID, &uga_phys, "UGA" },
|
2013-09-05 11:34:54 +01:00
|
|
|
#ifdef CONFIG_X86_UV
|
2020-03-26 09:24:14 +01:00
|
|
|
{UV_SYSTEM_TABLE_GUID, &uv_systab_phys, "UVsystab" },
|
2013-09-05 11:34:54 +01:00
|
|
|
#endif
|
2020-03-26 09:24:14 +01:00
|
|
|
{},
|
2013-09-05 11:34:54 +01:00
|
|
|
};
|
|
|
|
|
2019-06-25 15:36:45 +02:00
|
|
|
static const unsigned long * const efi_tables[] = {
|
|
|
|
&efi.acpi,
|
|
|
|
&efi.acpi20,
|
|
|
|
&efi.smbios,
|
|
|
|
&efi.smbios3,
|
2020-01-19 16:17:59 +01:00
|
|
|
&uga_phys,
|
2019-06-25 15:48:35 +02:00
|
|
|
#ifdef CONFIG_X86_UV
|
|
|
|
&uv_systab_phys,
|
|
|
|
#endif
|
2020-01-20 17:23:21 +01:00
|
|
|
&efi_fw_vendor,
|
|
|
|
&efi_runtime,
|
|
|
|
&efi_config_table,
|
2019-06-25 15:36:45 +02:00
|
|
|
&efi.esrt,
|
2020-01-19 16:17:59 +01:00
|
|
|
&prop_phys,
|
2020-01-22 15:05:12 +01:00
|
|
|
&efi_mem_attr_table,
|
2019-07-10 18:59:15 +00:00
|
|
|
#ifdef CONFIG_EFI_RCI2_TABLE
|
|
|
|
&rci2_table_phys,
|
|
|
|
#endif
|
2020-02-28 13:14:03 +01:00
|
|
|
&efi.tpm_log,
|
|
|
|
&efi.tpm_final_log,
|
2020-02-28 13:14:04 +01:00
|
|
|
&efi_rng_seed,
|
2020-09-04 21:31:05 -04:00
|
|
|
#ifdef CONFIG_LOAD_UEFI_KEYS
|
|
|
|
&efi.mokvar_table,
|
|
|
|
#endif
|
2019-06-25 15:36:45 +02:00
|
|
|
};
|
|
|
|
|
2013-12-20 18:02:19 +08:00
|
|
|
u64 efi_setup; /* efi setup_data physical address */
|
2013-12-20 18:02:18 +08:00
|
|
|
|
2014-09-07 19:42:15 +02:00
|
|
|
static int add_efi_memmap __initdata;
|
2008-06-25 05:44:46 -07: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);
|
|
|
|
|
2015-06-24 16:58:15 -07:00
|
|
|
void __init efi_find_mirror(void)
|
|
|
|
{
|
2016-04-25 21:06:38 +01:00
|
|
|
efi_memory_desc_t *md;
|
2015-06-24 16:58:15 -07:00
|
|
|
u64 mirror_size = 0, total_size = 0;
|
|
|
|
|
2019-11-06 17:43:05 -08:00
|
|
|
if (!efi_enabled(EFI_MEMMAP))
|
|
|
|
return;
|
|
|
|
|
2016-04-25 21:06:38 +01:00
|
|
|
for_each_efi_memory_desc(md) {
|
2015-06-24 16:58:15 -07: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 08:15:58 -07:00
|
|
|
/*
|
|
|
|
* Tell the kernel about the EFI memory map. This might include
|
2019-11-06 17:43:16 -08: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 08:15:58 -07:00
|
|
|
*/
|
|
|
|
|
2008-06-25 05:44:46 -07:00
|
|
|
static void __init do_add_efi_memmap(void)
|
2008-05-14 08:15:58 -07:00
|
|
|
{
|
2016-04-25 21:06:38 +01:00
|
|
|
efi_memory_desc_t *md;
|
2008-05-14 08:15:58 -07:00
|
|
|
|
2019-11-06 17:43:16 -08:00
|
|
|
if (!efi_enabled(EFI_MEMMAP))
|
|
|
|
return;
|
|
|
|
|
2016-04-25 21:06:38 +01:00
|
|
|
for_each_efi_memory_desc(md) {
|
2008-05-14 08:15:58 -07:00
|
|
|
unsigned long long start = md->phys_addr;
|
|
|
|
unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
|
|
|
|
int e820_type;
|
|
|
|
|
2009-06-16 16:43:40 -05: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-06 17:43:16 -08: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 17:09:33 +01:00
|
|
|
e820_type = E820_TYPE_RAM;
|
2009-06-16 16:43:40 -05:00
|
|
|
else
|
2017-01-28 17:09:33 +01:00
|
|
|
e820_type = E820_TYPE_RESERVED;
|
2009-06-16 16:43:40 -05:00
|
|
|
break;
|
|
|
|
case EFI_ACPI_RECLAIM_MEMORY:
|
2017-01-28 17:09:33 +01:00
|
|
|
e820_type = E820_TYPE_ACPI;
|
2009-06-16 16:43:40 -05:00
|
|
|
break;
|
|
|
|
case EFI_ACPI_MEMORY_NVS:
|
2017-01-28 17:09:33 +01:00
|
|
|
e820_type = E820_TYPE_NVS;
|
2009-06-16 16:43:40 -05:00
|
|
|
break;
|
|
|
|
case EFI_UNUSABLE_MEMORY:
|
2017-01-28 17:09:33 +01:00
|
|
|
e820_type = E820_TYPE_UNUSABLE;
|
2009-06-16 16:43:40 -05:00
|
|
|
break;
|
2015-04-03 12:05:28 -04:00
|
|
|
case EFI_PERSISTENT_MEMORY:
|
2017-01-28 17:09:33 +01:00
|
|
|
e820_type = E820_TYPE_PMEM;
|
2015-04-03 12:05:28 -04:00
|
|
|
break;
|
2009-06-16 16:43:40 -05: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 17:09:33 +01:00
|
|
|
e820_type = E820_TYPE_RESERVED;
|
2009-06-16 16:43:40 -05:00
|
|
|
break;
|
|
|
|
}
|
2019-11-06 17:43:16 -08: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 14:19:36 +01:00
|
|
|
e820__range_add(start, size, e820_type);
|
2008-05-14 08:15:58 -07: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 18:00:35 +01:00
|
|
|
e820__update_table(e820_table);
|
2008-05-14 08:15:58 -07:00
|
|
|
}
|
|
|
|
|
2019-11-06 17:43:16 -08: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 13:24:29 -08:00
|
|
|
int __init efi_memblock_x86_reserve_range(void)
|
2008-06-02 14:26:21 +08:00
|
|
|
{
|
2013-03-01 17:07:44 +01: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 11:48:16 +02:00
|
|
|
phys_addr_t pmap;
|
2016-02-26 21:22:05 +00:00
|
|
|
int rv;
|
2008-06-02 14:26:21 +08:00
|
|
|
|
2014-06-30 19:52:58 +02:00
|
|
|
if (efi_enabled(EFI_PARAVIRT))
|
|
|
|
return 0;
|
|
|
|
|
2020-02-02 11:22:41 +01:00
|
|
|
/* Can't handle firmware tables above 4GB on i386 */
|
|
|
|
if (IS_ENABLED(CONFIG_X86_32) && e->efi_memmap_hi > 0) {
|
2012-02-12 13:24:29 -08:00
|
|
|
pr_err("Memory map is above 4GB, disabling EFI.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2020-02-02 11:22:41 +01:00
|
|
|
pmap = (phys_addr_t)(e->efi_memmap | ((u64)e->efi_memmap_hi << 32));
|
|
|
|
|
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-06 17:43:16 -08:00
|
|
|
if (add_efi_memmap || do_efi_soft_reserve())
|
2016-02-26 21:22:05 +00:00
|
|
|
do_add_efi_memmap();
|
2012-02-12 13:24:29 -08:00
|
|
|
|
2019-11-06 17:43:26 -08:00
|
|
|
efi_fake_memmap_early();
|
|
|
|
|
2016-04-25 21:06:40 +01:00
|
|
|
WARN(efi.memmap.desc_version != 1,
|
|
|
|
"Unexpected EFI_MEMORY_DESCRIPTOR version %ld",
|
|
|
|
efi.memmap.desc_version);
|
|
|
|
|
2016-04-25 21:06:39 +01:00
|
|
|
memblock_reserve(pmap, efi.memmap.nr_map * efi.memmap.desc_size);
|
2020-01-15 17:35:45 +01:00
|
|
|
set_bit(EFI_PRESERVE_BS_REGIONS, &efi.flags);
|
2013-09-05 11:34:55 +01:00
|
|
|
|
2012-02-12 13:24:29 -08:00
|
|
|
return 0;
|
2008-06-02 14:26:21 +08: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 18:42:28 -05: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) {
|
2020-01-13 18:22:43 +01:00
|
|
|
struct efi_memory_map_data data = {
|
2020-02-02 11:30:14 +01:00
|
|
|
.phys_map = efi.memmap.phys_map,
|
|
|
|
.desc_version = efi.memmap.desc_version,
|
|
|
|
.desc_size = efi.memmap.desc_size,
|
|
|
|
.size = efi.memmap.desc_size * (efi.memmap.nr_map - n_removal),
|
|
|
|
.flags = 0,
|
2020-01-13 18:22:43 +01: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 18:42:28 -05:00
|
|
|
|
|
|
|
pr_warn("Removing %d invalid memory map entries.\n", n_removal);
|
2020-01-13 18:22:43 +01:00
|
|
|
efi_memmap_install(&data);
|
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 18:42:28 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-30 19:20:00 +09:00
|
|
|
void __init efi_print_memmap(void)
|
2008-01-30 13:31:19 +01:00
|
|
|
{
|
|
|
|
efi_memory_desc_t *md;
|
2016-04-25 21:06:38 +01:00
|
|
|
int i = 0;
|
2008-01-30 13:31:19 +01:00
|
|
|
|
2016-04-25 21:06:38 +01: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 13:32:21 +02: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 21:06:38 +01: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 13:32:21 +02: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 13:31:19 +01:00
|
|
|
(md->num_pages >> (20 - EFI_PAGE_SHIFT)));
|
|
|
|
}
|
2013-10-31 17:24:59 +01:00
|
|
|
}
|
2008-01-30 13:31:19 +01:00
|
|
|
|
2020-01-21 09:44:43 +01:00
|
|
|
static int __init efi_systab_init(unsigned long phys)
|
2008-01-30 13:31:19 +01:00
|
|
|
{
|
2020-01-03 12:39:45 +01:00
|
|
|
int size = efi_enabled(EFI_64BIT) ? sizeof(efi_system_table_64_t)
|
|
|
|
: sizeof(efi_system_table_32_t);
|
2020-01-20 10:49:11 +01:00
|
|
|
const efi_table_hdr_t *hdr;
|
2020-01-03 12:39:45 +01:00
|
|
|
bool over4g = false;
|
|
|
|
void *p;
|
2020-01-20 10:49:11 +01:00
|
|
|
int ret;
|
2020-01-03 12:39:45 +01:00
|
|
|
|
2020-01-20 10:49:11 +01:00
|
|
|
hdr = p = early_memremap_ro(phys, size);
|
2020-01-03 12:39:45 +01:00
|
|
|
if (p == NULL) {
|
|
|
|
pr_err("Couldn't map the system table!\n");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2020-01-20 10:49:11 +01:00
|
|
|
ret = efi_systab_check_header(hdr, 1);
|
|
|
|
if (ret) {
|
|
|
|
early_memunmap(p, size);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-11-14 09:42:35 +00:00
|
|
|
if (efi_enabled(EFI_64BIT)) {
|
2020-01-03 12:39:45 +01:00
|
|
|
const efi_system_table_64_t *systab64 = p;
|
|
|
|
|
2020-01-21 10:16:32 +01:00
|
|
|
efi_runtime = systab64->runtime;
|
|
|
|
over4g = systab64->runtime > U32_MAX;
|
2012-02-12 13:24:29 -08:00
|
|
|
|
2013-12-20 18:02:19 +08:00
|
|
|
if (efi_setup) {
|
2020-01-03 12:39:45 +01:00
|
|
|
struct efi_setup_data *data;
|
|
|
|
|
|
|
|
data = early_memremap_ro(efi_setup, sizeof(*data));
|
|
|
|
if (!data) {
|
|
|
|
early_memunmap(p, size);
|
2013-12-20 18:02:19 +08:00
|
|
|
return -ENOMEM;
|
2020-01-03 12:39:45 +01:00
|
|
|
}
|
|
|
|
|
2020-01-21 10:16:32 +01:00
|
|
|
efi_fw_vendor = (unsigned long)data->fw_vendor;
|
|
|
|
efi_config_table = (unsigned long)data->tables;
|
2020-01-03 12:39:45 +01:00
|
|
|
|
|
|
|
over4g |= data->fw_vendor > U32_MAX ||
|
|
|
|
data->tables > U32_MAX;
|
2012-02-12 13:24:29 -08:00
|
|
|
|
2014-06-30 19:52:56 +02:00
|
|
|
early_memunmap(data, sizeof(*data));
|
2020-01-03 12:39:45 +01:00
|
|
|
} else {
|
2020-01-21 10:16:32 +01:00
|
|
|
efi_fw_vendor = systab64->fw_vendor;
|
|
|
|
efi_config_table = systab64->tables;
|
|
|
|
|
2020-01-03 12:39:45 +01:00
|
|
|
over4g |= systab64->fw_vendor > U32_MAX ||
|
|
|
|
systab64->tables > U32_MAX;
|
2012-02-12 13:24:29 -08:00
|
|
|
}
|
2020-01-21 10:16:32 +01:00
|
|
|
efi_nr_tables = systab64->nr_tables;
|
2012-02-12 13:24:29 -08:00
|
|
|
} else {
|
2020-01-03 12:39:45 +01:00
|
|
|
const efi_system_table_32_t *systab32 = p;
|
|
|
|
|
2020-01-21 10:16:32 +01:00
|
|
|
efi_fw_vendor = systab32->fw_vendor;
|
|
|
|
efi_runtime = systab32->runtime;
|
|
|
|
efi_config_table = systab32->tables;
|
|
|
|
efi_nr_tables = systab32->nr_tables;
|
2020-01-03 12:39:45 +01:00
|
|
|
}
|
2012-02-12 13:24:29 -08:00
|
|
|
|
2020-01-20 18:35:17 +01:00
|
|
|
efi.runtime_version = hdr->revision;
|
|
|
|
|
2020-01-21 10:16:32 +01:00
|
|
|
efi_systab_report_header(hdr, efi_fw_vendor);
|
2020-01-03 12:39:45 +01:00
|
|
|
early_memunmap(p, size);
|
2012-02-12 13:24:29 -08:00
|
|
|
|
2020-01-03 12:39:45 +01:00
|
|
|
if (IS_ENABLED(CONFIG_X86_32) && over4g) {
|
|
|
|
pr_err("EFI data located above 4GB, disabling EFI.\n");
|
|
|
|
return -EINVAL;
|
2012-02-12 13:24:28 -08:00
|
|
|
}
|
2012-02-12 13:24:29 -08:00
|
|
|
|
2012-02-12 13:24:28 -08:00
|
|
|
return 0;
|
2012-02-12 13:24:25 -08:00
|
|
|
}
|
2008-01-30 13:31:19 +01:00
|
|
|
|
2020-01-22 14:40:57 +01:00
|
|
|
static int __init efi_config_init(const efi_config_table_type_t *arch_tables)
|
2020-01-20 17:17:27 +01:00
|
|
|
{
|
|
|
|
void *config_tables;
|
|
|
|
int sz, ret;
|
|
|
|
|
2020-01-20 17:23:21 +01:00
|
|
|
if (efi_nr_tables == 0)
|
2020-01-20 17:17:27 +01:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (efi_enabled(EFI_64BIT))
|
|
|
|
sz = sizeof(efi_config_table_64_t);
|
|
|
|
else
|
|
|
|
sz = sizeof(efi_config_table_32_t);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Let's see what config tables the firmware passed to us.
|
|
|
|
*/
|
2020-01-20 17:23:21 +01:00
|
|
|
config_tables = early_memremap(efi_config_table, efi_nr_tables * sz);
|
2020-01-20 17:17:27 +01:00
|
|
|
if (config_tables == NULL) {
|
|
|
|
pr_err("Could not map Configuration table!\n");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2020-01-20 17:23:21 +01:00
|
|
|
ret = efi_config_parse_tables(config_tables, efi_nr_tables,
|
2020-01-20 17:17:27 +01:00
|
|
|
arch_tables);
|
|
|
|
|
2020-01-20 17:23:21 +01:00
|
|
|
early_memunmap(config_tables, efi_nr_tables * sz);
|
2020-01-20 17:17:27 +01:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-02-12 13:24:25 -08:00
|
|
|
void __init efi_init(void)
|
|
|
|
{
|
2020-01-03 12:39:45 +01:00
|
|
|
if (IS_ENABLED(CONFIG_X86_32) &&
|
|
|
|
(boot_params.efi_info.efi_systab_hi ||
|
|
|
|
boot_params.efi_info.efi_memmap_hi)) {
|
2012-02-12 13:24:29 -08:00
|
|
|
pr_info("Table located above 4GB, disabling EFI.\n");
|
|
|
|
return;
|
|
|
|
}
|
2012-02-12 13:24:25 -08:00
|
|
|
|
2020-01-03 12:39:45 +01:00
|
|
|
efi_systab_phys = boot_params.efi_info.efi_systab |
|
|
|
|
((__u64)boot_params.efi_info.efi_systab_hi << 32);
|
|
|
|
|
|
|
|
if (efi_systab_init(efi_systab_phys))
|
2012-02-12 13:24:28 -08:00
|
|
|
return;
|
2012-11-14 09:42:35 +00:00
|
|
|
|
2020-01-20 17:23:21 +01:00
|
|
|
if (efi_reuse_config(efi_config_table, efi_nr_tables))
|
2013-12-20 18:02:19 +08:00
|
|
|
return;
|
|
|
|
|
2013-09-05 11:34:54 +01:00
|
|
|
if (efi_config_init(arch_tables))
|
2012-02-12 13:24:28 -08:00
|
|
|
return;
|
2012-11-14 09:42:35 +00:00
|
|
|
|
2012-02-12 13:24:29 -08: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())
|
2021-05-15 10:14:04 +02:00
|
|
|
pr_err("No EFI runtime due to 32/64-bit mismatch with kernel\n");
|
efi/x86: Drop two near identical versions of efi_runtime_init()
The routines efi_runtime_init32() and efi_runtime_init64() are
almost indistinguishable, and the only relevant difference is
the offset in the runtime struct from where to obtain the physical
address of the SetVirtualAddressMap() routine.
However, this address is only used once, when installing the virtual
address map that the OS will use to invoke EFI runtime services, and
at the time of the call, we will necessarily be running with a 1:1
mapping, and so there is no need to do the map/unmap dance here to
retrieve the address. In fact, in the preceding changes to these users,
we stopped using the address recorded here entirely.
So let's just get rid of all this code since it no longer serves a
purpose. While at it, tweak the logic so that we handle unsupported
and disable EFI runtime services in the same way, and unmap the EFI
memory map in both cases.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Matthew Garrett <mjg59@google.com>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20200103113953.9571-12-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-01-03 12:39:44 +01:00
|
|
|
|
|
|
|
if (!efi_runtime_supported() || efi_runtime_disabled()) {
|
|
|
|
efi_memmap_unmap();
|
|
|
|
return;
|
2012-02-12 13:24:28 -08:00
|
|
|
}
|
2012-11-14 09:42:35 +00:00
|
|
|
|
2020-01-19 16:17:59 +01:00
|
|
|
/* Parse the EFI Properties table if it exists */
|
|
|
|
if (prop_phys != EFI_INVALID_TABLE_ADDR) {
|
|
|
|
efi_properties_table_t *tbl;
|
|
|
|
|
|
|
|
tbl = early_memremap_ro(prop_phys, sizeof(*tbl));
|
|
|
|
if (tbl == NULL) {
|
|
|
|
pr_err("Could not map Properties table!\n");
|
|
|
|
} else {
|
|
|
|
if (tbl->memory_protection_attribute &
|
|
|
|
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA)
|
|
|
|
set_bit(EFI_NX_PE_DATA, &efi.flags);
|
|
|
|
|
|
|
|
early_memunmap(tbl, sizeof(*tbl));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
efi/x86: Drop two near identical versions of efi_runtime_init()
The routines efi_runtime_init32() and efi_runtime_init64() are
almost indistinguishable, and the only relevant difference is
the offset in the runtime struct from where to obtain the physical
address of the SetVirtualAddressMap() routine.
However, this address is only used once, when installing the virtual
address map that the OS will use to invoke EFI runtime services, and
at the time of the call, we will necessarily be running with a 1:1
mapping, and so there is no need to do the map/unmap dance here to
retrieve the address. In fact, in the preceding changes to these users,
we stopped using the address recorded here entirely.
So let's just get rid of all this code since it no longer serves a
purpose. While at it, tweak the logic so that we handle unsupported
and disable EFI runtime services in the same way, and unmap the EFI
memory map in both cases.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Matthew Garrett <mjg59@google.com>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20200103113953.9571-12-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-01-03 12:39:44 +01:00
|
|
|
set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
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 18:42:28 -05:00
|
|
|
efi_clean_memmap();
|
|
|
|
|
2015-02-05 11:44:41 +01:00
|
|
|
if (efi_enabled(EFI_DBG))
|
2015-09-30 19:20:00 +09:00
|
|
|
efi_print_memmap();
|
2008-01-30 13:31:19 +01:00
|
|
|
}
|
|
|
|
|
2013-12-20 18:02:16 +08:00
|
|
|
/* Merge contiguous regions of the same type and attribute */
|
|
|
|
static void __init efi_merge_regions(void)
|
2008-01-30 13:31:19 +01:00
|
|
|
{
|
2011-05-05 15:19:44 -04:00
|
|
|
efi_memory_desc_t *md, *prev_md = NULL;
|
|
|
|
|
2016-04-25 21:06:38 +01:00
|
|
|
for_each_efi_memory_desc(md) {
|
2011-05-05 15:19:44 -04: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 18:02:16 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-01-18 12:48:17 +01: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 23:02:18 +01: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 21:06:39 +01: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 23:02:18 +01:00
|
|
|
|
2016-04-25 21:06:39 +01: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 23:02:18 +01: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)
|
|
|
|
{
|
2020-07-13 16:30:05 -05:00
|
|
|
if (efi_enabled(EFI_64BIT)) {
|
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 23:02:18 +01:00
|
|
|
/*
|
|
|
|
* 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 21:06:39 +01: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 23:02:18 +01:00
|
|
|
|
2016-04-25 21:06:39 +01: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 23:02:18 +01:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return entry;
|
|
|
|
}
|
|
|
|
|
2016-06-20 14:36:51 +01: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-06 17:43:16 -08: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 14:36:51 +01:00
|
|
|
/*
|
|
|
|
* Map all of RAM so that we can access arguments in the 1:1
|
|
|
|
* mapping when making EFI runtime calls.
|
|
|
|
*/
|
2019-12-24 16:10:06 +01:00
|
|
|
if (efi_is_mixed()) {
|
2016-06-20 14:36:51 +01:00
|
|
|
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 18:02:16 +08:00
|
|
|
/*
|
2014-01-18 12:48:17 +01:00
|
|
|
* Map the efi memory ranges of the runtime services and update new_mmap with
|
|
|
|
* virtual addresses.
|
2013-12-20 18:02:16 +08:00
|
|
|
*/
|
2014-01-18 12:48:17 +01:00
|
|
|
static void * __init efi_map_regions(int *count, int *pg_shift)
|
2013-12-20 18:02:16 +08:00
|
|
|
{
|
2014-01-18 12:48:17 +01:00
|
|
|
void *p, *new_memmap = NULL;
|
|
|
|
unsigned long left = 0;
|
2016-04-25 21:06:39 +01:00
|
|
|
unsigned long desc_size;
|
2013-12-20 18:02:16 +08:00
|
|
|
efi_memory_desc_t *md;
|
2011-05-05 15:19:44 -04:00
|
|
|
|
2016-04-25 21:06:39 +01: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 23:02:18 +01:00
|
|
|
p = NULL;
|
|
|
|
while ((p = efi_map_next_entry(p))) {
|
2008-01-30 13:31:19 +01:00
|
|
|
md = p;
|
2016-06-20 14:36:51 +01:00
|
|
|
|
|
|
|
if (!should_map_region(md))
|
|
|
|
continue;
|
2008-02-04 16:48:06 +01:00
|
|
|
|
2013-10-31 17:25:08 +01:00
|
|
|
efi_map_region(md);
|
2013-12-20 18:02:16 +08:00
|
|
|
|
2016-04-25 21:06:39 +01:00
|
|
|
if (left < desc_size) {
|
2014-01-18 12:48:17 +01:00
|
|
|
new_memmap = realloc_pages(new_memmap, *pg_shift);
|
|
|
|
if (!new_memmap)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
left += PAGE_SIZE << *pg_shift;
|
|
|
|
(*pg_shift)++;
|
|
|
|
}
|
|
|
|
|
2016-04-25 21:06:39 +01:00
|
|
|
memcpy(new_memmap + (*count * desc_size), md, desc_size);
|
2014-01-18 12:48:17 +01:00
|
|
|
|
2016-04-25 21:06:39 +01:00
|
|
|
left -= desc_size;
|
2013-12-20 18:02:16 +08:00
|
|
|
(*count)++;
|
|
|
|
}
|
2013-10-31 17:25:08 +01:00
|
|
|
|
2013-12-20 18:02:16 +08:00
|
|
|
return new_memmap;
|
|
|
|
}
|
|
|
|
|
2014-01-18 12:48:18 +01:00
|
|
|
static void __init kexec_enter_virtual_mode(void)
|
|
|
|
{
|
2015-09-09 15:38:55 -07:00
|
|
|
#ifdef CONFIG_KEXEC_CORE
|
2014-01-18 12:48:18 +01:00
|
|
|
efi_memory_desc_t *md;
|
2016-01-21 14:11:59 +00:00
|
|
|
unsigned int num_pages;
|
2014-01-18 12:48:18 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't do virtual mode, since we don't do runtime services, on
|
2020-07-13 16:30:05 -05:00
|
|
|
* non-native EFI.
|
2014-01-18 12:48:18 +01:00
|
|
|
*/
|
2020-07-13 16:30:05 -05:00
|
|
|
if (efi_is_mixed()) {
|
2016-02-26 21:22:05 +00:00
|
|
|
efi_memmap_unmap();
|
2014-08-14 17:15:31 +08:00
|
|
|
clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
2014-01-18 12:48:18 +01: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 12:48:18 +01: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.
|
|
|
|
*/
|
2020-01-21 10:16:32 +01:00
|
|
|
for_each_efi_memory_desc(md)
|
2014-01-18 12:48:18 +01:00
|
|
|
efi_map_region_fixed(md); /* FIXME: add error handling */
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2016-04-25 21:06:39 +01: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 21:06:39 +01: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 12:48:18 +01:00
|
|
|
efi_sync_low_kernel_mappings();
|
2014-06-26 12:09:05 +02:00
|
|
|
efi_native_runtime_setup();
|
2014-01-18 12:48:18 +01:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2013-12-20 18:02:16 +08: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 18:02:16 +08:00
|
|
|
*
|
|
|
|
* 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 18:02:19 +08: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 12:48:18 +01:00
|
|
|
* to the same virtual addresses as the first kernel, see
|
|
|
|
* kexec_enter_virtual_mode().
|
2013-12-20 18:02:16 +08:00
|
|
|
*/
|
2014-01-18 12:48:18 +01:00
|
|
|
static void __init __efi_enter_virtual_mode(void)
|
2013-12-20 18:02:16 +08:00
|
|
|
{
|
2014-01-18 12:48:18 +01:00
|
|
|
int count = 0, pg_shift = 0;
|
2013-12-20 18:02:16 +08:00
|
|
|
void *new_memmap = NULL;
|
2014-01-18 12:48:17 +01:00
|
|
|
efi_status_t status;
|
2016-11-12 21:04:23 +00:00
|
|
|
unsigned long pa;
|
2008-02-04 16:48:06 +01:00
|
|
|
|
2015-11-27 21:09:34 +00:00
|
|
|
if (efi_alloc_page_tables()) {
|
|
|
|
pr_err("Failed to allocate EFI page tables\n");
|
2020-01-03 12:39:46 +01:00
|
|
|
goto err;
|
2015-11-27 21:09:34 +00:00
|
|
|
}
|
|
|
|
|
2014-01-18 12:48:18 +01: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");
|
2020-01-03 12:39:46 +01:00
|
|
|
goto err;
|
2014-01-18 12:48:17 +01:00
|
|
|
}
|
2013-12-20 18:02:18 +08: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");
|
2020-01-03 12:39:46 +01:00
|
|
|
goto err;
|
2016-02-27 15:52:50 +00:00
|
|
|
}
|
|
|
|
|
2017-01-31 13:21:41 +00:00
|
|
|
if (efi_enabled(EFI_DBG)) {
|
|
|
|
pr_info("EFI runtime memory map:\n");
|
|
|
|
efi_print_memmap();
|
|
|
|
}
|
|
|
|
|
2020-01-03 12:39:46 +01:00
|
|
|
if (efi_setup_page_tables(pa, 1 << pg_shift))
|
|
|
|
goto err;
|
2014-01-18 12:48:17 +01:00
|
|
|
|
2013-10-31 17:25:08 +01:00
|
|
|
efi_sync_low_kernel_mappings();
|
|
|
|
|
2020-01-03 12:39:43 +01:00
|
|
|
status = efi_set_virtual_address_map(efi.memmap.desc_size * count,
|
|
|
|
efi.memmap.desc_size,
|
|
|
|
efi.memmap.desc_version,
|
2020-01-21 09:44:43 +01:00
|
|
|
(efi_memory_desc_t *)pa,
|
|
|
|
efi_systab_phys);
|
2014-01-18 12:48:18 +01:00
|
|
|
if (status != EFI_SUCCESS) {
|
2020-01-03 12:39:46 +01:00
|
|
|
pr_err("Unable to switch EFI into virtual mode (status=%lx)!\n",
|
|
|
|
status);
|
|
|
|
goto err;
|
2008-01-30 13:31:19 +01:00
|
|
|
}
|
|
|
|
|
efi: Add embedded peripheral firmware support
Just like with PCI options ROMs, which we save in the setup_efi_pci*
functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself
sometimes may contain data which is useful/necessary for peripheral drivers
to have access to.
Specifically the EFI code may contain an embedded copy of firmware which
needs to be (re)loaded into the peripheral. Normally such firmware would be
part of linux-firmware, but in some cases this is not feasible, for 2
reasons:
1) The firmware is customized for a specific use-case of the chipset / use
with a specific hardware model, so we cannot have a single firmware file
for the chipset. E.g. touchscreen controller firmwares are compiled
specifically for the hardware model they are used with, as they are
calibrated for a specific model digitizer.
2) Despite repeated attempts we have failed to get permission to
redistribute the firmware. This is especially a problem with customized
firmwares, these get created by the chip vendor for a specific ODM and the
copyright may partially belong with the ODM, so the chip vendor cannot
give a blanket permission to distribute these.
This commit adds support for finding peripheral firmware embedded in the
EFI code and makes the found firmware available through the new
efi_get_embedded_fw() function.
Support for loading these firmwares through the standard firmware loading
mechanism is added in a follow-up commit in this patch-series.
Note we check the EFI_BOOT_SERVICES_CODE for embedded firmware near the end
of start_kernel(), just before calling rest_init(), this is on purpose
because the typical EFI_BOOT_SERVICES_CODE memory-segment is too large for
early_memremap(), so the check must be done after mm_init(). This relies
on EFI_BOOT_SERVICES_CODE not being free-ed until efi_free_boot_services()
is called, which means that this will only work on x86 for now.
Reported-by: Dave Olsthoorn <dave@bewaar.me>
Suggested-by: Peter Jones <pjones@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200115163554.101315-3-hdegoede@redhat.com
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-01-15 17:35:46 +01:00
|
|
|
efi_check_for_embedded_firmwares();
|
2018-11-29 18:12:25 +01:00
|
|
|
efi_free_boot_services();
|
|
|
|
|
2019-12-24 16:10:06 +01:00
|
|
|
if (!efi_is_mixed())
|
2014-06-26 12:09:05 +02:00
|
|
|
efi_native_runtime_setup();
|
2014-01-10 18:48:30 +00:00
|
|
|
else
|
|
|
|
efi_thunk_runtime_setup();
|
|
|
|
|
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 13:24:29 -08:00
|
|
|
|
2013-06-01 16:06:20 -04:00
|
|
|
/* clean DUMMY object */
|
2014-06-02 05:18:35 -07:00
|
|
|
efi_delete_dummy_variable();
|
2020-01-03 12:39:46 +01:00
|
|
|
return;
|
|
|
|
|
|
|
|
err:
|
|
|
|
clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
|
2008-01-30 13:31:19 +01:00
|
|
|
}
|
|
|
|
|
2014-01-18 12:48:18 +01:00
|
|
|
void __init efi_enter_virtual_mode(void)
|
|
|
|
{
|
2014-06-30 19:52:58 +02:00
|
|
|
if (efi_enabled(EFI_PARAVIRT))
|
|
|
|
return;
|
|
|
|
|
2020-01-21 09:44:43 +01:00
|
|
|
efi.runtime = (efi_runtime_services_t *)efi_runtime;
|
|
|
|
|
2014-01-18 12:48:18 +01: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 12:48:18 +01:00
|
|
|
}
|
|
|
|
|
2019-06-25 15:36:45 +02: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;
|
|
|
|
}
|
2020-01-19 16:17:59 +01:00
|
|
|
|
|
|
|
char *efi_systab_show_arch(char *str)
|
|
|
|
{
|
|
|
|
if (uga_phys != EFI_INVALID_TABLE_ADDR)
|
|
|
|
str += sprintf(str, "UGA=0x%lx\n", uga_phys);
|
|
|
|
return str;
|
|
|
|
}
|
2020-01-20 17:23:21 +01:00
|
|
|
|
|
|
|
#define EFI_FIELD(var) efi_ ## var
|
|
|
|
|
|
|
|
#define EFI_ATTR_SHOW(name) \
|
|
|
|
static ssize_t name##_show(struct kobject *kobj, \
|
|
|
|
struct kobj_attribute *attr, char *buf) \
|
|
|
|
{ \
|
|
|
|
return sprintf(buf, "0x%lx\n", EFI_FIELD(name)); \
|
|
|
|
}
|
|
|
|
|
|
|
|
EFI_ATTR_SHOW(fw_vendor);
|
|
|
|
EFI_ATTR_SHOW(runtime);
|
|
|
|
EFI_ATTR_SHOW(config_table);
|
|
|
|
|
|
|
|
struct kobj_attribute efi_attr_fw_vendor = __ATTR_RO(fw_vendor);
|
|
|
|
struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
|
|
|
|
struct kobj_attribute efi_attr_config_table = __ATTR_RO(config_table);
|
|
|
|
|
|
|
|
umode_t efi_attr_is_visible(struct kobject *kobj, struct attribute *attr, int n)
|
|
|
|
{
|
|
|
|
if (attr == &efi_attr_fw_vendor.attr) {
|
|
|
|
if (efi_enabled(EFI_PARAVIRT) ||
|
|
|
|
efi_fw_vendor == EFI_INVALID_TABLE_ADDR)
|
|
|
|
return 0;
|
|
|
|
} else if (attr == &efi_attr_runtime.attr) {
|
|
|
|
if (efi_runtime == EFI_INVALID_TABLE_ADDR)
|
|
|
|
return 0;
|
|
|
|
} else if (attr == &efi_attr_config_table.attr) {
|
|
|
|
if (efi_config_table == EFI_INVALID_TABLE_ADDR)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return attr->mode;
|
|
|
|
}
|