Changes in Kconfig

0b2c29fb - efi/zboot: Limit compression options to GZIP and ZSTD

Fri, 06 Dec 2024 10:41:40 +0000

efi/zboot: Limit compression options to GZIP and ZSTDFor historical reasons, the legacy decompressor code on variousarchitectures supports 7 different compression types for the compressedkernel image.EFI zboot is not a compression library museum, and so the options can belimited to what is likely to be useful in practice:- GZIP is tried and tested, and is still one of the fastest at decompression time, although the compression ratio is not very high; moreover, Fedora is already shipping EFI zboot kernels for arm64 that use GZIP, and QEMU implements direct support for it when booting a kernel without firmware loaded;- ZSTD has a very high compression ratio (although not the highest), and is almost as fast as GZIP at decompression time.Reducing the number of options makes it less of a hassle for otherconsumers of the EFI zboot format (such as QEMU today, and kexec in thefuture) to support it transparently without having to carry 7 differentdecompression libraries.Acked-by: Gerd Hoffmann Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

6fce6e97 - efi/zboot: Fix outdated comment about using LoadImage/StartImage

Sun, 13 Oct 2024 11:09:09 +0000

efi/zboot: Fix outdated comment about using LoadImage/StartImageEFI zboot no longer uses LoadImage/StartImage, but subsumes the archcode to load and start the bare metal image directly. Fix the Kconfigdescription accordingly.Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

c44b6be6 - efi: Add tee-based EFI variable driver

Tue, 07 Nov 2023 05:40:54 +0000

efi: Add tee-based EFI variable driverWhen the flash is not owned by the non-secure world, accessing the EFIvariables is straight-forward and done via EFI Runtime VariableServices. In this case, critical variables for system integrity andsecurity are normally stored in the dedicated secure storage and canonly be manipulated directly from the secure world.Usually, small embedded devices don't have the special dedicated securestorage. 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 ourcase). There is an existing solution utilizing eMMC RPMB partition forEFI Variables, it is implemented by interacting with TEE (OP-TEE in thiscase), StandaloneMM (as EFI Variable Service Pseudo TA), eMMC driver andtee-supplicant. The last piece is the tee-based variable access driverto interact with TEE and StandaloneMM.So let's add the kernel functions needed.This feature is implemented as a kernel module. StMM PTA hasTA_FLAG_DEVICE_ENUM_SUPP flag when registered to OP-TEE so that thistee_stmm_efi module is probed after tee-supplicant starts, since"SetVariable" EFI Runtime Variable Service requires to interact withtee-supplicant.Acked-by: Sumit Garg Co-developed-by: Ilias Apalodimas Signed-off-by: Ilias Apalodimas Signed-off-by: Masahisa Kojima Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

cf8e8658 - arch: Remove Itanium (IA-64) architecture

Thu, 20 Oct 2022 13:54:33 +0000

arch: Remove Itanium (IA-64) architectureThe Itanium architecture is obsolete, and an informal survey [0] revealsthat any residual use of Itanium hardware in production is mostly HP-UXor OpenVMS based. The use of Linux on Itanium appears to be limited toenthusiasts that occasionally boot a fresh Linux kernel to see whetherthings are still working as intended, and perhaps to churn out somedistro packages that are rarely used in practice.None of the original companies behind Itanium still produce or supportany hardware or software for the architecture, and it is listed as'Orphaned' in the MAINTAINERS file, as apparently, none of the engineersthat contributed on behalf of those companies (nor anyone else, for thatmatter) have been willing to support or maintain the architectureupstream or even be responsible for applying the odd fix. The Intelfirmware team removed all IA-64 support from the Tianocore/EDK2reference implementation of EFI in 2018. (Itanium is the originalarchitecture for which EFI was developed, and the way Linux supports itdeviates significantly from other architectures.) Some distros, such asDebian and Gentoo, still maintain [unofficial] ia64 ports, but many havedropped support years ago.While the argument is being made [1] that there is a 'for the commongood' angle to being able to build and run existing projects such as theGrid Community Toolkit [2] on Itanium for interoperability testing, thefact remains that none of those projects are known to be deployed onLinux/ia64, and very few people actually have access to such a system inthe first place. Even if there were ways imaginable in which Linux/ia64could be put to good use today, what matters is whether anyone isactually doing that, and this does not appear to be the case.There are no emulators widely available, and so boot testing Itanium isgenerally infeasible for ordinary contributors. GCC still supports IA-64but its compile farm [3] no longer has any IA-64 machines. GLIBC wouldlike to get rid of IA-64 [4] too because it would permit some overduecode cleanups. In summary, the benefits to the ecosystem of having IA-64be part of it are mostly theoretical, whereas the maintenance overheadof 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 knowngood state in the most recent LTS release. Other projects will followonce 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 Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

745e3ed8 - efi/libstub: Implement support for unaccepted memory

Tue, 06 Jun 2023 14:26:31 +0000

efi/libstub: Implement support for unaccepted memoryUEFI Specification version 2.9 introduces the concept of memoryacceptance: Some Virtual Machine platforms, such as Intel TDX or AMDSEV-SNP, requiring memory to be accepted before it can be used by theguest. Accepting happens via a protocol specific for the VirtualMachine platform.Accepting memory is costly and it makes VMM allocate memory for theaccepted guest physical address range. It's better to postpone memoryacceptance until memory is needed. It lowers boot time and reducesmemory overhead.The kernel needs to know what memory has been accepted. Firmwarecommunicates 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 forthe kernel: e820 (or whatever the arch uses) has to be modified on everypage acceptance. It leads to table fragmentation and there's a limitednumber of entries in the e820 table.Another option is to mark such memory as usable in e820 and track if therange has been accepted in a bitmap. One bit in the bitmap represents anaturally aligned power-2-sized region of address space -- unit.For x86, unit size is 2MiB: 4k of the bitmap is enough to track 64GiB orphysical address space.In the worst-case scenario -- a huge hole in the middle of theaddress space -- It needs 256MiB to handle 4PiB of the addressspace.Any unaccepted memory that is not aligned to unit_size gets acceptedupfront.The bitmap is allocated and constructed in the EFI stub and passed downto the kernel via EFI configuration table. allocate_e820() allocates thebitmap if unaccepted memory is present, according to the size ofunaccepted region.Signed-off-by: Kirill A. Shutemov Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20230606142637.5171-4-kirill.shutemov@linux.intel.com List of files: /linux-6.15/drivers/firmware/efi/Kconfig

e346bebb - efi: libstub: Always enable initrd command line loader and bump version

Tue, 29 Nov 2022 17:23:08 +0000

efi: libstub: Always enable initrd command line loader and bump versionIn preparation for setting a cross-architecture baseline for EFI bootsupport, remove the Kconfig option that permits the command line initrdloader to be disabled. Also, bump the minor version so that any imagebuilt with the new version can be identified as supporting this.Acked-by: Leif Lindholm Reviewed-by: Daniel Kiper Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

1fff234d - efi: x86: Move EFI runtime map sysfs code to arch/x86

Mon, 07 Nov 2022 08:17:16 +0000

efi: x86: Move EFI runtime map sysfs code to arch/x86The EFI runtime map code is only wired up on x86, which is the onlyarchitecture that has a need for it in its implementation of kexec.So let's move this code under arch/x86 and drop all references to itfrom generic code. To ensure that the efi_runtime_map_init() is invokedat the appropriate time use a 'sync' subsys_initcall() that will becalled right after the EFI initcall made from generic code where theoriginal invocation of efi_runtime_map_init() resided.Signed-off-by: Ard Biesheuvel Reviewed-by: Dave Young List of files: /linux-6.15/drivers/firmware/efi/Kconfig

8dfac4d8 - efi: runtime-maps: Clarify purpose and enable by default for kexec

Mon, 07 Nov 2022 07:42:08 +0000

efi: runtime-maps: Clarify purpose and enable by default for kexecThe current Kconfig logic for CONFIG_EFI_RUNTIME_MAPS does not conveythat without it, a kexec kernel is not able to boot in EFI mode at all.So clarify this, and make the option only configurable via the menusystem if CONFIG_EXPERT is set.Signed-off-by: Ard Biesheuvel Reviewed-by: Dave Young List of files: /linux-6.15/drivers/firmware/efi/Kconfig

4059ba65 - efi: memmap: Move EFI fake memmap support into x86 arch tree

Sat, 01 Oct 2022 16:38:15 +0000

efi: memmap: Move EFI fake memmap support into x86 arch treeThe EFI fake memmap support is specific to x86, which manipulates theEFI memory map in various different ways after receiving it from the EFIstub. On other architectures, we have managed to push back on this, andthe EFI memory map is kept pristine.So let's move the fake memmap code into the x86 arch tree, where itarguably belongs.Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

75e1a246 - efi: libstub: Undeprecate the command line initrd loader

Mon, 26 Sep 2022 21:23:04 +0000

efi: libstub: Undeprecate the command line initrd loaderThe initrd= command line loader can be useful for development, but itwas limited to loading files from the same file system as the loadedkernel (and it didn't work on x86 mixed mode).As both issues have been fixed, and the initrd= can now be used withfiles residing on any simple file system exposed by the EFI firmware,let's permit it to be enabled on RISC-V and LoongArch, which did notsupport it up to this point.Note that LoadFile2 remains the preferred option, as it is much simplerto use and implement, but generic loaders (including the UEFI shell) maynot implement this so there, initrd= can now be used as well (if enabledin the build)Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

f57fb375 - efi: libstub: Remove zboot signing from build options

Mon, 17 Oct 2022 10:48:46 +0000

efi: libstub: Remove zboot signing from build optionsThe zboot decompressor series introduced a feature to sign the PE/COFFkernel image for secure boot as part of the kernel build. This wasnecessary because there are actually two images that need to be signed:the kernel with the EFI stub attached, and the decompressor application.This is a bit of a burden, because it means that the images must besigned on the the same system that performs the build, and this is notrealistic for distros.During the next cycle, we will introduce changes to the zboot code sothat the inner image no longer needs to be signed. This means that theouter PE/COFF image can be handled as usual, and be signed later in therelease process.Let's remove the associated Kconfig options now so that they don't endup in a LTS release while already being deprecated.Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

a0509109 - efi/libstub: implement generic EFI zboot

Sun, 01 May 2022 23:08:16 +0000

efi/libstub: implement generic EFI zbootImplement a minimal EFI app that decompresses the real kernel image andlaunches 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 knowna 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 (whichare not part of the EFI spec) or omitting the firmware providedLoadImage() and StartImage() boot services, which is also undesirable,given that they encapsulate platform specific policies related to secureboot and measured boot, but also related to memory permissions (whetheror not and which types of heap allocations have both write and executepermissions.)The only generic and truly portable way around this is to simply signboth the inner and the outer image with the same key/cert pair, so thisis what is implemented here.Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

ead384d9 - efi/loongarch: Add efistub booting support

Fri, 19 Aug 2022 10:20:37 +0000

efi/loongarch: Add efistub booting supportThis patch adds efistub booting support, which is the standard UEFI bootprotocol 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 FDTand drop a lot of non-standard code.We use a flat mapping to map the efi runtime in the kernel's addressspace. In efi, VA = PA; in kernel, VA = PA + PAGE_OFFSET. As a result,flat mapping is not identity mapping, SetVirtualAddressMap() is stillneeded for the efi runtime.Tested-by: Xi Ruoyao Signed-off-by: Huacai Chen [ardb: change fpic to fpie as suggested by Xi Ruoyao]Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

0f5b2c69 - efi: vars: Remove deprecated 'efivars' sysfs interface

Mon, 20 Jun 2022 11:34:03 +0000

efi: vars: Remove deprecated 'efivars' sysfs interfaceCommit 5d9db883761a ("efi: Add support for a UEFI variable filesystem")dated Oct 5, 2012, introduced a new efivarfs pseudo-filesystem toreplace the efivars sysfs interface that was used up to that point toexpose EFI variables to user space.The main problem with the sysfs interface was that it only supported upto 1024 bytes of payload per file, whereas the underlying variablesthemselves are only bounded by a platform specific per-variable andglobal limit that is typically much higher than 1024 bytes.The deprecated sysfs interface is only enabled on x86 and Itanium, otherEFI enabled architectures only support the efivarfs pseudo-filesystem.So let's finally rip off the band aid, and drop the old interfaceentirely. This will make it easier to refactor and clean up theunderlying infrastructure that is shared between efivars, efivarfs andefi-pstore, and is long overdue for a makeover.Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

85974825 - efi: pstore: Omit efivars caching EFI varstore access layer

Mon, 20 Jun 2022 11:21:26 +0000

efi: pstore: Omit efivars caching EFI varstore access layerAvoid the efivars layer and simply call the newly introduced EFIvarstore helpers instead. This simplifies the code substantially, andalso allows us to remove some hacks in the shared efivars layer thatwere 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 therecord may have been loaded from.Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

416581e4 - efi: efibc: avoid efivar API for setting variables

Mon, 20 Jun 2022 09:35:37 +0000

efi: efibc: avoid efivar API for setting variablesAvoid abusing the efivar API by passing locally instantiatedefivar_entry structs into efivar_set_entry_safe(), rather than using theAPI as intended. Instead, just call efi.set_variable() directly.Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

75ed63d9 - efi: clean up Kconfig dependencies on CONFIG_EFI

Sat, 28 May 2022 09:49:54 +0000

efi: clean up Kconfig dependencies on CONFIG_EFIGeert reports that the new option CONFIG_EFI_DISABLE_RUNTIME is uservisible even when EFI support is disabled, which is unnecessary andclutters the Kconfig interface.So let's move this option into the existing Kconfig submenu that alreadydepends on CONFIG_EFI, and while at it, give some other options the sametreatment.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 basedpieces will be built independently (the latter only depends on theformer on !X86)Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

82e0d6d7 - efi: libstub: ensure allocated memory to be executable

Thu, 03 Mar 2022 14:21:20 +0000

efi: libstub: ensure allocated memory to be executableThere are UEFI versions that restrict execution of memory regions,preventing the kernel from booting. Parts that needs to be executableare:* 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 rangesto be executable. Only modify attributes that does nothave appropriate attributes.Signed-off-by: Baskov Evgeniy Link: https://lore.kernel.org/r/20220303142120.1975-3-baskov@ispras.ruSigned-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

12274189 - efi: Save location of EFI confidential computing area

Tue, 12 Apr 2022 21:21:24 +0000

efi: Save location of EFI confidential computing areaConfidential computing (coco) hardware such as AMD SEV (Secure EncryptedVirtualization) allows a guest owner to inject secrets into the VMsmemory without the host/hypervisor being able to read them.Firmware support for secret injection is available in OVMF, whichreserves a memory area for secret injection and includes a pointer to itthe in EFI config table entry LINUX_EFI_COCO_SECRET_TABLE_GUID.If EFI exposes such a table entry, uefi_init() will keep a pointer tothe EFI config table entry in efi.coco_secret, so it can be used laterby the kernel (specifically drivers/virt/coco/efi_secret). It will alsoappear 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=0x7ea0c018The new functionality can be enabled with CONFIG_EFI_COCO_SECRET=y.Signed-off-by: Dov Murik Reviewed-by: Gerd Hoffmann Link: https://lore.kernel.org/r/20220412212127.154182-2-dovmurik@linux.ibm.comSigned-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig

a031651f - efi: Allow to enable EFI runtime services by default on RT

Thu, 31 Mar 2022 15:16:54 +0000

efi: Allow to enable EFI runtime services by default on RTCommit d9f283ae71af ("efi: Disable runtime services on RT") disabled EFIruntime services by default when the CONFIG_PREEMPT_RT option is enabled.The rationale for that commit is that some EFI calls could take too muchtime, 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 toenable 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, thatwould 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 mechanismto 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 theEFI runtime services by default even when CONFIG_PREEMPT_RT is not set.Reported-by: Alexander Larsson Fixes: d9f283ae71af ("efi: Disable runtime services on RT")Signed-off-by: Javier Martinez Canillas Link: https://lore.kernel.org/r/20220331151654.184433-1-javierm@redhat.comSigned-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/firmware/efi/Kconfig