#
decd347c |
|
28-Mar-2024 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Reinstate soft limit for initrd loading Commit 8117961d98fb2 ("x86/efi: Disregard setup header of loaded image") dropped the memcopy of the image's setup header into the boot_params struct provided to the core kernel, on the basis that EFI boot does not need it and should rely only on a single protocol to interface with the boot chain. It is also a prerequisite for being able to increase the section alignment to 4k, which is needed to enable memory protections when running in the boot services. So only the setup_header fields that matter to the core kernel are populated explicitly, and everything else is ignored. One thing was overlooked, though: the initrd_addr_max field in the setup_header is not used by the core kernel, but it is used by the EFI stub itself when it loads the initrd, where its default value of INT_MAX is used as the soft limit for memory allocation. This means that, in the old situation, the initrd was virtually always loaded in the lower 2G of memory, but now, due to initrd_addr_max being 0x0, the initrd may end up anywhere in memory. This should not be an issue principle, as most systems can deal with this fine. However, it does appear to tickle some problems in older UEFI implementations, where the memory ends up being corrupted, resulting in errors when unpacking the initramfs. So set the initrd_addr_max field to INT_MAX like it was before. Fixes: 8117961d98fb2 ("x86/efi: Disregard setup header of loaded image") Reported-by: Radek Podgorny <radek@podgorny.cz> Closes: https://lore.kernel.org/all/a99a831a-8ad5-4cb0-bff9-be637311f771@podgorny.cz Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
df7ecce8 |
|
22-Mar-2024 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Don't clear BSS twice in mixed mode Clearing BSS should only be done once, at the very beginning. efi_pe_entry() is the entrypoint from the firmware, which may not clear BSS and so it is done explicitly. However, efi_pe_entry() is also used as an entrypoint by the mixed mode startup code, in which case BSS will already have been cleared, and doing it again at this point will corrupt global variables holding the firmware's GDT/IDT and segment selectors. So make the memset() conditional on whether the EFI stub is running in native mode. Fixes: b3810c5a2cc4a666 ("x86/efistub: Clear decompressor BSS in native EFI entrypoint") Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
b3810c5a |
|
15-Mar-2024 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Clear decompressor BSS in native EFI entrypoint The EFI stub on x86 no longer invokes the decompressor as a subsequent boot stage, but calls into the decompression code directly while running in the context of the EFI boot services. This means that when using the native EFI entrypoint (as opposed to the EFI handover protocol, which clears BSS explicitly), the firmware PE image loader is being relied upon to ensure that BSS is zeroed before the EFI stub is entered from the firmware. As Radek's report proves, this is a bad idea. Not all loaders do this correctly, which means some global variables that should be statically initialized to 0x0 may have junk in them. So clear BSS explicitly when entering via efi_pe_entry(). Note that zeroing BSS from C code is not generally safe, but in this case, the following assignment and dereference of a global pointer variable ensures that the memset() cannot be deferred or reordered. Cc: <stable@kernel.org> # v6.1+ Reported-by: Radek Podgorny <radek@podgorny.cz> Closes: https://lore.kernel.org/all/a99a831a-8ad5-4cb0-bff9-be637311f771@podgorny.cz Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
9c554610 |
|
25-Jan-2024 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Remap kernel text read-only before dropping NX attribute Currently, the EFI stub invokes the EFI memory attributes protocol to strip any NX restrictions from the entire loaded kernel, resulting in all code and data being mapped read-write-execute. The point of the EFI memory attributes protocol is to remove the need for all memory allocations to be mapped with both write and execute permissions by default, and make it the OS loader's responsibility to transition data mappings to code mappings where appropriate. Even though the UEFI specification does not appear to leave room for denying memory attribute changes based on security policy, let's be cautious and avoid relying on the ability to create read-write-execute mappings. This is trivially achievable, given that the amount of kernel code executing via the firmware's 1:1 mapping is rather small and limited to the .head.text region. So let's drop the NX restrictions only on that subregion, but not before remapping it as read-only first. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
d228814b |
|
14-Feb-2024 |
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> |
efi/libstub: Add get_event_log() support for CC platforms To allow event log info access after boot, EFI boot stub extracts the event log information and installs it in an EFI configuration table. Currently, EFI boot stub only supports installation of event log only for TPM 1.2 and TPM 2.0 protocols. Extend the same support for CC protocol. Since CC platform also uses TCG2 format, reuse TPM2 support code as much as possible. Link: https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#efi-cc-measurement-protocol [1] Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://lkml.kernel.org/r/0229a87e-fb19-4dad-99fc-4afd7ed4099a%40collabora.com [ardb: Split out final events table handling to avoid version confusion] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
cd0d9d92 |
|
27-Feb-2024 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: Move mem_encrypt= parsing to the decompressor The early SME/SEV code parses the command line very early, in order to decide whether or not memory encryption should be enabled, which needs to occur even before the initial page tables are created. This is problematic for a number of reasons: - this early code runs from the 1:1 mapping provided by the decompressor or firmware, which uses a different translation than the one assumed by the linker, and so the code needs to be built in a special way; - parsing external input while the entire kernel image is still mapped writable is a bad idea in general, and really does not belong in security minded code; - the current code ignores the built-in command line entirely (although this appears to be the case for the entire decompressor) Given that the decompressor/EFI stub is an intrinsic part of the x86 bootable kernel image, move the command line parsing there and out of the core kernel. This removes the need to build lib/cmdline.o in a special way, or to use RIP-relative LEA instructions in inline asm blocks. This involves a new xloadflag in the setup header to indicate that mem_encrypt=on appeared on the kernel command line. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/20240227151907.387873-17-ardb+git@google.com
|
#
2f77465b |
|
30-Jan-2024 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR The EFI stub's kernel placement logic randomizes the physical placement of the kernel by taking all available memory into account, and picking a region at random, based on a random seed. When KASLR is disabled, this seed is set to 0x0, and this results in the lowest available region of memory to be selected for loading the kernel, even if this is below LOAD_PHYSICAL_ADDR. Some of this memory is typically reserved for the GFP_DMA region, to accommodate masters that can only access the first 16 MiB of system memory. Even if such devices are rare these days, we may still end up with a warning in the kernel log, as reported by Tom: swapper/0: page allocation failure: order:10, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0 Fix this by tweaking the random allocation logic to accept a low bound on the placement, and set it to LOAD_PHYSICAL_ADDR. Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") Reported-by: Tom Englund <tomenglund26@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218404 Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
a7a6a01f |
|
25-Jan-2024 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Give up if memory attribute protocol returns an error The recently introduced EFI memory attributes protocol should be used if it exists to ensure that the memory allocation created for the kernel permits execution. This is needed for compatibility with tightened requirements related to Windows logo certification for x86 PCs. Currently, we simply strip the execute protect (XP) attribute from the entire range, but this might be rejected under some firmware security policies, and so in a subsequent patch, this will be changed to only strip XP from the executable region that runs early, and make it read-only (RO) as well. In order to catch any issues early, ensure that the memory attribute protocol works as intended, and give up if it produces spurious errors. Note that the DXE services based fallback was always based on best effort, so don't propagate any errors returned by that API. Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
01638431 |
|
26-Dec-2023 |
Yuntao Wang <ytcoode@gmail.com> |
efi/x86: Fix the missing KASLR_FLAG bit in boot_params->hdr.loadflags When KASLR is enabled, the KASLR_FLAG bit in boot_params->hdr.loadflags should be set to 1 to propagate KASLR status from compressed kernel to kernel, just as the choose_random_location() function does. Currently, when the kernel is booted via the EFI stub, the KASLR_FLAG bit in boot_params->hdr.loadflags is not set, even though it should be. This causes some functions, such as kernel_randomize_memory(), not to execute as expected. Fix it. Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") Signed-off-by: Yuntao Wang <ytcoode@gmail.com> [ardb: drop 'else' branch clearing KASLR_FLAG] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
50d7cdf7 |
|
11-Dec-2023 |
Ard Biesheuvel <ardb@kernel.org> |
efi/x86: Avoid physical KASLR on older Dell systems River reports boot hangs with v6.6 and v6.7, and the bisect points to commit a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") which moves the memory allocation and kernel decompression from the legacy decompressor (which executes *after* ExitBootServices()) to the EFI stub, using boot services for allocating the memory. The memory allocation succeeds but the subsequent call to decompress_kernel() never returns, resulting in a failed boot and a hanging system. As it turns out, this issue only occurs when physical address randomization (KASLR) is enabled, and given that this is a feature we can live without (virtual KASLR is much more important), let's disable the physical part of KASLR when booting on AMI UEFI firmware claiming to implement revision v2.0 of the specification (which was released in 2006), as this is the version these systems advertise. Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218173 Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
50dcc2e0 |
|
17-Oct-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: efistub: Assign global boot_params variable Now that the x86 EFI stub calls into some APIs exposed by the decompressor (e.g., kaslr_get_random_long()), it is necessary to ensure that the global boot_params variable is set correctly before doing so. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: linux-kernel@vger.kernel.org
|
#
7e502622 |
|
12-Sep-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efi: Disregard setup header of loaded image The native EFI entrypoint does not take a struct boot_params from the loader, but instead, it constructs one from scratch, using the setup header data placed at the start of the image. This setup header is placed in a way that permits legacy loaders to manipulate the contents (i.e., to pass the kernel command line or the address and size of an initial ramdisk), but EFI boot does not use it in that way - it only copies the contents that were placed there at build time, but EFI loaders will not (and should not) manipulate the setup header to configure the boot. (Commit 63bf28ceb3ebbe76 "efi: x86: Wipe setup_data on pure EFI boot" deals with some of the fallout of using setup_data in a way that breaks EFI boot.) Given that none of the non-zero values that are copied from the setup header into the EFI stub's struct boot_params are relevant to the boot now that the EFI stub no longer enters via the legacy decompressor, the copy can be omitted altogether. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230912090051.4014114-19-ardb@google.com
|
#
db772413 |
|
16-Oct-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot: efistub: Assign global boot_params variable Now that the x86 EFI stub calls into some APIs exposed by the decompressor (e.g., kaslr_get_random_long()), it is necessary to ensure that the global boot_params variable is set correctly before doing so. Note that the decompressor and the kernel proper carry conflicting declarations for the global variable 'boot_params' so refer to it via an alias to work around this. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
ff07186b |
|
11-Oct-2023 |
Nikolay Borisov <nik.borisov@suse.com> |
x86/efistub: Don't try to print after ExitBootService() setup_e820() is executed after UEFI's ExitBootService has been called. This causes the firmware to throw an exception because the Console IO protocol is supposed to work only during boot service environment. As per UEFI 2.9, section 12.1: "This protocol is used to handle input and output of text-based information intended for the system user during the operation of code in the boot services environment." So drop the diagnostic warning from this function. We might add back a warning that is issued later when initializing the kernel itself. Signed-off-by: Nikolay Borisov <nik.borisov@suse.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
8b94da92 |
|
23-Aug-2023 |
Mikel Rychliski <mikel@mikelr.com> |
x86/efistub: Fix PCI ROM preservation in mixed mode preserve_pci_rom_image() was accessing the romsize field in efi_pci_io_protocol_t directly instead of using the efi_table_attr() helper. This prevents the ROM image from being saved correctly during a mixed mode boot. Fixes: 2c3625cb9fa2 ("efi/x86: Fold __setup_efi_pci32() and __setup_efi_pci64() into one function") Signed-off-by: Mikel Rychliski <mikel@mikelr.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
a1b87d54 |
|
07-Aug-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Avoid legacy decompressor when doing EFI boot The bare metal decompressor code was never really intended to run in a hosted environment such as the EFI boot services, and does a few things that are becoming problematic in the context of EFI boot now that the logo requirements are getting tighter: EFI executables will no longer be allowed to consist of a single executable section that is mapped with read, write and execute permissions if they are intended for use in a context where Secure Boot is enabled (and where Microsoft's set of certificates is used, i.e., every x86 PC built to run Windows). To avoid stepping on reserved memory before having inspected the E820 tables, and to ensure the correct placement when running a kernel build that is non-relocatable, the bare metal decompressor moves its own executable image to the end of the allocation that was reserved for it, in order to perform the decompression in place. This means the region in question requires both write and execute permissions, which either need to be given upfront (which EFI will no longer permit), or need to be applied on demand using the existing page fault handling framework. However, the physical placement of the kernel is usually randomized anyway, and even if it isn't, a dedicated decompression output buffer can be allocated anywhere in memory using EFI APIs when still running in the boot services, given that EFI support already implies a relocatable kernel. This means that decompression in place is never necessary, nor is moving the compressed image from one end to the other. Since EFI already maps all of memory 1:1, it is also unnecessary to create new page tables or handle page faults when decompressing the kernel. That means there is also no need to replace the special exception handlers for SEV. Generally, there is little need to do any of the things that the decompressor does beyond - initialize SEV encryption, if needed, - perform the 4/5 level paging switch, if needed, - decompress the kernel - relocate the kernel So do all of this from the EFI stub code, and avoid the bare metal decompressor altogether. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230807162720.545787-24-ardb@kernel.org
|
#
31c77a50 |
|
07-Aug-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Perform SNP feature test while running in the firmware Before refactoring the EFI stub boot flow to avoid the legacy bare metal decompressor, duplicate the SNP feature check in the EFI stub before handing over to the kernel proper. The SNP feature check can be performed while running under the EFI boot services, which means it can force the boot to fail gracefully and return an error to the bootloader if the loaded kernel does not implement support for all the features that the hypervisor enabled. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230807162720.545787-23-ardb@kernel.org
|
#
11078876 |
|
07-Aug-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Prefer EFI memory attributes protocol over DXE services Currently, the EFI stub relies on DXE services in some cases to clear non-execute restrictions from page allocations that need to be executable. This is dodgy, because DXE services are not specified by UEFI but by PI, and they are not intended for consumption by OS loaders. However, no alternative existed at the time. Now, there is a new UEFI protocol that should be used instead, so if it exists, prefer it over the DXE services calls. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230807162720.545787-18-ardb@kernel.org
|
#
cb1c9e02 |
|
07-Aug-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Perform 4/5 level paging switch from the stub In preparation for updating the EFI stub boot flow to avoid the bare metal decompressor code altogether, implement the support code for switching between 4 and 5 levels of paging before jumping to the kernel proper. Reuse the newly refactored trampoline that the bare metal decompressor uses, but relies on EFI APIs to allocate 32-bit addressable memory and remap it with the appropriate permissions. Given that the bare metal decompressor will no longer call into the trampoline if the number of paging levels is already set correctly, it is no longer needed to remove NX restrictions from the memory range where this trampoline may end up. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Link: https://lore.kernel.org/r/20230807162720.545787-17-ardb@kernel.org
|
#
d7156b98 |
|
07-Aug-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Clear BSS in EFI handover protocol entrypoint The so-called EFI handover protocol is value-add from the distros that permits a loader to simply copy a PE kernel image into memory and call an alternative entrypoint that is described by an embedded boot_params structure. Most implementations of this protocol do not bother to check the PE header for minimum alignment, section placement, etc, and therefore also don't clear the image's BSS, or even allocate enough memory for it. Allocating more memory on the fly is rather difficult, but at least clear the BSS region explicitly when entering in this manner, so that the EFI stub code does not get confused by global variables that were not zero-initialized correctly. When booting in mixed mode, this BSS clearing must occur before any global state is created, so clear it in the 32-bit asm entry point. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230807162720.545787-7-ardb@kernel.org
|
#
df9215f1 |
|
07-Aug-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Simplify and clean up handover entry code Now that the EFI entry code in assembler is only used by the optional and deprecated EFI handover protocol, and given that the EFI stub C code no longer returns to it, most of it can simply be dropped. While at it, clarify the symbol naming, by merging efi_main() and efi_stub_entry(), making the latter the shared entry point for all different boot modes that enter via the EFI stub. The efi32_stub_entry() and efi64_stub_entry() names are referenced explicitly by the tooling that populates the setup header, so these must be retained, but can be emitted as aliases of efi_stub_entry() where appropriate. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230807162720.545787-5-ardb@kernel.org
|
#
d2d7a54f |
|
07-Aug-2023 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Branch straight to kernel entry point from C code Instead of returning to the calling code in assembler that does nothing more than perform an indirect call with the boot_params pointer in register ESI/RSI, perform the jump directly from the EFI stub C code. This will allow the asm entrypoint code to be dropped entirely in subsequent patches. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230807162720.545787-4-ardb@kernel.org
|
#
c0461bd1 |
|
06-Jun-2023 |
Dionna Glaze <dionnaglaze@google.com> |
x86/efi: Safely enable unaccepted memory in UEFI The UEFI v2.9 specification includes a new memory type to be used in environments where the OS must accept memory that is provided from its host. Before the introduction of this memory type, all memory was accepted eagerly in the firmware. In order for the firmware to safely stop accepting memory on the OS's behalf, the OS must affirmatively indicate support to the firmware. This is only a problem for AMD SEV-SNP, since Linux has had support for it since 5.19. The other technology that can make use of unaccepted memory, Intel TDX, does not yet have Linux support, so it can strictly require unaccepted memory support as a dependency of CONFIG_TDX and not require communication with the firmware. Enabling unaccepted memory requires calling a 0-argument enablement protocol before ExitBootServices. This call is only made if the kernel is compiled with UNACCEPTED_MEMORY=y This protocol will be removed after the end of life of the first LTS that includes it, in order to give firmware implementations an expiration date for it. When the protocol is removed, firmware will strictly infer that a SEV-SNP VM is running an OS that supports the unaccepted memory type. At the earliest convenience, when unaccepted memory support is added to Linux, SEV-SNP may take strict dependence in it. After the firmware removes support for the protocol, this should be reverted. [tl: address some checkscript warnings] Signed-off-by: Dionna Glaze <dionnaglaze@google.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/0d5f3d9a20b5cf361945b7ab1263c36586a78a42.1686063086.git.thomas.lendacky@amd.com
|
#
745e3ed8 |
|
06-Jun-2023 |
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> |
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
|
#
2e9f46ee |
|
06-Jun-2023 |
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> |
efi/x86: Get full memory map in allocate_e820() Currently allocate_e820() is only interested in the size of map and size of memory descriptor to determine how many e820 entries the kernel needs. UEFI Specification version 2.9 introduces a new memory type -- unaccepted memory. To track unaccepted memory, the kernel needs to allocate a bitmap. The size of the bitmap is dependent on the maximum physical address present in the system. A full memory map is required to find the maximum address. Modify allocate_e820() to get a full memory map. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Borislav Petkov <bp@suse.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20230606142637.5171-3-kirill.shutemov@linux.intel.com
|
#
4b520162 |
|
22-Nov-2022 |
Ard Biesheuvel <ardb@kernel.org> |
x86/boot/compressed, efi: Merge multiple definitions of image_offset into one There is no need for head_32.S and head_64.S both declaring a copy of the global 'image_offset' variable, so drop those and make the extern C declaration the definition. When image_offset is moved to the .c file, it needs to be placed particularly in the .data section because it lands by default in the .bss section which is cleared too late, in .Lrelocated, before the first access to it and thus garbage gets read, leading to SEV guests exploding in early boot. This happens only when the SEV guest kernel is loaded through grub. If supplied with qemu's -kernel command line option, that memory is always cleared upfront by qemu and all is fine there. [ bp: Expand commit message with SEV aspect. ] Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20221122161017.2426828-8-ardb@kernel.org
|
#
db14655a |
|
14-Oct-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: Give efi_main() asmlinkage qualification To stop the bots from sending sparse warnings to me and the list about efi_main() not having a prototype, decorate it with asmlinkage so that it is clear that it is called from assembly, and therefore needs to remain external, even if it is never declared in a header file. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
f4dc7fff |
|
16-Sep-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: unify initrd loading between architectures Use a EFI configuration table to pass the initrd to the core kernel, instead of per-arch methods. This cleans up the code considerably, and should make it easier for architectures to get rid of their reliance on DT for doing EFI boot in the future. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
eab31265 |
|
03-Jun-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: simplify efi_get_memory_map() and struct efi_boot_memmap Currently, struct efi_boot_memmap is a struct that is passed around between callers of efi_get_memory_map() and the users of the resulting data, and which carries pointers to various variables whose values are provided by the EFI GetMemoryMap() boot service. This is overly complex, and it is much easier to carry these values in the struct itself. So turn the struct into one that carries these data items directly, including a flex array for the variable number of EFI memory descriptors that the boot service may return. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
63bf28ce |
|
04-Aug-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: x86: Wipe setup_data on pure EFI boot When booting the x86 kernel via EFI using the LoadImage/StartImage boot services [as opposed to the deprecated EFI handover protocol], the setup header is taken from the image directly, and given that EFI's LoadImage has no Linux/x86 specific knowledge regarding struct bootparams or struct setup_header, any absolute addresses in the setup header must originate from the file and not from a prior loading stage. Since we cannot generally predict where LoadImage() decides to load an image (*), such absolute addresses must be treated as suspect: even if a prior boot stage intended to make them point somewhere inside the [signed] image, there is no way to validate that, and if they point at an arbitrary location in memory, the setup_data nodes will not be covered by any signatures or TPM measurements either, and could be made to contain an arbitrary sequence of SETUP_xxx nodes, which could interfere quite badly with the early x86 boot sequence. (*) Note that, while LoadImage() does take a buffer/size tuple in addition to a device path, which can be used to provide the image contents directly, it will re-allocate such images, as the memory footprint of an image is generally larger than the PE/COFF file representation. Cc: <stable@vger.kernel.org> # v5.10+ Link: https://lore.kernel.org/all/20220904165321.1140894-1-Jason@zx2c4.com/ Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
#
7a1ec84f |
|
06-Sep-2022 |
chen zhang <chenzhang@kylinos.cn> |
efi/x86: libstub: remove unused variable The variable "has_system_memory" is unused in function ‘adjust_memory_range_protection’, remove it. Signed-off-by: chen zhang <chenzhang@kylinos.cn> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
31f1a0ed |
|
19-May-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi/x86: libstub: Make DXE calls mixed mode safe The newly added DXE calls use 64-bit quantities, which means we need to marshall them explicitly when running in mixed mode. Currently, we get away without it because we just bail when GetMemorySpaceDescriptor() fails, which is guaranteed to happen due to the function argument mixup. Let's fix this properly, though, by defining the macros that describe how to marshall the arguments. While at it, drop an incorrect cast on a status variable. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
82e0d6d7 |
|
03-Mar-2022 |
Baskov Evgeniy <baskov@ispras.ru> |
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>
|
#
3ba75c13 |
|
03-Mar-2022 |
Baskov Evgeniy <baskov@ispras.ru> |
efi: libstub: declare DXE services table UEFI DXE services are not yet used in kernel code but are required to manipulate page table memory protection flags. Add required declarations to use DXE services functions. Signed-off-by: Baskov Evgeniy <baskov@ispras.ru> Link: https://lore.kernel.org/r/20220303142120.1975-2-baskov@ispras.ru [ardb: ignore absent DXE table but warn if the signature check fails] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
20287d56 |
|
19-Nov-2021 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: consolidate initrd handling across architectures Before adding TPM measurement of the initrd contents, refactor the initrd handling slightly to be more self-contained and consistent. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Link: https://lore.kernel.org/r/20211119114745.1560453-4-ilias.apalodimas@linaro.org Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
688eb282 |
|
11-Oct-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Only copy the compressed kernel image in efi_relocate_kernel() The image_size argument to efi_relocate_kernel() is currently specified as init_size, but this is unnecessarily large. The compressed kernel is much smaller, in fact, its image only extends up to the start of _bss, since at this point, the .bss section is still uninitialized. Depending on compression level, this can reduce the amount of data copied by 4-5x. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20201011142012.96493-1-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
59476f80 |
|
18-Jun-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Only copy upto the end of setup_header When copying the setup_header into the boot_params buffer, only the data that is actually part of the setup_header should be copied. efi_pe_entry() currently copies the entire second sector, which initializes some of the fields in boot_params beyond the setup_header with garbage (i.e. part of the real-mode boot code gets copied into those fields). This does not cause any issues currently because the fields that are overwritten are padding, BIOS EDD information that won't get used, and the E820 table which will get properly filled in later. Fix this to only copy data that is actually part of the setup_header structure. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
0bda49f3 |
|
18-Jun-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Remove unused variables Commit 987053a30016 ("efi/x86: Move command-line initrd loading to efi_main") made the ramdisk_addr/ramdisk_size variables in efi_pe_entry unused, but neglected to delete them. Delete these unused variables. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
e9524fb9 |
|
27-May-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Don't blow away existing initrd Commit 987053a30016 ("efi/x86: Move command-line initrd loading to efi_main") moved the command-line initrd loading into efi_main(), with a check to ensure that it was attempted only if the EFI stub was booted via efi_pe_entry rather than the EFI handover entry. However, in the case where it was booted via handover entry, and thus an initrd may have already been loaded by the bootloader, it then wrote 0 for the initrd address and size, removing any existing initrd. Fix this by checking if size is positive before setting the fields in the bootparams structure. Fixes: 987053a30016 ("efi/x86: Move command-line initrd loading to efi_main") Reported-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Dan Williams <dan.j.williams@intel.com> Link: https://lkml.kernel.org/r/20200527232602.21596-1-nivedita@alum.mit.edu
|
#
27cd5511 |
|
19-May-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Use pool allocation for the command line Now that we removed the memory limit for the allocation of the command line, there is no longer a need to use the page based allocator so switch to a pool allocation instead. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
fd626195 |
|
07-May-2020 |
Lenny Szubowicz <lszubowi@redhat.com> |
efi/libstub/x86: Avoid EFI map buffer alloc in allocate_e820() In allocate_e820(), call the EFI get_memory_map() service directly instead of indirectly via efi_get_memory_map(). This avoids allocation of a buffer and return of the full EFI memory map, which is not needed here and would otherwise need to be freed. Routine allocate_e820() only needs to know how many EFI memory descriptors there are in the map to allocate an adequately sized e820ext buffer, if it's needed. Note that since efi_get_memory_map() returns a memory map buffer sized with extra headroom, allocate_e820() now needs to explicitly factor that into the e820ext size calculation. Signed-off-by: Lenny Szubowicz <lszubowi@redhat.com> Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
055042be |
|
30-Apr-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/libstub: Check return value of efi_parse_options efi_parse_options can fail if it is unable to allocate space for a copy of the command line. Check the return value to make sure it succeeded. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-12-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
7dde67f2 |
|
30-Apr-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Support builtin command line Add support for the x86 CMDLINE_BOOL and CMDLINE_OVERRIDE configuration options. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-11-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
f61900fd |
|
30-Apr-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/libstub: Unify initrd loading across architectures Factor out the initrd loading into a common function that can be called both from the generic efi-stub.c and the x86-specific x86-stub.c. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-10-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
987053a3 |
|
30-Apr-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Move command-line initrd loading to efi_main Consolidate the initrd loading in efi_main. The command line options now need to be parsed only once. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-9-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
36bdd0a7 |
|
30-Apr-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Use efi_err for error messages Use efi_err instead of bare efi_printk for error messages. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-5-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
eed4e019 |
|
30-Apr-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/libstub: Add a helper function to split 64-bit values In several places 64-bit values need to be split up into two 32-bit fields, in order to be backward-compatible with the old 32-bit ABIs. Instead of open-coding this, add a helper function to set a 64-bit value as two 32-bit fields. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-3-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
019512f1 |
|
30-Apr-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Use correct size for boot_params struct boot_params is only 4096 bytes, not 16384. Fix this by using sizeof(struct boot_params) instead of hardcoding the incorrect value. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-2-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
0a755614 |
|
16-Apr-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub/x86: Avoid getter function for efi_is64 We no longer need to take special care when using global variables in the EFI stub, so switch to a simple symbol reference for efi_is64. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
980771f6 |
|
16-Apr-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Drop __pure getters for EFI stub options The practice of using __pure getter functions to access global variables in the EFI stub dates back to the time when we had to carefully prevent GOT entries from being emitted, because we could not rely on the toolchain to do this for us. Today, we use the hidden visibility pragma for all EFI stub source files, which now all live in the same subdirectory, and we apply a sanity check on the objects, so we can get rid of these getter functions and simply refer to global data objects directly. So switch over the remaining boolean variables carrying options set on the kernel command line. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
ccc27ae7 |
|
16-Apr-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Drop __pure getter for efi_system_table The practice of using __pure getter functions to access global variables in the EFI stub dates back to the time when we had to carefully prevent GOT entries from being emitted, because we could not rely on the toolchain to do this for us. Today, we use the hidden visibility pragma for all EFI stub source files, which now all live in the same subdirectory, and we apply a sanity check on the objects, so we can get rid of these getter functions and simply refer to global data objects directly. Start with efi_system_table(), and convert it into a global variable. While at it, make it a pointer-to-const, because we can. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
54439370 |
|
16-Apr-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi: Kill __efistub_global Now that both arm and x86 are using the linker script to place the EFI stub's global variables in the correct section, remove __efistub_global. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20200416151227.3360778-4-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
21cb9b41 |
|
09-Apr-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Always relocate the kernel for EFI handover entry Commit d5cdf4cfeac9 ("efi/x86: Don't relocate the kernel unless necessary") tries to avoid relocating the kernel in the EFI stub as far as possible. However, when systemd-boot is used to boot a unified kernel image [1], the image is constructed by embedding the bzImage as a .linux section in a PE executable that contains a small stub loader from systemd that will call the EFI stub handover entry, together with additional sections and potentially an initrd. When this image is constructed, by for example dracut, the initrd is placed after the bzImage without ensuring that at least init_size bytes are available for the bzImage. If the kernel is not relocated by the EFI stub, this could result in the compressed kernel's startup code in head_{32,64}.S overwriting the initrd. To prevent this, unconditionally relocate the kernel if the EFI stub was entered via the handover entry point. [1] https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images Fixes: d5cdf4cfeac9 ("efi/x86: Don't relocate the kernel unless necessary") Reported-by: Sergey Shatunov <me@prok.pw> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200406180614.429454-2-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200409130434.6736-5-ardb@kernel.org
|
#
105cb954 |
|
09-Apr-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Move efi stub globals from .bss to .data Commit 3ee372ccce4d ("x86/boot/compressed/64: Remove .bss/.pgtable from bzImage") removed the .bss section from the bzImage. However, while a PE loader is required to zero-initialize the .bss section before calling the PE entry point, the EFI handover protocol does not currently document any requirement that .bss be initialized by the bootloader prior to calling the handover entry. When systemd-boot is used to boot a unified kernel image [1], the image is constructed by embedding the bzImage as a .linux section in a PE executable that contains a small stub loader from systemd together with additional sections and potentially an initrd. As the .bss section within the bzImage is no longer explicitly present as part of the file, it is not initialized before calling the EFI handover entry. Furthermore, as the size of the embedded .linux section is only the size of the bzImage file itself, the .bss section's memory may not even have been allocated. In particular, this can result in efi_disable_pci_dma being true even when it was not specified via the command line or configuration option, which in turn causes crashes while booting on some systems. To avoid issues, place all EFI stub global variables into the .data section instead of .bss. As of this writing, only boolean flags for a few command line arguments and the sys_table pointer were in .bss and will now move into the .data section. [1] https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images Fixes: 3ee372ccce4d ("x86/boot/compressed/64: Remove .bss/.pgtable from bzImage") Reported-by: Sergey Shatunov <me@prok.pw> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200406180614.429454-1-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200409130434.6736-4-ardb@kernel.org
|
#
05a08796 |
|
09-Apr-2020 |
Colin Ian King <colin.king@canonical.com> |
efi/libstub/x86: Remove redundant assignment to pointer hdr The pointer hdr is being assigned a value that is never read and it is being updated later with a new value. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200402102537.503103-1-colin.king@canonical.com Link: https://lore.kernel.org/r/20200409130434.6736-3-ardb@kernel.org
|
#
0347d8c2 |
|
08-Mar-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Fix cast of image argument handle_protocol() expects void **, not void *. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200305143642.820865-1-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-28-ardb@kernel.org
|
#
ac82d356 |
|
08-Mar-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub/x86: Use ULONG_MAX as upper bound for all allocations The header flag XLF_CAN_BE_LOADED_ABOVE_4G will inform us whether allocations above 4 GiB for kernel, command line, etc are permitted, so we take it into account when calling efi_allocate_pages() etc. However, CONFIG_EFI_STUB implies CONFIG_RELOCATABLE, and so the flag is guaranteed to be set on x86_64 builds, whereas i386 builds are guaranteed to run under firmware that will not allocate above 4 GB in the first place. So drop the check, and just pass ULONG_MAX as the upper bound for all allocations. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200303225054.28741-1-ardb@kernel.org Link: https://lore.kernel.org/r/20200308080859.21568-27-ardb@kernel.org
|
#
d5cdf4cf |
|
08-Mar-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Don't relocate the kernel unless necessary Add alignment slack to the PE image size, so that we can realign the decompression buffer within the space allocated for the image. Only relocate the kernel if it has been loaded at an unsuitable address: - Below LOAD_PHYSICAL_ADDR, or - Above 64T for 64-bit and 512MiB for 32-bit For 32-bit, the upper limit is conservative, but the exact limit can be difficult to calculate. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200303221205.4048668-6-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-20-ardb@kernel.org
|
#
1887c9b6 |
|
08-Mar-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Decompress at start of PE image load address When booted via PE loader, define image_offset to hold the offset of startup_32() from the start of the PE image, and use it as the start of the decompression buffer. [ mingo: Fixed the grammar in the comments. ] Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200303221205.4048668-3-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-17-ardb@kernel.org
|
#
f3fa0efc |
|
08-Mar-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub/x86: Deal with exit() boot service returning Even though it is uncommon, there are cases where the Exit() EFI boot service might return, e.g., when we were booted via the EFI handover protocol from OVMF and the kernel image was specified on the command line, in which case Exit() attempts to terminate the boot manager, which is not an EFI application itself. So let's drop into an infinite loop instead of randomly executing code that isn't expecting it. Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build Signed-off-by: Ard Biesheuvel <ardb@kernel.org> [ardb: put 'hlt' in deadloop] Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200303080648.21427-1-ardb@kernel.org Link: https://lore.kernel.org/r/20200308080859.21568-15-ardb@kernel.org
|
#
8acf63ef |
|
08-Mar-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/x86: Avoid using code32_start code32_start is meant for 16-bit real-mode bootloaders to inform the kernel where the 32-bit protected mode code starts. Nothing in the protected mode kernel except the EFI stub uses it. efi_main() currently returns boot_params, with code32_start set inside it to tell efi_stub_entry() where startup_32 is located. Since it was invoked by efi_stub_entry() in the first place, boot_params is already known. Return the address of startup_32 instead. This will allow a 64-bit kernel to live above 4Gb, for example, and it's cleaner as well. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200301230436.2246909-5-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-13-ardb@kernel.org
|
#
17054f49 |
|
12-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/x86: Implement mixed mode boot without the handover protocol Add support for booting 64-bit x86 kernels from 32-bit firmware running on 64-bit capable CPUs without requiring the bootloader to implement the EFI handover protocol or allocate the setup block, etc etc, all of which can be done by the stub itself, using code that already exists. Instead, create an ordinary EFI application entrypoint but implemented in 32-bit code [so that it can be invoked by 32-bit firmware], and stash the address of this 32-bit entrypoint in the .compat section where the bootloader can find it. Note that we use the setup block embedded in the binary to go through startup_32(), but it gets reallocated and copied in efi_pe_entry(), using the same code that runs when the x86 kernel is booted in EFI mode from native firmware. This requires the loaded image protocol to be installed on the kernel image's EFI handle, and point to the kernel image itself and not to its loader. This, in turn, requires the bootloader to use the LoadImage() boot service to load the 64-bit image from 32-bit firmware, which is in fact supported by firmware based on EDK2. (Only StartImage() will fail, and instead, the newly added entrypoint needs to be invoked) Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
3b8f44fc |
|
15-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub/x86: Use Exit() boot service to exit the stub on errors Currently, we either return with an error [from efi_pe_entry()] or enter a deadloop [in efi_main()] if any fatal errors occur during execution of the EFI stub. Let's switch to calling the Exit() EFI boot service instead in both cases, so that we a) can get rid of the deadloop, and simply return to the boot manager if any errors occur during execution of the stub, including during the call to ExitBootServices(), b) can also return cleanly from efi_pe_entry() or efi_main() in mixed mode, once we introduce support for LoadImage/StartImage based mixed mode in the next patch. Note that on systems running downstream GRUBs [which do not use LoadImage or StartImage to boot the kernel, and instead, pass their own image handle as the loaded image handle], calling Exit() will exit from GRUB rather than from the kernel, but this is a tolerable side effect. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
f7b85b33 |
|
14-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub/x86: Make loaded_image protocol handling mixed mode safe Add the definitions and use the special wrapper so that the loaded_image UEFI protocol can be safely used from mixed mode. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
79d3219d |
|
04-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Take noinitrd cmdline argument into account for devpath initrd One of the advantages of using what basically amounts to a callback interface into the bootloader for loading the initrd is that it provides a natural place for the bootloader or firmware to measure the initrd contents while they are being passed to the kernel. Unfortunately, this is not a guarantee that the initrd will in fact be loaded and its /init invoked by the kernel, since the command line may contain the 'noinitrd' option, in which case the initrd is ignored, but this will not be reflected in the PCR that covers the initrd measurement. This could be addressed by measuring the command line as well, and including that PCR in the attestation policy, but this locks down the command line completely, which may be too restrictive. So let's take the noinitrd argument into account in the stub, too. This forces any PCR that covers the initrd to assume a different value when noinitrd is passed, allowing an attestation policy to disregard the command line if there is no need to take its measurement into account for other reasons. As Peter points out, this would still require the agent that takes the measurements to measure a separator event into the PCR in question at ExitBootServices() time, to prevent replay attacks using the known measurement from the TPM log. Cc: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
ec93fc37 |
|
03-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Add support for loading the initrd from a device path There are currently two ways to specify the initrd to be passed to the Linux kernel when booting via the EFI stub: - it can be passed as a initrd= command line option when doing a pure PE boot (as opposed to the EFI handover protocol that exists for x86) - otherwise, the bootloader or firmware can load the initrd into memory, and pass the address and size via the bootparams struct (x86) or device tree (ARM) In the first case, we are limited to loading from the same file system that the kernel was loaded from, and it is also problematic in a trusted boot context, given that we cannot easily protect the command line from tampering without either adding complicated white/blacklisting of boot arguments or locking down the command line altogether. In the second case, we force the bootloader to duplicate knowledge about the boot protocol which is already encoded in the stub, and which may be subject to change over time, e.g., bootparams struct definitions, memory allocation/alignment requirements for the placement of the initrd etc etc. In the ARM case, it also requires the bootloader to modify the hardware description provided by the firmware, as it is passed in the same file. On systems where the initrd is measured after loading, it creates a time window where the initrd contents might be manipulated in memory before handing over to the kernel. Address these concerns by adding support for loading the initrd into memory by invoking the EFI LoadFile2 protocol installed on a vendor GUIDed device path that specifically designates a Linux initrd. This addresses the above concerns, by putting the EFI stub in charge of placement in memory and of passing the base and size to the kernel proper (via whatever means it desires) while still leaving it up to the firmware or bootloader to obtain the file contents, potentially from other file systems than the one the kernel itself was loaded from. On platforms that implement measured boot, it permits the firmware to take the measurement right before the kernel actually consumes the contents. Acked-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
91d150c0 |
|
10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Clean up command line parsing routine We currently parse the command non-destructively, to avoid having to allocate memory for a copy before passing it to the standard parsing routines that are used by the core kernel, and which modify the input to delineate the parsed tokens with NUL characters. Instead, we call strstr() and strncmp() to go over the input multiple times, and match prefixes rather than tokens, which implies that we would match, e.g., 'nokaslrfoo' in the stub and disable KASLR, while the kernel would disregard the option and run with KASLR enabled. In order to avoid having to reason about whether and how this behavior may be abused, let's clean up the parsing routines, and rebuild them on top of the existing helpers. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
31f5e546 |
|
10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Take soft and hard memory limits into account for initrd loading On x86, the preferred load address of the initrd is still below 4 GB, even though in some cases, we can cope with an initrd that is loaded above that. To simplify the code, and to make it more straightforward to introduce other ways to load the initrd, pass the soft and hard memory limits at the same time, and let the code handling the initrd= command line option deal with this. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
9302c1bb |
|
10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Rewrite file I/O routine The file I/O routine that is used to load initrd or dtb files from the EFI system partition suffers from a few issues: - it converts the u8[] command line back to a UTF-16 string, which is pointless since we only handle initrd or dtb arguments provided via the loaded image protocol anyway, which is where we got the UTF-16[] command line from in the first place when booting via the PE entry point, - in the far majority of cases, only a single initrd= option is present, but it optimizes for multiple options, by going over the command line twice, allocating heap buffers for dynamically sized arrays, etc. - the coding style is hard to follow, with few comments, and all logic including string parsing etc all combined in a single routine. Let's fix this by rewriting most of it, based on the idea that in the case of multiple initrds, we can just allocate a new, bigger buffer and copy over the data before freeing the old one. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
1e45bf73 |
|
10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub/x86: Permit cmdline data to be allocated above 4 GB We now support cmdline data that is located in memory that is not 32-bit addressable, so relax the allocation limit on systems where this feature is enabled. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
6a4db9bf |
|
10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub/x86: Permit bootparams struct to be allocated above 4 GB We now support bootparams structures that are located in memory that is not 32-bit addressable, so relax the allocation limit on systems where this feature is enabled. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
c2d0b470 |
|
10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub/x86: Incorporate eboot.c into libstub Most of the EFI stub source files of all architectures reside under drivers/firmware/efi/libstub, where they share a Makefile with special CFLAGS and an include file with declarations that are only relevant for stub code. Currently, we carry a lot of stub specific stuff in linux/efi.h only because eboot.c in arch/x86 needs them as well. So let's move eboot.c into libstub/, and move the contents of eboot.h that we still care about into efistub.h Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|