linux-stable.git/drivers/firmware/efi, branch v6.8

efi/capsule-loader: fix incorrect allocation size

2024-02-13T15:30:07+00:00

gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures
is not enough for a 64-bit phys_addr_t:

drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open':
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size]
  295 |         cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL);
      |                        ^

Use the correct type instead here.

Fixes: f24c4d478013 ("efi/capsule-loader: Reinstate virtual capsule mapping")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ard Biesheuvel

cxl/cper: Fix errant CPER prints for CXL events

2024-02-03T17:31:17+00:00

Jonathan reports that CXL CPER events dump an extra generic error
message.

	{1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
	{1}[Hardware Error]: event severity: recoverable
	{1}[Hardware Error]:  Error 0, type: recoverable
	{1}[Hardware Error]:   section type: unknown, fbcd0a77-c260-417f-85a9-088b1621eba6
	{1}[Hardware Error]:   section length: 0x90
	{1}[Hardware Error]:   00000000: 00000090 00000007 00000000 0d938086 ................
	{1}[Hardware Error]:   00000010: 00100000 00000000 00040000 00000000 ................
	...

CXL events were rerouted though the CXL subsystem for additional
processing.  However, when that work was done it was missed that
cper_estatus_print_section() continued with a generic error message
which is confusing.

Teach CPER print code to ignore printing details of some section types.
Assign the CXL event GUIDs to this set to prevent confusing unknown
prints.

Reported-by: Jonathan Cameron 
Suggested-by: Jonathan Cameron 
Signed-off-by: Ira Weiny 
Reviewed-by: Dave Jiang 
Reviewed-by: Jonathan Cameron 
Reviewed-by: Alison Schofield 
Signed-off-by: Ard Biesheuvel

efi: Don't add memblocks for soft-reserved memory

2024-02-02T18:31:24+00:00

Adding memblocks for soft-reserved regions prevents them from later being
hotplugged in by dax_kmem.

Signed-off-by: Andrew Bresticker 
Signed-off-by: Ard Biesheuvel

efi: runtime: Fix potential overflow of soft-reserved region size

2024-02-02T18:31:24+00:00

md_size will have been narrowed if we have >= 4GB worth of pages in a
soft-reserved region.

Signed-off-by: Andrew Bresticker 
Signed-off-by: Ard Biesheuvel

efi/libstub: Add one kernel-doc comment

2024-01-30T20:44:21+00:00

Add the description of @memory_type to silence the warning:
drivers/firmware/efi/libstub/alignedmem.c:27: warning: Function parameter or struct member 'memory_type' not described in 'efi_allocate_pages_aligned'

Signed-off-by: Yang Li 
[ardb: tweak comment]
Signed-off-by: Ard Biesheuvel

x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR

2024-01-30T20:44:21+00:00

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 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218404
Signed-off-by: Ard Biesheuvel

x86/efistub: Give up if memory attribute protocol returns an error

2024-01-26T15:58:19+00:00

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

riscv/efistub: Tighten ELF relocation check

2024-01-23T13:31:33+00:00

The EFI stub makefile contains logic to ensure that the objects that
make up the stub do not contain relocations that require runtime fixups
(typically to account for the runtime load address of the executable)

On RISC-V, we also avoid GP based relocations, as they require that GP
is assigned the correct base in the startup code, which is not
implemented in the EFI stub.

So add these relocation types to the grep expression that is used to
carry out this check.

Link: https://lkml.kernel.org/r/42c63cb9-87d0-49db-9af8-95771b186684%40siemens.com
Signed-off-by: Ard Biesheuvel

riscv/efistub: Ensure GP-relative addressing is not used

2024-01-23T13:31:32+00:00

The cflags for the RISC-V efistub were missing -mno-relax, thus were
under the risk that the compiler could use GP-relative addressing. That
happened for _edata with binutils-2.41 and kernel 6.1, causing the
relocation to fail due to an invalid kernel_size in handle_kernel_image.
It was not yet observed with newer versions, but that may just be luck.

Cc: 
Signed-off-by: Jan Kiszka 
Signed-off-by: Ard Biesheuvel

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

2024-01-10T01:11:27+00:00

Pull EFI updates from Ard Biesheuvel:

 - Fix a syzbot reported issue in efivarfs where concurrent accesses to
   the file system resulted in list corruption

 - Add support for accessing EFI variables via the TEE subsystem (and a
   trusted application in the secure world) instead of via EFI runtime
   firmware running in the OS's execution context

 - Avoid linker tricks to discover the image base on LoongArch

* tag 'efi-next-for-v6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
  efi: memmap: fix kernel-doc warnings
  efi/loongarch: Directly position the loaded image file
  efivarfs: automatically update super block flag
  efi: Add tee-based EFI variable driver
  efi: Add EFI_ACCESS_DENIED status code
  efi: expose efivar generic ops register function
  efivarfs: Move efivarfs list into superblock s_fs_info
  efivarfs: Free s_fs_info on unmount
  efivarfs: Move efivar availability check into FS context init
  efivarfs: force RO when remounting if SetVariable is not supported