2019-05-19 20:07:45 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2013-02-08 23:48:51 +08:00
|
|
|
menu "EFI (Extensible Firmware Interface) Support"
|
|
|
|
|
depends on EFI
|
|
|
|
|
|
|
|
|
|
config EFI_VARS
|
|
|
|
|
tristate "EFI Variable Support via sysfs"
|
2020-09-23 16:20:10 +08:00
|
|
|
depends on EFI && (X86 || IA64)
|
2013-02-08 23:48:51 +08:00
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
If you say Y here, you are able to get EFI (Extensible Firmware
|
|
|
|
|
Interface) variable information via sysfs. You may read,
|
|
|
|
|
write, create, and destroy EFI variables through this interface.
|
2020-09-23 16:20:10 +08:00
|
|
|
Note that this driver is only retained for compatibility with
|
|
|
|
|
legacy users: new users should use the efivarfs filesystem
|
|
|
|
|
instead.
|
2013-02-08 23:48:51 +08:00
|
|
|
|
efi: Work around ia64 build problem with ESRT driver
So, I'm told this problem exists in the world:
> Subject: Build error in -next due to 'efi: Add esrt support'
>
> Building ia64:defconfig ... failed
> --------------
> Error log:
>
> drivers/firmware/efi/esrt.c:28:31: fatal error: asm/early_ioremap.h: No such file or directory
>
I'm not really sure how it's okay that we have things in asm-generic on
some platforms but not others - is having it the same everywhere not the
whole point of asm-generic?
That said, ia64 doesn't have early_ioremap.h . So instead, since it's
difficult to imagine new IA64 machines with UEFI 2.5, just don't build
this code there.
To me this looks like a workaround - doing something like:
generic-y += early_ioremap.h
in arch/ia64/include/asm/Kbuild would appear to be more correct, but
ia64 has its own early_memremap() decl in arch/ia64/include/asm/io.h ,
and it's a macro. So adding the above /and/ requiring that asm/io.h be
included /after/ asm/early_ioremap.h in all cases would fix it, but
that's pretty ugly as well. Since I'm not going to spend the rest of my
life rectifying ia64 headers vs "generic" headers that aren't generic,
it's much simpler to just not build there.
Note that I've only actually tried to build this patch on x86_64, but
esrt.o still gets built there, and that would seem to demonstrate that
the conditional building is working correctly at all the places the code
built before. I no longer have any ia64 machines handy to test that the
exclusion actually works there.
Signed-off-by: Peter Jones <pjones@redhat.com>
Acked-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
(Compile-)Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2015-06-06 03:14:54 +08:00
|
|
|
config EFI_ESRT
|
|
|
|
|
bool
|
|
|
|
|
depends on EFI && !IA64
|
|
|
|
|
default y
|
|
|
|
|
|
2013-02-08 23:48:51 +08:00
|
|
|
config EFI_VARS_PSTORE
|
|
|
|
|
tristate "Register efivars backend for pstore"
|
2020-09-23 15:56:14 +08:00
|
|
|
depends on PSTORE
|
2013-02-08 23:48:51 +08:00
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Say Y here to enable use efivars as a backend to pstore. This
|
|
|
|
|
will allow writing console messages, crash dumps, or anything
|
|
|
|
|
else supported by pstore to EFI variables.
|
|
|
|
|
|
|
|
|
|
config EFI_VARS_PSTORE_DEFAULT_DISABLE
|
|
|
|
|
bool "Disable using efivars as a pstore backend by default"
|
|
|
|
|
depends on EFI_VARS_PSTORE
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Saying Y here will disable the use of efivars as a storage
|
|
|
|
|
backend for pstore by default. This setting can be overridden
|
|
|
|
|
using the efivars module's pstore_disable parameter.
|
|
|
|
|
|
2013-12-20 18:02:18 +08:00
|
|
|
config EFI_RUNTIME_MAP
|
|
|
|
|
bool "Export efi runtime maps to sysfs"
|
2015-09-10 06:38:55 +08:00
|
|
|
depends on X86 && EFI && KEXEC_CORE
|
2013-12-20 18:02:18 +08:00
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Export efi runtime memory maps to /sys/firmware/efi/runtime-map.
|
|
|
|
|
That memory map is used for example by kexec to set up efi virtual
|
|
|
|
|
mapping the 2nd kernel, but can also be used for debugging purposes.
|
|
|
|
|
|
|
|
|
|
See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map.
|
|
|
|
|
|
2015-09-30 22:01:56 +08:00
|
|
|
config EFI_FAKE_MEMMAP
|
|
|
|
|
bool "Enable EFI fake memory map"
|
|
|
|
|
depends on EFI && X86
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Saying Y here will enable "efi_fake_mem" boot option.
|
|
|
|
|
By specifying this parameter, you can add arbitrary attribute
|
|
|
|
|
to specific memory range by updating original (firmware provided)
|
|
|
|
|
EFI memmap.
|
|
|
|
|
This is useful for debugging of EFI memmap related feature.
|
|
|
|
|
e.g. Address Range Mirroring feature.
|
|
|
|
|
|
|
|
|
|
config EFI_MAX_FAKE_MEM
|
|
|
|
|
int "maximum allowable number of ranges in efi_fake_mem boot option"
|
|
|
|
|
depends on EFI_FAKE_MEMMAP
|
|
|
|
|
range 1 128
|
|
|
|
|
default 8
|
|
|
|
|
help
|
|
|
|
|
Maximum allowable number of ranges in efi_fake_mem boot option.
|
|
|
|
|
Ranges can be set up to this value using comma-separated list.
|
|
|
|
|
The default value is 8.
|
|
|
|
|
|
2019-11-07 09:43:11 +08:00
|
|
|
config EFI_SOFT_RESERVE
|
|
|
|
|
bool "Reserve EFI Specific Purpose Memory"
|
|
|
|
|
depends on EFI && EFI_STUB && ACPI_HMAT
|
|
|
|
|
default ACPI_HMAT
|
|
|
|
|
help
|
|
|
|
|
On systems that have mixed performance classes of memory EFI
|
|
|
|
|
may indicate specific purpose memory with an attribute (See
|
|
|
|
|
EFI_MEMORY_SP in UEFI 2.8). A memory range tagged with this
|
|
|
|
|
attribute may have unique performance characteristics compared
|
|
|
|
|
to the system's general purpose "System RAM" pool. On the
|
|
|
|
|
expectation that such memory has application specific usage,
|
|
|
|
|
and its base EFI memory type is "conventional" answer Y to
|
|
|
|
|
arrange for the kernel to reserve it as a "Soft Reserved"
|
|
|
|
|
resource, and set aside for direct-access (device-dax) by
|
|
|
|
|
default. The memory range can later be optionally assigned to
|
|
|
|
|
the page allocator by system administrator policy via the
|
|
|
|
|
device-dax kmem facility. Say N to have the kernel treat this
|
|
|
|
|
memory as "System RAM" by default.
|
|
|
|
|
|
|
|
|
|
If unsure, say Y.
|
|
|
|
|
|
2022-03-03 22:21:20 +08:00
|
|
|
config EFI_DXE_MEM_ATTRIBUTES
|
|
|
|
|
bool "Adjust memory attributes in EFISTUB"
|
|
|
|
|
depends on EFI && EFI_STUB && X86
|
|
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
UEFI specification does not guarantee all memory to be
|
|
|
|
|
accessible for both write and execute as the kernel expects
|
|
|
|
|
it to be.
|
|
|
|
|
Use DXE services to check and alter memory protection
|
|
|
|
|
attributes during boot via EFISTUB to ensure that memory
|
|
|
|
|
ranges used by the kernel are writable and executable.
|
|
|
|
|
|
2013-12-31 01:12:12 +08:00
|
|
|
config EFI_PARAMS_FROM_FDT
|
|
|
|
|
bool
|
|
|
|
|
help
|
|
|
|
|
Select this config option from the architecture Kconfig if
|
|
|
|
|
the EFI runtime support gets system table address, memory
|
|
|
|
|
map address, and other parameters from the device tree.
|
|
|
|
|
|
2014-06-26 18:09:05 +08:00
|
|
|
config EFI_RUNTIME_WRAPPERS
|
|
|
|
|
bool
|
|
|
|
|
|
2020-04-16 03:54:18 +08:00
|
|
|
config EFI_GENERIC_STUB
|
2014-07-02 20:54:43 +08:00
|
|
|
bool
|
|
|
|
|
|
efi/libstub/arm: Add opt-in Kconfig option for the DTB loader
There are various ways a platform can provide a device tree binary
to the kernel, with different levels of sophistication:
- ideally, the UEFI firmware, which is tightly coupled with the
platform, provides a device tree image directly as a UEFI
configuration table, and typically permits the contents to be
manipulated either via menu options or via UEFI environment
variables that specify a replacement image,
- GRUB for ARM has a 'devicetree' directive which allows a device
tree image to be loaded from any location accessible to GRUB, and
supersede the one provided by the firmware,
- the EFI stub implements a dtb= command line option that allows a
device tree image to be loaded from a file residing in the same
file system as the one the kernel image was loaded from.
The dtb= command line option was never intended to be more than a
development feature, to allow the other options to be implemented
in parallel. So let's make it an opt-in feature that is disabled
by default, but can be re-enabled at will.
Note that we already disable the dtb= command line option when we
detect that we are running with UEFI Secure Boot enabled.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-7-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:38 +08:00
|
|
|
config EFI_ARMSTUB_DTB_LOADER
|
|
|
|
|
bool "Enable the DTB loader"
|
2020-09-18 06:37:14 +08:00
|
|
|
depends on EFI_GENERIC_STUB && !RISCV
|
2018-09-12 04:26:38 +08:00
|
|
|
default y
|
efi/libstub/arm: Add opt-in Kconfig option for the DTB loader
There are various ways a platform can provide a device tree binary
to the kernel, with different levels of sophistication:
- ideally, the UEFI firmware, which is tightly coupled with the
platform, provides a device tree image directly as a UEFI
configuration table, and typically permits the contents to be
manipulated either via menu options or via UEFI environment
variables that specify a replacement image,
- GRUB for ARM has a 'devicetree' directive which allows a device
tree image to be loaded from any location accessible to GRUB, and
supersede the one provided by the firmware,
- the EFI stub implements a dtb= command line option that allows a
device tree image to be loaded from a file residing in the same
file system as the one the kernel image was loaded from.
The dtb= command line option was never intended to be more than a
development feature, to allow the other options to be implemented
in parallel. So let's make it an opt-in feature that is disabled
by default, but can be re-enabled at will.
Note that we already disable the dtb= command line option when we
detect that we are running with UEFI Secure Boot enabled.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-7-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:38 +08:00
|
|
|
help
|
|
|
|
|
Select this config option to add support for the dtb= command
|
|
|
|
|
line parameter, allowing a device tree blob to be loaded into
|
|
|
|
|
memory from the EFI System Partition by the stub.
|
|
|
|
|
|
2018-09-12 04:26:38 +08:00
|
|
|
If the device tree is provided by the platform or by
|
|
|
|
|
the bootloader this option may not be needed.
|
|
|
|
|
But, for various development reasons and to maintain existing
|
|
|
|
|
functionality for bootloaders that do not have such support
|
|
|
|
|
this option is necessary.
|
efi/libstub/arm: Add opt-in Kconfig option for the DTB loader
There are various ways a platform can provide a device tree binary
to the kernel, with different levels of sophistication:
- ideally, the UEFI firmware, which is tightly coupled with the
platform, provides a device tree image directly as a UEFI
configuration table, and typically permits the contents to be
manipulated either via menu options or via UEFI environment
variables that specify a replacement image,
- GRUB for ARM has a 'devicetree' directive which allows a device
tree image to be loaded from any location accessible to GRUB, and
supersede the one provided by the firmware,
- the EFI stub implements a dtb= command line option that allows a
device tree image to be loaded from a file residing in the same
file system as the one the kernel image was loaded from.
The dtb= command line option was never intended to be more than a
development feature, to allow the other options to be implemented
in parallel. So let's make it an opt-in feature that is disabled
by default, but can be re-enabled at will.
Note that we already disable the dtb= command line option when we
detect that we are running with UEFI Secure Boot enabled.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-7-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:38 +08:00
|
|
|
|
2020-04-21 15:17:35 +08:00
|
|
|
config EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
|
2020-04-25 18:22:04 +08:00
|
|
|
bool "Enable the command line initrd loader" if !X86
|
|
|
|
|
depends on EFI_STUB && (EFI_GENERIC_STUB || X86)
|
2020-10-28 23:34:02 +08:00
|
|
|
default y if X86
|
2020-09-18 06:37:14 +08:00
|
|
|
depends on !RISCV
|
2020-04-21 15:17:35 +08:00
|
|
|
help
|
|
|
|
|
Select this config option to add support for the initrd= command
|
|
|
|
|
line parameter, allowing an initrd that resides on the same volume
|
|
|
|
|
as the kernel image to be loaded into memory.
|
|
|
|
|
|
|
|
|
|
This method is deprecated.
|
|
|
|
|
|
2016-04-26 04:06:57 +08:00
|
|
|
config EFI_BOOTLOADER_CONTROL
|
|
|
|
|
tristate "EFI Bootloader Control"
|
2022-06-20 17:35:37 +08:00
|
|
|
select UCS2_STRING
|
2016-04-26 04:06:57 +08:00
|
|
|
default n
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2016-04-26 04:06:57 +08:00
|
|
|
This module installs a reboot hook, such that if reboot() is
|
|
|
|
|
invoked with a string argument NNN, "NNN" is copied to the
|
|
|
|
|
"LoaderEntryOneShot" EFI variable, to be read by the
|
|
|
|
|
bootloader. If the string matches one of the boot labels
|
|
|
|
|
defined in its configuration, the bootloader will boot once
|
|
|
|
|
to that label. The "LoaderEntryRebootReason" EFI variable is
|
|
|
|
|
set with the reboot reason: "reboot" or "shutdown". The
|
|
|
|
|
bootloader reads this reboot reason and takes particular
|
|
|
|
|
action according to its policy.
|
|
|
|
|
|
2016-04-26 04:07:01 +08:00
|
|
|
config EFI_CAPSULE_LOADER
|
|
|
|
|
tristate "EFI capsule loader"
|
2020-12-13 16:39:40 +08:00
|
|
|
depends on EFI && !IA64
|
2016-04-26 04:07:01 +08:00
|
|
|
help
|
|
|
|
|
This option exposes a loader interface "/dev/efi_capsule_loader" for
|
|
|
|
|
users to load EFI capsules. This driver requires working runtime
|
|
|
|
|
capsule support in the firmware, which many OEMs do not provide.
|
|
|
|
|
|
|
|
|
|
Most users should say N.
|
|
|
|
|
|
2017-06-02 21:52:04 +08:00
|
|
|
config EFI_CAPSULE_QUIRK_QUARK_CSH
|
2017-12-15 23:38:01 +08:00
|
|
|
bool "Add support for Quark capsules with non-standard headers"
|
2017-06-02 21:52:04 +08:00
|
|
|
depends on X86 && !64BIT
|
|
|
|
|
select EFI_CAPSULE_LOADER
|
|
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Add support for processing Quark X1000 EFI capsules, whose header
|
|
|
|
|
layout deviates from the layout mandated by the UEFI specification.
|
|
|
|
|
|
2016-08-25 11:15:31 +08:00
|
|
|
config EFI_TEST
|
|
|
|
|
tristate "EFI Runtime Service Tests Support"
|
|
|
|
|
depends on EFI
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
This driver uses the efi.<service> function pointers directly instead
|
|
|
|
|
of going through the efivar API, because it is not trying to test the
|
|
|
|
|
kernel subsystem, just for testing the UEFI runtime service
|
|
|
|
|
interfaces which are provided by the firmware. This driver is used
|
|
|
|
|
by the Firmware Test Suite (FWTS) for testing the UEFI runtime
|
|
|
|
|
interfaces readiness of the firmware.
|
|
|
|
|
Details for FWTS are available from:
|
|
|
|
|
<https://wiki.ubuntu.com/FirmwareTestSuite>
|
|
|
|
|
|
|
|
|
|
Say Y here to enable the runtime services support via /dev/efi_test.
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2022-05-28 17:49:54 +08:00
|
|
|
config EFI_DEV_PATH_PARSER
|
|
|
|
|
bool
|
|
|
|
|
|
x86/efi: Retrieve and assign Apple device properties
Apple's EFI drivers supply device properties which are needed to support
Macs optimally. They contain vital information which cannot be obtained
any other way (e.g. Thunderbolt Device ROM). They're also used to convey
the current device state so that OS drivers can pick up where EFI
drivers left (e.g. GPU mode setting).
There's an EFI driver dubbed "AAPL,PathProperties" which implements a
per-device key/value store. Other EFI drivers populate it using a custom
protocol. The macOS bootloader /System/Library/CoreServices/boot.efi
retrieves the properties with the same protocol. The kernel extension
AppleACPIPlatform.kext subsequently merges them into the I/O Kit
registry (see ioreg(8)) where they can be queried by other kernel
extensions and user space.
This commit extends the efistub to retrieve the device properties before
ExitBootServices is called. It assigns them to devices in an fs_initcall
so that they can be queried with the API in <linux/property.h>.
Note that the device properties will only be available if the kernel is
booted with the efistub. Distros should adjust their installers to
always use the efistub on Macs. grub with the "linux" directive will not
work unless the functionality of this commit is duplicated in grub.
(The "linuxefi" directive should work but is not included upstream as of
this writing.)
The custom protocol has GUID 91BD12FE-F6C3-44FB-A5B7-5122AB303AE0 and
looks like this:
typedef struct {
unsigned long version; /* 0x10000 */
efi_status_t (*get) (
IN struct apple_properties_protocol *this,
IN struct efi_dev_path *device,
IN efi_char16_t *property_name,
OUT void *buffer,
IN OUT u32 *buffer_len);
/* EFI_SUCCESS, EFI_NOT_FOUND, EFI_BUFFER_TOO_SMALL */
efi_status_t (*set) (
IN struct apple_properties_protocol *this,
IN struct efi_dev_path *device,
IN efi_char16_t *property_name,
IN void *property_value,
IN u32 property_value_len);
/* allocates copies of property name and value */
/* EFI_SUCCESS, EFI_OUT_OF_RESOURCES */
efi_status_t (*del) (
IN struct apple_properties_protocol *this,
IN struct efi_dev_path *device,
IN efi_char16_t *property_name);
/* EFI_SUCCESS, EFI_NOT_FOUND */
efi_status_t (*get_all) (
IN struct apple_properties_protocol *this,
OUT void *buffer,
IN OUT u32 *buffer_len);
/* EFI_SUCCESS, EFI_BUFFER_TOO_SMALL */
} apple_properties_protocol;
Thanks to Pedro Vilaça for this blog post which was helpful in reverse
engineering Apple's EFI drivers and bootloader:
https://reverse.put.as/2016/06/25/apple-efi-firmware-passwords-and-the-scbo-myth/
If someone at Apple is reading this, please note there's a memory leak
in your implementation of the del() function as the property struct is
freed but the name and value allocations are not.
Neither the macOS bootloader nor Apple's EFI drivers check the protocol
version, but we do to avoid breakage if it's ever changed. It's been the
same since at least OS X 10.6 (2009).
The get_all() function conveniently fills a buffer with all properties
in marshalled form which can be passed to the kernel as a setup_data
payload. The number of device properties is dynamic and can change
between a first invocation of get_all() (to determine the buffer size)
and a second invocation (to retrieve the actual buffer), hence the
peculiar loop which does not finish until the buffer size settles.
The macOS bootloader does the same.
The setup_data payload is later on unmarshalled in an fs_initcall. The
idea is that most buses instantiate devices in "subsys" initcall level
and drivers are usually bound to these devices in "device" initcall
level, so we assign the properties in-between, i.e. in "fs" initcall
level.
This assumes that devices to which properties pertain are instantiated
from a "subsys" initcall or earlier. That should always be the case
since on macOS, AppleACPIPlatformExpert::matchEFIDevicePath() only
supports ACPI and PCI nodes and we've fully scanned those buses during
"subsys" initcall level.
The second assumption is that properties are only needed from a "device"
initcall or later. Seems reasonable to me, but should this ever not work
out, an alternative approach would be to store the property sets e.g. in
a btree early during boot. Then whenever device_add() is called, an EFI
Device Path would have to be constructed for the newly added device,
and looked up in the btree. That way, the property set could be assigned
to the device immediately on instantiation. And this would also work for
devices instantiated in a deferred fashion. It seems like this approach
would be more complicated and require more code. That doesn't seem
justified without a specific use case.
For comparison, the strategy on macOS is to assign properties to objects
in the ACPI namespace (AppleACPIPlatformExpert::mergeEFIProperties()).
That approach is definitely wrong as it fails for devices not present in
the namespace: The NHI EFI driver supplies properties for attached
Thunderbolt devices, yet on Macs with Thunderbolt 1 only one device
level behind the host controller is described in the namespace.
Consequently macOS cannot assign properties for chained devices. With
Thunderbolt 2 they started to describe three device levels behind host
controllers in the namespace but this grossly inflates the SSDT and
still fails if the user daisy-chained more than three devices.
We copy the property names and values from the setup_data payload to
swappable virtual memory and afterwards make the payload available to
the page allocator. This is just for the sake of good housekeeping, it
wouldn't occupy a meaningful amount of physical memory (4444 bytes on my
machine). Only the payload is freed, not the setup_data header since
otherwise we'd break the list linkage and we cannot safely update the
predecessor's ->next link because there's no locking for the list.
The payload is currently not passed on to kexec'ed kernels, same for PCI
ROMs retrieved by setup_efi_pci(). This can be added later if there is
demand by amending setup_efi_state(). The payload can then no longer be
made available to the page allocator of course.
Tested-by: Lukas Wunner <lukas@wunner.de> [MacBookPro9,1]
Tested-by: Pierre Moreau <pierre.morrow@free.fr> [MacBookPro11,3]
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andreas Noever <andreas.noever@gmail.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pedro Vilaça <reverser@put.as>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: grub-devel@gnu.org
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20161112213237.8804-9-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-11-13 05:32:36 +08:00
|
|
|
config APPLE_PROPERTIES
|
|
|
|
|
bool "Apple Device Properties"
|
|
|
|
|
depends on EFI_STUB && X86
|
|
|
|
|
select EFI_DEV_PATH_PARSER
|
|
|
|
|
select UCS2_STRING
|
|
|
|
|
help
|
|
|
|
|
Retrieve properties from EFI on Apple Macs and assign them to
|
|
|
|
|
devices, allowing for improved support of Apple hardware.
|
|
|
|
|
Properties that would otherwise be missing include the
|
|
|
|
|
Thunderbolt Device ROM and GPU configuration data.
|
|
|
|
|
|
|
|
|
|
If unsure, say Y if you have a Mac. Otherwise N.
|
|
|
|
|
|
2017-08-25 23:50:15 +08:00
|
|
|
config RESET_ATTACK_MITIGATION
|
|
|
|
|
bool "Reset memory attack mitigation"
|
|
|
|
|
depends on EFI_STUB
|
|
|
|
|
help
|
|
|
|
|
Request that the firmware clear the contents of RAM after a reboot
|
|
|
|
|
using the TCG Platform Reset Attack Mitigation specification. This
|
|
|
|
|
protects against an attacker forcibly rebooting the system while it
|
|
|
|
|
still contains secrets in RAM, booting another OS and extracting the
|
2018-01-16 17:10:02 +08:00
|
|
|
secrets. This should only be enabled when userland is configured to
|
|
|
|
|
clear the MemoryOverwriteRequest flag on clean shutdown after secrets
|
|
|
|
|
have been evicted, since otherwise it will trigger even on clean
|
|
|
|
|
reboots.
|
2017-08-25 23:50:15 +08:00
|
|
|
|
2019-07-11 02:59:15 +08:00
|
|
|
config EFI_RCI2_TABLE
|
|
|
|
|
bool "EFI Runtime Configuration Interface Table Version 2 Support"
|
2019-10-30 01:37:50 +08:00
|
|
|
depends on X86 || COMPILE_TEST
|
2019-07-11 02:59:15 +08:00
|
|
|
help
|
|
|
|
|
Displays the content of the Runtime Configuration Interface
|
|
|
|
|
Table version 2 on Dell EMC PowerEdge systems as a binary
|
|
|
|
|
attribute 'rci2' under /sys/firmware/efi/tables directory.
|
|
|
|
|
|
|
|
|
|
RCI2 table contains BIOS HII in XML format and is used to populate
|
|
|
|
|
BIOS setup page in Dell EMC OpenManage Server Administrator tool.
|
|
|
|
|
The BIOS setup page contains BIOS tokens which can be configured.
|
|
|
|
|
|
|
|
|
|
Say Y here for Dell EMC PowerEdge systems.
|
|
|
|
|
|
2020-01-03 19:39:50 +08:00
|
|
|
config EFI_DISABLE_PCI_DMA
|
|
|
|
|
bool "Clear Busmaster bit on PCI bridges during ExitBootServices()"
|
|
|
|
|
help
|
|
|
|
|
Disable the busmaster bit in the control register on all PCI bridges
|
|
|
|
|
while calling ExitBootServices() and passing control to the runtime
|
|
|
|
|
kernel. System firmware may configure the IOMMU to prevent malicious
|
|
|
|
|
PCI devices from being able to attack the OS via DMA. However, since
|
|
|
|
|
firmware can't guarantee that the OS is IOMMU-aware, it will tear
|
|
|
|
|
down IOMMU configuration when ExitBootServices() is called. This
|
|
|
|
|
leaves a window between where a hostile device could still cause
|
|
|
|
|
damage before Linux configures the IOMMU again.
|
|
|
|
|
|
|
|
|
|
If you say Y here, the EFI stub will clear the busmaster bit on all
|
|
|
|
|
PCI bridges before ExitBootServices() is called. This will prevent
|
|
|
|
|
any malicious PCI devices from being able to perform DMA until the
|
|
|
|
|
kernel reenables busmastering after configuring the IOMMU.
|
|
|
|
|
|
|
|
|
|
This option will cause failures with some poorly behaved hardware
|
|
|
|
|
and should not be enabled without testing. The kernel commandline
|
|
|
|
|
options "efi=disable_early_pci_dma" or "efi=no_disable_early_pci_dma"
|
|
|
|
|
may be used to override this option.
|
|
|
|
|
|
2019-02-02 17:41:18 +08:00
|
|
|
config EFI_EARLYCON
|
|
|
|
|
def_bool y
|
2022-05-28 17:49:54 +08:00
|
|
|
depends on SERIAL_EARLYCON && !ARM && !IA64
|
2019-02-02 17:41:18 +08:00
|
|
|
select FONT_SUPPORT
|
|
|
|
|
select ARCH_USE_MEMREMAP_PROT
|
2020-06-16 04:24:08 +08:00
|
|
|
|
|
|
|
|
config EFI_CUSTOM_SSDT_OVERLAYS
|
|
|
|
|
bool "Load custom ACPI SSDT overlay from an EFI variable"
|
2022-05-28 17:49:54 +08:00
|
|
|
depends on ACPI
|
2020-06-16 04:24:08 +08:00
|
|
|
default ACPI_TABLE_UPGRADE
|
|
|
|
|
help
|
|
|
|
|
Allow loading of an ACPI SSDT overlay from an EFI variable specified
|
|
|
|
|
by a kernel command line option.
|
|
|
|
|
|
|
|
|
|
See Documentation/admin-guide/acpi/ssdt-overlays.rst for more
|
|
|
|
|
information.
|
2022-03-31 23:16:54 +08:00
|
|
|
|
|
|
|
|
config EFI_DISABLE_RUNTIME
|
|
|
|
|
bool "Disable EFI runtime services support by default"
|
|
|
|
|
default y if PREEMPT_RT
|
|
|
|
|
help
|
|
|
|
|
Allow to disable the EFI runtime services support by default. This can
|
|
|
|
|
already be achieved by using the efi=noruntime option, but it could be
|
|
|
|
|
useful to have this default without any kernel command line parameter.
|
|
|
|
|
|
|
|
|
|
The EFI runtime services are disabled by default when PREEMPT_RT is
|
|
|
|
|
enabled, because measurements have shown that some EFI functions calls
|
|
|
|
|
might take too much time to complete, causing large latencies which is
|
|
|
|
|
an issue for Real-Time kernels.
|
|
|
|
|
|
|
|
|
|
This default can be overridden by using the efi=runtime option.
|
2022-04-13 05:21:24 +08:00
|
|
|
|
|
|
|
|
config EFI_COCO_SECRET
|
|
|
|
|
bool "EFI Confidential Computing Secret Area Support"
|
|
|
|
|
help
|
|
|
|
|
Confidential Computing platforms (such as AMD SEV) allow the
|
|
|
|
|
Guest Owner to securely inject secrets during guest VM launch.
|
|
|
|
|
The secrets are placed in a designated EFI reserved memory area.
|
|
|
|
|
|
|
|
|
|
In order to use the secrets in the kernel, the location of the secret
|
|
|
|
|
area (as published in the EFI config table) must be kept.
|
|
|
|
|
|
|
|
|
|
If you say Y here, the address of the EFI secret area will be kept
|
|
|
|
|
for usage inside the kernel. This will allow the
|
|
|
|
|
virt/coco/efi_secret module to access the secrets, which in turn
|
|
|
|
|
allows userspace programs to access the injected secrets.
|
2022-05-28 17:49:54 +08:00
|
|
|
|
|
|
|
|
config EFI_EMBEDDED_FIRMWARE
|
|
|
|
|
bool
|
|
|
|
|
select CRYPTO_LIB_SHA256
|
|
|
|
|
|
|
|
|
|
endmenu
|
|
|
|
|
|
|
|
|
|
config UEFI_CPER
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config UEFI_CPER_ARM
|
|
|
|
|
bool
|
|
|
|
|
depends on UEFI_CPER && ( ARM || ARM64 )
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
config UEFI_CPER_X86
|
|
|
|
|
bool
|
|
|
|
|
depends on UEFI_CPER && X86
|
|
|
|
|
default y
|