korg/linux
0
0
Fork 0
mirror of https://mirrors.bfsu.edu.cn/git/linux.git synced 2024-12-01 08:04:22 +08:00
Code Issues Packages Projects Releases Wiki Activity
fb318ca0a5
linux/drivers/firmware/efi/Kconfig

319 lines
11 KiB
Plaintext
Raw Normal View History

treewide: Add SPDX license identifier - Makefile/Kconfig Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-19 20:07:45 +08:00
# SPDX-License-Identifier: GPL-2.0-only
efivars: Move pstore code into the new EFI directory efivars.c has grown far too large and needs to be divided up. Create a new directory and move the persistence storage code to efi-pstore.c now that it uses the new efivar API. This helps us to greatly reduce the size of efivars.c and paves the way for moving other code out of efivars.c. Note that because CONFIG_EFI_VARS can be built as a module efi-pstore must also include support for building as a module. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Anton Vorontsov <cbouatmailru@gmail.com> Cc: Colin Cross <ccross@android.com> Cc: Kees Cook <keescook@chromium.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-08 23:48:51 +08:00
menu "EFI (Extensible Firmware Interface) Support"
depends on EFI
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
arch: Remove Itanium (IA-64) architecture The Itanium architecture is obsolete, and an informal survey [0] reveals that any residual use of Itanium hardware in production is mostly HP-UX or OpenVMS based. The use of Linux on Itanium appears to be limited to enthusiasts that occasionally boot a fresh Linux kernel to see whether things are still working as intended, and perhaps to churn out some distro packages that are rarely used in practice. None of the original companies behind Itanium still produce or support any hardware or software for the architecture, and it is listed as 'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers that contributed on behalf of those companies (nor anyone else, for that matter) have been willing to support or maintain the architecture upstream or even be responsible for applying the odd fix. The Intel firmware team removed all IA-64 support from the Tianocore/EDK2 reference implementation of EFI in 2018. (Itanium is the original architecture for which EFI was developed, and the way Linux supports it deviates significantly from other architectures.) Some distros, such as Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have dropped support years ago. While the argument is being made [1] that there is a 'for the common good' angle to being able to build and run existing projects such as the Grid Community Toolkit [2] on Itanium for interoperability testing, the fact remains that none of those projects are known to be deployed on Linux/ia64, and very few people actually have access to such a system in the first place. Even if there were ways imaginable in which Linux/ia64 could be put to good use today, what matters is whether anyone is actually doing that, and this does not appear to be the case. There are no emulators widely available, and so boot testing Itanium is generally infeasible for ordinary contributors. GCC still supports IA-64 but its compile farm [3] no longer has any IA-64 machines. GLIBC would like to get rid of IA-64 [4] too because it would permit some overdue code cleanups. In summary, the benefits to the ecosystem of having IA-64 be part of it are mostly theoretical, whereas the maintenance overhead of keeping it supported is real. So let's rip off the band aid, and remove the IA-64 arch code entirely. This follows the timeline proposed by the Debian/ia64 maintainer [5], which removes support in a controlled manner, leaving IA-64 in a known good state in the most recent LTS release. Other projects will follow once the kernel support is removed. [0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/ [1] https://lore.kernel.org/all/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/ [2] https://gridcf.org/gct-docs/latest/index.html [3] https://cfarm.tetaneutral.net/machines/list/ [4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/ [5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/ Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-10-20 21:54:33 +08:00
depends on EFI
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
default y
efivars: Move pstore code into the new EFI directory efivars.c has grown far too large and needs to be divided up. Create a new directory and move the persistence storage code to efi-pstore.c now that it uses the new efivar API. This helps us to greatly reduce the size of efivars.c and paves the way for moving other code out of efivars.c. Note that because CONFIG_EFI_VARS can be built as a module efi-pstore must also include support for building as a module. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Anton Vorontsov <cbouatmailru@gmail.com> Cc: Colin Cross <ccross@android.com> Cc: Kees Cook <keescook@chromium.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-08 23:48:51 +08:00
config EFI_VARS_PSTORE
tristate "Register efivars backend for pstore"
efi: pstore: disentangle from deprecated efivars module The EFI pstore implementation relies on the 'efivars' abstraction, which encapsulates the EFI variable store in a way that can be overridden by other backing stores, like the Google SMI one. On top of that, the EFI pstore implementation also relies on the efivars.ko module, which is a separate layer built on top of the 'efivars' abstraction that exposes the [deprecated] sysfs entries for each variable that exists in the backing store. Since the efivars.ko module is deprecated, and all users appear to have moved to the efivarfs file system instead, let's prepare for its removal, by removing EFI pstore's dependency on it. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-09-23 15:56:14 +08:00
depends on PSTORE
efi: pstore: Omit efivars caching EFI varstore access layer Avoid the efivars layer and simply call the newly introduced EFI varstore helpers instead. This simplifies the code substantially, and also allows us to remove some hacks in the shared efivars layer that were added for efi-pstore specifically. In order to be able to delete the EFI variable associated with a record, store the UTF-16 name of the variable in the pstore record's priv field. That way, we don't have to make guesses regarding which variable the record may have been loaded from. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-06-20 19:21:26 +08:00
select UCS2_STRING
efivars: Move pstore code into the new EFI directory efivars.c has grown far too large and needs to be divided up. Create a new directory and move the persistence storage code to efi-pstore.c now that it uses the new efivar API. This helps us to greatly reduce the size of efivars.c and paves the way for moving other code out of efivars.c. Note that because CONFIG_EFI_VARS can be built as a module efi-pstore must also include support for building as a module. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Anton Vorontsov <cbouatmailru@gmail.com> Cc: Colin Cross <ccross@android.com> Cc: Kees Cook <keescook@chromium.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
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.
efi: Common enable/disable infrastructure for EFI soft reservation UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the interpretation of the EFI Memory Types as "reserved for a specific purpose". The proposed Linux behavior for specific purpose memory is that it is reserved for direct-access (device-dax) by default and not available for any kernel usage, not even as an OOM fallback. Later, through udev scripts or another init mechanism, these device-dax claimed ranges can be reconfigured and hot-added to the available System-RAM with a unique node identifier. This device-dax management scheme implements "soft" in the "soft reserved" designation by allowing some or all of the reservation to be recovered as typical memory. This policy can be disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with efi=nosoftreserve. As for this patch, define the common helpers to determine if the EFI_MEMORY_SP attribute should be honored. The determination needs to be made early to prevent the kernel from being loaded into soft-reserved memory, or otherwise allowing early allocations to land there. Follow-on changes are needed per architecture to leverage these helpers in their respective mem-init paths. Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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.
efi: libstub: ensure allocated memory to be executable There are UEFI versions that restrict execution of memory regions, preventing the kernel from booting. Parts that needs to be executable are: * Area used for trampoline placement. * All memory regions that the kernel may be relocated before and during extraction. Use DXE services to ensure aforementioned address ranges to be executable. Only modify attributes that does not have appropriate attributes. Signed-off-by: Baskov Evgeniy <baskov@ispras.ru> Link: https://lore.kernel.org/r/20220303142120.1975-3-baskov@ispras.ru Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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.
efi: add helper function to get UEFI params from FDT ARM and ARM64 architectures use the device tree to pass UEFI parameters from stub to kernel. These parameters are things known to the stub but not discoverable by the kernel after the stub calls ExitBootSerives(). There is a helper function in: drivers/firmware/efi/fdt.c which the stub uses to add the UEFI parameters to the device tree. This patch adds a complimentary helper function which UEFI runtime support may use to retrieve the parameters from the device tree. If an architecture wants to use this helper, it should select CONFIG_EFI_PARAMS_FROM_FDT. Signed-off-by: Mark Salter <msalter@redhat.com> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
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.
efi/x86: Move UEFI Runtime Services wrappers to generic code In order for other archs (such as arm64) to be able to reuse the virtual mode function call wrappers, move them to drivers/firmware/efi/runtime-wrappers.c. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2014-06-26 18:09:05 +08:00
config EFI_RUNTIME_WRAPPERS
bool
efi/libstub: Move arm-stub to a common file Most of the arm-stub code is written in an architecture independent manner. As a result, RISC-V can reuse most of the arm-stub code. Rename the arm-stub.c to efi-stub.c so that ARM, ARM64 and RISC-V can use it. This patch doesn't introduce any functional changes. Signed-off-by: Atish Patra <atish.patra@wdc.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Link: https://lore.kernel.org/r/20200415195422.19866-2-atish.patra@wdc.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-16 03:54:18 +08:00
config EFI_GENERIC_STUB
efi: efistub: Convert into static library This patch changes both x86 and arm64 efistub implementations from #including shared .c files under drivers/firmware/efi to building shared code as a static library. The x86 code uses a stub built into the boot executable which uncompresses the kernel at boot time. In this case, the library is linked into the decompressor. In the arm64 case, the stub is part of the kernel proper so the library is linked into the kernel proper as well. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2014-07-02 20:54:43 +08:00
bool
efi/libstub: implement generic EFI zboot Implement a minimal EFI app that decompresses the real kernel image and launches it using the firmware's LoadImage and StartImage boot services. This removes the need for any arch-specific hacks. Note that on systems that have UEFI secure boot policies enabled, LoadImage/StartImage require images to be signed, or their hashes known a priori, in order to be permitted to boot. There are various possible strategies to work around this requirement, but they all rely either on overriding internal PI/DXE protocols (which are not part of the EFI spec) or omitting the firmware provided LoadImage() and StartImage() boot services, which is also undesirable, given that they encapsulate platform specific policies related to secure boot and measured boot, but also related to memory permissions (whether or not and which types of heap allocations have both write and execute permissions.) The only generic and truly portable way around this is to simply sign both the inner and the outer image with the same key/cert pair, so this is what is implemented here. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-05-02 07:08:16 +08:00
config EFI_ZBOOT
bool "Enable the generic EFI decompressor"
depends on EFI_GENERIC_STUB && !ARM
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZ4
select HAVE_KERNEL_LZMA
select HAVE_KERNEL_LZO
select HAVE_KERNEL_XZ
select HAVE_KERNEL_ZSTD
help
Create the bootable image as an EFI application that carries the
actual kernel image in compressed form, and decompresses it into
memory before executing it via LoadImage/StartImage EFI boot service
calls. For compatibility with non-EFI loaders, the payload can be
decompressed and executed by the loader as well, provided that the
loader implements the decompression algorithm and that non-EFI boot
is supported by the encapsulated image. (The compression algorithm
used is described in the zboot image header)
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"
efi/loongarch: Add efistub booting support This patch adds efistub booting support, which is the standard UEFI boot protocol for LoongArch to use. We use generic efistub, which means we can pass boot information (i.e., system table, memory map, kernel command line, initrd) via a light FDT and drop a lot of non-standard code. We use a flat mapping to map the efi runtime in the kernel's address space. In efi, VA = PA; in kernel, VA = PA + PAGE_OFFSET. As a result, flat mapping is not identity mapping, SetVirtualAddressMap() is still needed for the efi runtime. Tested-by: Xi Ruoyao <xry111@xry111.site> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> [ardb: change fpic to fpie as suggested by Xi Ruoyao] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-08-19 18:20:37 +08:00
depends on EFI_GENERIC_STUB && !RISCV && !LOONGARCH
efi/libstub/arm: default EFI_ARMSTUB_DTB_LOADER to y Default EFI_ARMSTUB_DTB_LOADER to y to allow the dtb= command line parameter to function with efi loader. Required for development purposes and to boot on existing bootloaders that do not support devicetree provided by the firmware or by the bootloader. Fixes: 3d7ee348aa41 ("efi/libstub/arm: Add opt-in Kconfig option ...") Signed-off-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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.
efi/libstub/arm: default EFI_ARMSTUB_DTB_LOADER to y Default EFI_ARMSTUB_DTB_LOADER to y to allow the dtb= command line parameter to function with efi loader. Required for development purposes and to boot on existing bootloaders that do not support devicetree provided by the firmware or by the bootloader. Fixes: 3d7ee348aa41 ("efi/libstub/arm: Add opt-in Kconfig option ...") Signed-off-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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
efibc: Add EFI Bootloader Control module This module installs a reboot callback, 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", "shutdown". The bootloader reads this reboot reason and takes particular action according to its policy. There are reboot implementations that do "reboot <reason>", such as Android's reboot command and Upstart's reboot replacement, which pass the reason as an argument to the reboot syscall. There is no platform-agnostic way how those could be modified to pass the reason to the bootloader, regardless of platform or bootloader. Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stefan Stanacar <stefan.stanacar@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1461614832-17633-26-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-26 04:06:57 +08:00
config EFI_BOOTLOADER_CONTROL
tristate "EFI Bootloader Control"
efi: efibc: avoid efivar API for setting variables Avoid abusing the efivar API by passing locally instantiated efivar_entry structs into efivar_set_entry_safe(), rather than using the API as intended. Instead, just call efi.set_variable() directly. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-06-20 17:35:37 +08:00
select UCS2_STRING
efibc: Add EFI Bootloader Control module This module installs a reboot callback, 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", "shutdown". The bootloader reads this reboot reason and takes particular action according to its policy. There are reboot implementations that do "reboot <reason>", such as Android's reboot command and Upstart's reboot replacement, which pass the reason as an argument to the reboot syscall. There is no platform-agnostic way how those could be modified to pass the reason to the bootloader, regardless of platform or bootloader. Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stefan Stanacar <stefan.stanacar@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1461614832-17633-26-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-26 04:06:57 +08:00
default n
treewide: replace '---help---' in Kconfig files with 'help' Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-14 00:50:22 +08:00
help
efibc: Add EFI Bootloader Control module This module installs a reboot callback, 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", "shutdown". The bootloader reads this reboot reason and takes particular action according to its policy. There are reboot implementations that do "reboot <reason>", such as Android's reboot command and Upstart's reboot replacement, which pass the reason as an argument to the reboot syscall. There is no platform-agnostic way how those could be modified to pass the reason to the bootloader, regardless of platform or bootloader. Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stefan Stanacar <stefan.stanacar@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1461614832-17633-26-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
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.
efi: Add misc char driver interface to update EFI firmware This patch introduces a kernel module to expose a capsule loader interface (misc char device file note) for users to upload capsule binaries. Example: cat firmware.bin > /dev/efi_capsule_loader Any upload error will be returned while doing "cat" through file operation write() function call. Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com> [ Update comments and Kconfig text ] Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Reviewed-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sam Protsenko <semen.protsenko@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: joeyli <jlee@suse.com> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1461614832-17633-30-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-26 04:07:01 +08:00
config EFI_CAPSULE_LOADER
tristate "EFI capsule loader"
arch: Remove Itanium (IA-64) architecture The Itanium architecture is obsolete, and an informal survey [0] reveals that any residual use of Itanium hardware in production is mostly HP-UX or OpenVMS based. The use of Linux on Itanium appears to be limited to enthusiasts that occasionally boot a fresh Linux kernel to see whether things are still working as intended, and perhaps to churn out some distro packages that are rarely used in practice. None of the original companies behind Itanium still produce or support any hardware or software for the architecture, and it is listed as 'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers that contributed on behalf of those companies (nor anyone else, for that matter) have been willing to support or maintain the architecture upstream or even be responsible for applying the odd fix. The Intel firmware team removed all IA-64 support from the Tianocore/EDK2 reference implementation of EFI in 2018. (Itanium is the original architecture for which EFI was developed, and the way Linux supports it deviates significantly from other architectures.) Some distros, such as Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have dropped support years ago. While the argument is being made [1] that there is a 'for the common good' angle to being able to build and run existing projects such as the Grid Community Toolkit [2] on Itanium for interoperability testing, the fact remains that none of those projects are known to be deployed on Linux/ia64, and very few people actually have access to such a system in the first place. Even if there were ways imaginable in which Linux/ia64 could be put to good use today, what matters is whether anyone is actually doing that, and this does not appear to be the case. There are no emulators widely available, and so boot testing Itanium is generally infeasible for ordinary contributors. GCC still supports IA-64 but its compile farm [3] no longer has any IA-64 machines. GLIBC would like to get rid of IA-64 [4] too because it would permit some overdue code cleanups. In summary, the benefits to the ecosystem of having IA-64 be part of it are mostly theoretical, whereas the maintenance overhead of keeping it supported is real. So let's rip off the band aid, and remove the IA-64 arch code entirely. This follows the timeline proposed by the Debian/ia64 maintainer [5], which removes support in a controlled manner, leaving IA-64 in a known good state in the most recent LTS release. Other projects will follow once the kernel support is removed. [0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/ [1] https://lore.kernel.org/all/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/ [2] https://gridcf.org/gct-docs/latest/index.html [3] https://cfarm.tetaneutral.net/machines/list/ [4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/ [5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/ Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-10-20 21:54:33 +08:00
depends on EFI
efi: Add misc char driver interface to update EFI firmware This patch introduces a kernel module to expose a capsule loader interface (misc char device file note) for users to upload capsule binaries. Example: cat firmware.bin > /dev/efi_capsule_loader Any upload error will be returned while doing "cat" through file operation write() function call. Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com> [ Update comments and Kconfig text ] Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Reviewed-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sam Protsenko <semen.protsenko@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: joeyli <jlee@suse.com> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1461614832-17633-30-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
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.
efi/capsule: Add support for Quark security header The firmware for Quark X102x prepends a security header to the capsule which is needed to support the mandatory secure boot on this processor. The header can be detected by checking for the "_CSH" signature and - to avoid any GUID conflict - validating its size field to contain the expected value. Then we need to look for the EFI header right after the security header and pass the real header to __efi_capsule_setup_info. To be minimal invasive and maximal safe, the quirk version of efi_capsule_setup_info() is only effective on Quark processors. Tested-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-11-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-02 21:52:04 +08:00
config EFI_CAPSULE_QUIRK_QUARK_CSH
kconfig: use bool instead of boolean for type definition attributes, again Commit 6341e62b212a ("kconfig: use bool instead of boolean for type definition attributes") did treewide replacement of 'boolean', and also mentioned the keyword 'boolean' would be dropped later on. Some years have passed, but it has not happened yet. Meanwhile, some new instances have come up. I am really going to drop this keyword. I need to do the replacement once again. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-15 23:38:01 +08:00
bool "Add support for Quark capsules with non-standard headers"
efi/capsule: Add support for Quark security header The firmware for Quark X102x prepends a security header to the capsule which is needed to support the mandatory secure boot on this processor. The header can be detected by checking for the "_CSH" signature and - to avoid any GUID conflict - validating its size field to contain the expected value. Then we need to look for the EFI header right after the security header and pass the real header to __efi_capsule_setup_info. To be minimal invasive and maximal safe, the quirk version of efi_capsule_setup_info() is only effective on Quark processors. Tested-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-11-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
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.
efi: Add efi_test driver for exporting UEFI runtime service interfaces This driver is used by the Firmware Test Suite (FWTS) for testing the UEFI runtime interfaces readiness of the firmware. This driver exports UEFI runtime service interfaces into userspace, which allows to use and test UEFI runtime services provided by the firmware. This driver uses the efi.<service> function pointers directly instead of going through the efivar API to allow for direct testing of the UEFI runtime service interfaces provided by the firmware. Details for FWTS are available from, <https://wiki.ubuntu.com/FirmwareTestSuite> Signed-off-by: Ivan Hu <ivan.hu@canonical.com> Cc: joeyli <jlee@suse.com> Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
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.
efi: clean up Kconfig dependencies on CONFIG_EFI Geert reports that the new option CONFIG_EFI_DISABLE_RUNTIME is user visible even when EFI support is disabled, which is unnecessary and clutters the Kconfig interface. So let's move this option into the existing Kconfig submenu that already depends on CONFIG_EFI, and while at it, give some other options the same treatment. Also clean up a small wart where the efi/ subdirectory is listed twice. Let's just list it unconditionally so that both EFI and UEFI_CPER based pieces will be built independently (the latter only depends on the former on !X86) Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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.
efi/libstub: Enable reset attack mitigation If a machine is reset while secrets are present in RAM, it may be possible for code executed after the reboot to extract those secrets from untouched memory. The Trusted Computing Group specified a mechanism for requesting that the firmware clear all RAM on reset before booting another OS. This is done by setting the MemoryOverwriteRequestControl variable at startup. If userspace can ensure that all secrets are removed as part of a controlled shutdown, it can reset this variable to 0 before triggering a hardware reboot. Signed-off-by: Matthew Garrett <mjg59@google.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170825155019.6740-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
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
x86/efi: Clarify that reset attack mitigation needs appropriate userspace Some distributions have turned on the reset attack mitigation feature, which is designed to force the platform to clear the contents of RAM if the machine is shut down uncleanly. However, in order for the platform to be able to determine whether the shutdown was clean or not, userspace has to be configured to clear the MemoryOverwriteRequest flag on shutdown - otherwise the firmware will end up clearing RAM on every reboot, which is unnecessarily time consuming. Add some additional clarity to the kconfig text to reduce the risk of systems being configured this way. Signed-off-by: Matthew Garrett <mjg59@google.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@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 Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
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.
efi/libstub: Enable reset attack mitigation If a machine is reset while secrets are present in RAM, it may be possible for code executed after the reboot to extract those secrets from untouched memory. The Trusted Computing Group specified a mechanism for requesting that the firmware clear all RAM on reset before booting another OS. This is done by setting the MemoryOverwriteRequestControl variable at startup. If userspace can ensure that all secrets are removed as part of a controlled shutdown, it can reset this variable to 0 before triggering a hardware reboot. Signed-off-by: Matthew Garrett <mjg59@google.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170825155019.6740-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-08-25 23:50:15 +08:00
efi: Export Runtime Configuration Interface table to sysfs System firmware advertises the address of the 'Runtime Configuration Interface table version 2 (RCI2)' via an EFI Configuration Table entry. This code retrieves the RCI2 table from the address and exports it to sysfs as a binary attribute 'rci2' under /sys/firmware/efi/tables directory. The approach adopted is similar to the attribute 'DMI' under /sys/firmware/dmi/tables. 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. Signed-off-by: Narendra K <Narendra.K@dell.com> Reviewed-by: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-07-11 02:59:15 +08:00
config EFI_RCI2_TABLE
bool "EFI Runtime Configuration Interface Table Version 2 Support"
efi: Make CONFIG_EFI_RCI2_TABLE selectable on x86 only For the EFI_RCI2_TABLE Kconfig option, 'make oldconfig' asks the user for input on platforms where the option may not be applicable. This patch modifies the Kconfig option to ask the user for input only when CONFIG_X86 or CONFIG_COMPILE_TEST is set to y. Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Narendra K <Narendra.K@dell.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@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: https://lkml.kernel.org/r/20191029173755.27149-2-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-10-30 01:37:50 +08:00
depends on X86 || COMPILE_TEST
efi: Export Runtime Configuration Interface table to sysfs System firmware advertises the address of the 'Runtime Configuration Interface table version 2 (RCI2)' via an EFI Configuration Table entry. This code retrieves the RCI2 table from the address and exports it to sysfs as a binary attribute 'rci2' under /sys/firmware/efi/tables directory. The approach adopted is similar to the attribute 'DMI' under /sys/firmware/dmi/tables. 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. Signed-off-by: Narendra K <Narendra.K@dell.com> Reviewed-by: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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.
efi: Allow disabling PCI busmastering on bridges during boot Add an option to disable the busmaster bit in the control register on all PCI bridges before 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 CONFIG_EFI_DISABLE_PCI_DMA is enabled or "efi=disable_early_pci_dma" is passed on the command line, 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 may 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 the default. Note that PCI devices downstream from PCI bridges are disconnected from their drivers first, using the UEFI driver model API, so that DMA can be disabled safely at the bridge level. [ardb: disconnect PCI I/O handles first, as suggested by Arvind] Co-developed-by: Matthew Garrett <mjg59@google.com> Signed-off-by: Matthew Garrett <mjg59@google.com> 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 <matthewgarrett@google.com> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20200103113953.9571-18-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
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.
efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation Move the x86 EFI earlyprintk implementation to a shared location under drivers/firmware and tweak it slightly so we can expose it as an earlycon implementation (which is generic) rather than earlyprintk (which is only implemented for a few architectures) This also involves switching to write-combine mappings by default (which is required on ARM since device mappings lack memory semantics, and so memcpy/memset may not be used on them), and adding support for shared memory framebuffers on cache coherent non-x86 systems (which do not tolerate mismatched attributes). Note that 32-bit ARM does not populate its struct screen_info early enough for earlycon=efifb to work, so it is disabled there. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Alexander Graf <agraf@suse.de> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20190202094119.13230-10-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-02-02 17:41:18 +08:00
config EFI_EARLYCON
def_bool y
arch: Remove Itanium (IA-64) architecture The Itanium architecture is obsolete, and an informal survey [0] reveals that any residual use of Itanium hardware in production is mostly HP-UX or OpenVMS based. The use of Linux on Itanium appears to be limited to enthusiasts that occasionally boot a fresh Linux kernel to see whether things are still working as intended, and perhaps to churn out some distro packages that are rarely used in practice. None of the original companies behind Itanium still produce or support any hardware or software for the architecture, and it is listed as 'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers that contributed on behalf of those companies (nor anyone else, for that matter) have been willing to support or maintain the architecture upstream or even be responsible for applying the odd fix. The Intel firmware team removed all IA-64 support from the Tianocore/EDK2 reference implementation of EFI in 2018. (Itanium is the original architecture for which EFI was developed, and the way Linux supports it deviates significantly from other architectures.) Some distros, such as Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have dropped support years ago. While the argument is being made [1] that there is a 'for the common good' angle to being able to build and run existing projects such as the Grid Community Toolkit [2] on Itanium for interoperability testing, the fact remains that none of those projects are known to be deployed on Linux/ia64, and very few people actually have access to such a system in the first place. Even if there were ways imaginable in which Linux/ia64 could be put to good use today, what matters is whether anyone is actually doing that, and this does not appear to be the case. There are no emulators widely available, and so boot testing Itanium is generally infeasible for ordinary contributors. GCC still supports IA-64 but its compile farm [3] no longer has any IA-64 machines. GLIBC would like to get rid of IA-64 [4] too because it would permit some overdue code cleanups. In summary, the benefits to the ecosystem of having IA-64 be part of it are mostly theoretical, whereas the maintenance overhead of keeping it supported is real. So let's rip off the band aid, and remove the IA-64 arch code entirely. This follows the timeline proposed by the Debian/ia64 maintainer [5], which removes support in a controlled manner, leaving IA-64 in a known good state in the most recent LTS release. Other projects will follow once the kernel support is removed. [0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/ [1] https://lore.kernel.org/all/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/ [2] https://gridcf.org/gct-docs/latest/index.html [3] https://cfarm.tetaneutral.net/machines/list/ [4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/ [5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/ Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-10-20 21:54:33 +08:00
depends on SERIAL_EARLYCON && !ARM
efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation Move the x86 EFI earlyprintk implementation to a shared location under drivers/firmware and tweak it slightly so we can expose it as an earlycon implementation (which is generic) rather than earlyprintk (which is only implemented for a few architectures) This also involves switching to write-combine mappings by default (which is required on ARM since device mappings lack memory semantics, and so memcpy/memset may not be used on them), and adding support for shared memory framebuffers on cache coherent non-x86 systems (which do not tolerate mismatched attributes). Note that 32-bit ARM does not populate its struct screen_info early enough for earlycon=efifb to work, so it is disabled there. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Alexander Graf <agraf@suse.de> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20190202094119.13230-10-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-02-02 17:41:18 +08:00
select FONT_SUPPORT
select ARCH_USE_MEMREMAP_PROT
efi: Make it possible to disable efivar_ssdt entirely In most cases, such as CONFIG_ACPI_CUSTOM_DSDT and CONFIG_ACPI_TABLE_UPGRADE, boot-time modifications to firmware tables are tied to specific Kconfig options. Currently this is not the case for modifying the ACPI SSDT via the efivar_ssdt kernel command line option and associated EFI variable. This patch adds CONFIG_EFI_CUSTOM_SSDT_OVERLAYS, which defaults disabled, in order to allow enabling or disabling that feature during the build. Cc: <stable@vger.kernel.org> Signed-off-by: Peter Jones <pjones@redhat.com> Link: https://lore.kernel.org/r/20200615202408.2242614-1-pjones@redhat.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-06-16 04:24:08 +08:00
config EFI_CUSTOM_SSDT_OVERLAYS
bool "Load custom ACPI SSDT overlay from an EFI variable"
efi: clean up Kconfig dependencies on CONFIG_EFI Geert reports that the new option CONFIG_EFI_DISABLE_RUNTIME is user visible even when EFI support is disabled, which is unnecessary and clutters the Kconfig interface. So let's move this option into the existing Kconfig submenu that already depends on CONFIG_EFI, and while at it, give some other options the same treatment. Also clean up a small wart where the efi/ subdirectory is listed twice. Let's just list it unconditionally so that both EFI and UEFI_CPER based pieces will be built independently (the latter only depends on the former on !X86) Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-05-28 17:49:54 +08:00
depends on ACPI
efi: Make it possible to disable efivar_ssdt entirely In most cases, such as CONFIG_ACPI_CUSTOM_DSDT and CONFIG_ACPI_TABLE_UPGRADE, boot-time modifications to firmware tables are tied to specific Kconfig options. Currently this is not the case for modifying the ACPI SSDT via the efivar_ssdt kernel command line option and associated EFI variable. This patch adds CONFIG_EFI_CUSTOM_SSDT_OVERLAYS, which defaults disabled, in order to allow enabling or disabling that feature during the build. Cc: <stable@vger.kernel.org> Signed-off-by: Peter Jones <pjones@redhat.com> Link: https://lore.kernel.org/r/20200615202408.2242614-1-pjones@redhat.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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.
efi: Allow to enable EFI runtime services by default on RT Commit d9f283ae71af ("efi: Disable runtime services on RT") disabled EFI runtime services by default when the CONFIG_PREEMPT_RT option is enabled. The rationale for that commit is that some EFI calls could take too much time, leading to large latencies which is an issue for Real-Time kernels. But a side effect of that change was that now is not possible anymore to enable the EFI runtime services by default when CONFIG_PREEMPT_RT is set, without passing an efi=runtime command line parameter to the kernel. Instead, let's add a new EFI_DISABLE_RUNTIME boolean Kconfig option, that would be set to n by default but to y if CONFIG_PREEMPT_RT is enabled. That way, the current behaviour is preserved but gives users a mechanism to enable the EFI runtimes services in their kernels if that is required. For example, if the firmware could guarantee bounded time for EFI calls. Also, having a separate boolean config could allow users to disable the EFI runtime services by default even when CONFIG_PREEMPT_RT is not set. Reported-by: Alexander Larsson <alexl@redhat.com> Fixes: d9f283ae71af ("efi: Disable runtime services on RT") Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20220331151654.184433-1-javierm@redhat.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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.
efi: Save location of EFI confidential computing area Confidential computing (coco) hardware such as AMD SEV (Secure Encrypted Virtualization) allows a guest owner to inject secrets into the VMs memory without the host/hypervisor being able to read them. Firmware support for secret injection is available in OVMF, which reserves a memory area for secret injection and includes a pointer to it the in EFI config table entry LINUX_EFI_COCO_SECRET_TABLE_GUID. If EFI exposes such a table entry, uefi_init() will keep a pointer to the EFI config table entry in efi.coco_secret, so it can be used later by the kernel (specifically drivers/virt/coco/efi_secret). It will also appear in the kernel log as "CocoSecret=ADDRESS"; for example: [ 0.000000] efi: EFI v2.70 by EDK II [ 0.000000] efi: CocoSecret=0x7f22e680 SMBIOS=0x7f541000 ACPI=0x7f77e000 ACPI 2.0=0x7f77e014 MEMATTR=0x7ea0c018 The new functionality can be enabled with CONFIG_EFI_COCO_SECRET=y. Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://lore.kernel.org/r/20220412212127.154182-2-dovmurik@linux.ibm.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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.
efi: clean up Kconfig dependencies on CONFIG_EFI Geert reports that the new option CONFIG_EFI_DISABLE_RUNTIME is user visible even when EFI support is disabled, which is unnecessary and clutters the Kconfig interface. So let's move this option into the existing Kconfig submenu that already depends on CONFIG_EFI, and while at it, give some other options the same treatment. Also clean up a small wart where the efi/ subdirectory is listed twice. Let's just list it unconditionally so that both EFI and UEFI_CPER based pieces will be built independently (the latter only depends on the former on !X86) Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-05-28 17:49:54 +08:00
efi/libstub: Implement support for unaccepted memory UEFI Specification version 2.9 introduces the concept of memory acceptance: Some Virtual Machine platforms, such as Intel TDX or AMD SEV-SNP, requiring memory to be accepted before it can be used by the guest. Accepting happens via a protocol specific for the Virtual Machine platform. Accepting memory is costly and it makes VMM allocate memory for the accepted guest physical address range. It's better to postpone memory acceptance until memory is needed. It lowers boot time and reduces memory overhead. The kernel needs to know what memory has been accepted. Firmware communicates this information via memory map: a new memory type -- EFI_UNACCEPTED_MEMORY -- indicates such memory. Range-based tracking works fine for firmware, but it gets bulky for the kernel: e820 (or whatever the arch uses) has to be modified on every page acceptance. It leads to table fragmentation and there's a limited number of entries in the e820 table. Another option is to mark such memory as usable in e820 and track if the range has been accepted in a bitmap. One bit in the bitmap represents a naturally aligned power-2-sized region of address space -- unit. For x86, unit size is 2MiB: 4k of the bitmap is enough to track 64GiB or physical address space. In the worst-case scenario -- a huge hole in the middle of the address space -- It needs 256MiB to handle 4PiB of the address space. Any unaccepted memory that is not aligned to unit_size gets accepted upfront. The bitmap is allocated and constructed in the EFI stub and passed down to the kernel via EFI configuration table. allocate_e820() allocates the bitmap if unaccepted memory is present, according to the size of unaccepted region. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20230606142637.5171-4-kirill.shutemov@linux.intel.com
2023-06-06 22:26:31 +08:00
config UNACCEPTED_MEMORY
bool
depends on EFI_STUB
help
Some Virtual Machine platforms, such as Intel TDX, require
some memory to be "accepted" by the guest before it can be used.
This mechanism helps prevent malicious hosts from making changes
to guest memory.
UEFI specification v2.9 introduced EFI_UNACCEPTED_MEMORY memory type.
This option adds support for unaccepted memory and makes such memory
usable by the kernel.
efi: clean up Kconfig dependencies on CONFIG_EFI Geert reports that the new option CONFIG_EFI_DISABLE_RUNTIME is user visible even when EFI support is disabled, which is unnecessary and clutters the Kconfig interface. So let's move this option into the existing Kconfig submenu that already depends on CONFIG_EFI, and while at it, give some other options the same treatment. Also clean up a small wart where the efi/ subdirectory is listed twice. Let's just list it unconditionally so that both EFI and UEFI_CPER based pieces will be built independently (the latter only depends on the former on !X86) Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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
efi: Add tee-based EFI variable driver When the flash is not owned by the non-secure world, accessing the EFI variables is straight-forward and done via EFI Runtime Variable Services. In this case, critical variables for system integrity and security are normally stored in the dedicated secure storage and can only be manipulated directly from the secure world. Usually, small embedded devices don't have the special dedicated secure storage. The eMMC device with an RPMB partition is becoming more common, and we can use this RPMB partition to store the EFI Variables. The eMMC device is typically owned by the non-secure world (Linux in our case). There is an existing solution utilizing eMMC RPMB partition for EFI Variables, it is implemented by interacting with TEE (OP-TEE in this case), StandaloneMM (as EFI Variable Service Pseudo TA), eMMC driver and tee-supplicant. The last piece is the tee-based variable access driver to interact with TEE and StandaloneMM. So let's add the kernel functions needed. This feature is implemented as a kernel module. StMM PTA has TA_FLAG_DEVICE_ENUM_SUPP flag when registered to OP-TEE so that this tee_stmm_efi module is probed after tee-supplicant starts, since "SetVariable" EFI Runtime Variable Service requires to interact with tee-supplicant. Acked-by: Sumit Garg <sumit.garg@linaro.org> Co-developed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2023-11-07 13:40:54 +08:00
config TEE_STMM_EFI
tristate "TEE-based EFI runtime variable service driver"
depends on EFI && OPTEE
help
Select this config option if TEE is compiled to include StandAloneMM
as a separate secure partition. It has the ability to check and store
EFI variables on an RPMB or any other non-volatile medium used by
StandAloneMM.
Enabling this will change the EFI runtime services from the firmware
provided functions to TEE calls.
To compile this driver as a module, choose M here: the module
will be called tee_stmm_efi.
Reference in New Issue Copy Permalink