kernel/git/stable/linux.git/drivers/firmware/efi, branch linux-6.17.y

efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs

2025-12-18T13:00:15+00:00

[ Upstream commit 96b010536ee020e716d28d9b359a4bcd18800aeb ] Up to UEFI spec 2.9, the type byte of CPER struct for ARM processor was defined simply as: Type at byte offset 4: - Cache error - TLB Error - Bus Error - Micro-architectural Error All other values are reserved Yet, there was no information about how this would be encoded. Spec 2.9A errata corrected it by defining: - Bit 1 - Cache Error - Bit 2 - TLB Error - Bit 3 - Bus Error - Bit 4 - Micro-architectural Error All other values are reserved That actually aligns with the values already defined on older versions at N.2.4.1. Generic Processor Error Section. Spec 2.10 also preserve the same encoding as 2.9A. Adjust CPER and GHES handling code for both generic and ARM processors to properly handle UEFI 2.9A and 2.10 encoding. Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-information Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Borislav Petkov (AMD) Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

efi/cper: Adjust infopfx size to accept an extra space

2025-12-18T13:00:14+00:00

[ Upstream commit 8ad2c72e21efb3dc76c5b14089fa7984cdd87898 ] Compiling with W=1 with werror enabled produces an error: drivers/firmware/efi/cper-arm.c: In function ‘cper_print_proc_arm’: drivers/firmware/efi/cper-arm.c:298:64: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] 298 | snprintf(infopfx, sizeof(infopfx), "%s ", newpfx); | ^ drivers/firmware/efi/cper-arm.c:298:25: note: ‘snprintf’ output between 2 and 65 bytes into a destination of size 64 298 | snprintf(infopfx, sizeof(infopfx), "%s ", newpfx); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As the logic there adds an space at the end of infopx buffer. Add an extra space to avoid such warning. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Borislav Petkov (AMD) Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

efi/cper: Add a new helper function to print bitmasks

2025-12-18T13:00:14+00:00

[ Upstream commit a976d790f49499ccaa0f991788ad8ebf92e7fd5c ] Add a helper function to print a string with names associated to each bit field. A typical example is: const char * const bits[] = { "bit 3 name", "bit 4 name", "bit 5 name", }; char str[120]; unsigned int bitmask = BIT(3) | BIT(5); #define MASK GENMASK(5,3) cper_bits_to_str(str, sizeof(str), FIELD_GET(MASK, bitmask), bits, ARRAY_SIZE(bits)); The above code fills string "str" with "bit 3 name|bit 5 name". Reviewed-by: Jonathan Cameron Signed-off-by: Mauro Carvalho Chehab Acked-by: Borislav Petkov (AMD) Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

efi/libstub: Fix page table access in 5-level to 4-level paging transition

2025-12-18T12:59:34+00:00

[ Upstream commit 84361123413efc84b06f3441c6c827b95d902732 ] When transitioning from 5-level to 4-level paging, the existing code incorrectly accesses page table entries by directly dereferencing CR3 and applying PAGE_MASK. This approach has several issues: - __native_read_cr3() returns the raw CR3 register value, which on x86_64 includes not just the physical address but also flags Bits above the physical address width of the system (i.e. above __PHYSICAL_MASK_SHIFT) are also not masked. - The pgd value is masked by PAGE_SIZE which doesn't take into account the higher bits such as _PAGE_BIT_NOPTISHADOW. Replace this with proper accessor functions: - native_read_cr3_pa(): Uses CR3_ADDR_MASK to additionally mask metadata out of CR3 (like SME or LAM bits). All remaining bits are real address bits or reserved and must be 0. - mask pgd value with PTE_PFN_MASK instead of PAGE_MASK, accounting for flags above bit 51 (_PAGE_BIT_NOPTISHADOW in particular). Bits below 51, but above the max physical address are reserved and must be 0. Fixes: cb1c9e02b0c1 ("x86/efistub: Perform 4/5 level paging switch from the stub") Reported-by: Michael van der Westhuizen Reported-by: Tobias Fleig Co-developed-by: Kiryl Shutsemau Signed-off-by: Kiryl Shutsemau Signed-off-by: Usama Arif Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20251103141002.2280812-3-usamaarif642@gmail.com Signed-off-by: Sasha Levin

efi: Explain OVMF acronym in OVMF_DEBUG_LOG help text

2025-10-15T10:03:48+00:00

[ Upstream commit 05e75ac35ee9e38f96bbfebf1830ec2cace2e7f8 ] People not very intimate with EFI may not know the meaning of the OVMF acronym. Write it in full, to help users with making good decisions when configuring their kernels. Fixes: f393a761763c5427 ("efi: add ovmf debug log driver") Signed-off-by: Geert Uytterhoeven Reviewed-by: Richard Lyu Acked-by: Gerd Hoffmann Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

efi: stmm: Drop unneeded null pointer check

2025-08-26T12:49:42+00:00

The API documenation of setup_mm_hdr does not mention that dptr can be NULL, this is a local function, and no caller passes NULL. So drop the unneeded check. Signed-off-by: Jan Kiszka Reviewed-by: Ilias Apalodimas Acked-by: Sumit Garg Signed-off-by: Ard Biesheuvel

efi: stmm: Drop unused EFI error from setup_mm_hdr arguments

2025-08-26T12:49:42+00:00

No caller ever evaluates what we return in 'ret'. They only use the return code of the function. Signed-off-by: Jan Kiszka Reviewed-by: Ilias Apalodimas Acked-by: Sumit Garg Signed-off-by: Ard Biesheuvel

efi: stmm: Do not return EFI_OUT_OF_RESOURCES on internal errors

2025-08-26T12:49:42+00:00

When we are low on memory or when the internal API is violated, we cannot return EFI_OUT_OF_RESOURCES. According to the UEFI standard, that error code is either related to persistent storage used for the variable or even not foreseen as possible error (GetVariable e.g.). Use the not fully accurate but compliant error code EFI_DEVICE_ERROR in those cases. Signed-off-by: Jan Kiszka Reviewed-by: Ilias Apalodimas Acked-by: Sumit Garg Signed-off-by: Ard Biesheuvel

efi: stmm: Fix incorrect buffer allocation method

2025-08-26T12:47:53+00:00

The communication buffer allocated by setup_mm_hdr() is later on passed to tee_shm_register_kernel_buf(). The latter expects those buffers to be contiguous pages, but setup_mm_hdr() just uses kmalloc(). That can cause various corruptions or BUGs, specifically since commit 9aec2fb0fd5e ("slab: allocate frozen pages"), though it was broken before as well. Fix this by using alloc_pages_exact() instead of kmalloc(). Fixes: c44b6be62e8d ("efi: Add tee-based EFI variable driver") Signed-off-by: Jan Kiszka Acked-by: Ilias Apalodimas Acked-by: Sumit Garg Signed-off-by: Ard Biesheuvel

Merge tag 'efi-next-for-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi

2025-08-09T15:10:01+00:00

Pull EFI updates from Ard Biesheuvel: - Expose the OVMF firmware debug log via sysfs - Lower the default log level for the EFI stub to avoid corrupting any splash screens with unimportant diagnostic output * tag 'efi-next-for-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: add API doc entry for ovmf_debug_log efistub: Lower default log level efi: add ovmf debug log driver