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

tpm: fix signed/unsigned bug when checking event logs

2024-12-14T18:44:24+00:00

[ Upstream commit e6d654e9f5a97742cfe794b1c4bb5d3fb2d25e98 ]

A prior bugfix that fixes a signed/unsigned error causes
another signed unsigned error.

A situation where log_tbl->size is invalid can cause the
size passed to memblock_reserve to become negative.

log_size from the main event log is an unsigned int, and
the code reduces to the following

u64 value = (int)unsigned_value;

This results in sign extension, and the value sent to
memblock_reserve becomes effectively negative.

Fixes: be59d57f9806 ("efi/tpm: Fix sanity check of unsigned tbl_size being less than zero")
Signed-off-by: Gregory Price 
Reviewed-by: Ilias Apalodimas 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin

efi/tpm: Pass correct address to memblock_reserve

2024-12-14T18:44:24+00:00

[ Upstream commit f4cd18c5b2000df0c382f6530eeca9141ea41faf ]

memblock_reserve() expects a physical address, but the address being
passed for the TPM final events log is what was returned from
early_memremap(). This results in something like the following:

[    0.000000] memblock_reserve: [0xffffffffff2c0000-0xffffffffff2c00e4] efi_tpm_eventlog_init+0x324/0x370

Pass the address from efi like what is done for the TPM events log.

Fixes: c46f3405692d ("tpm: Reserve the TPM final events table")
Cc: Matthew Garrett 
Cc: Jarkko Sakkinen 
Cc: Bartosz Szczepanek 
Cc: Ard Biesheuvel 
Signed-off-by: Jerry Snitselaar 
Acked-by: Jarkko Sakkinen 
Signed-off-by: Ard Biesheuvel 
Stable-dep-of: e6d654e9f5a9 ("tpm: fix signed/unsigned bug when checking event logs")
Signed-off-by: Sasha Levin

efivarfs: Request at most 512 bytes for variable names

2024-04-13T10:51:31+00:00

commit f45812cc23fb74bef62d4eb8a69fe7218f4b9f2a upstream.

Work around a quirk in a few old (2011-ish) UEFI implementations, where
a call to `GetNextVariableName` with a buffer size larger than 512 bytes
will always return EFI_INVALID_PARAMETER.

There is some lore around EFI variable names being up to 1024 bytes in
size, but this has no basis in the UEFI specification, and the upper
bounds are typically platform specific, and apply to the entire variable
(name plus payload).

Given that Linux does not permit creating files with names longer than
NAME_MAX (255) bytes, 512 bytes (== 256 UTF-16 characters) is a
reasonable limit.

Cc:  # 6.1+
Signed-off-by: Tim Schumacher 
Signed-off-by: Ard Biesheuvel 
[timschumi@gmx.de: adjusted diff for changed context and code move]
Signed-off-by: Tim Schumacher 
Signed-off-by: Greg Kroah-Hartman

efi/capsule-loader: fix incorrect allocation size

2024-03-06T14:36:09+00:00

[ Upstream commit fccfa646ef3628097d59f7d9c1a3e84d4b6bb45e ]

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 
Signed-off-by: Sasha Levin

efi: Accept version 2 of memory attributes table

2023-02-22T11:50:27+00:00

commit 636ab417a7aec4ee993916e688eb5c5977570836 upstream.

UEFI v2.10 introduces version 2 of the memory attributes table, which
turns the reserved field into a flags field, but is compatible with
version 1 in all other respects. So let's not complain about version 2
if we encounter it.

Cc: 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

efi: fix potential NULL deref in efi_mem_reserve_persistent

2023-02-22T11:50:25+00:00

[ Upstream commit 966d47e1f27c45507c5df82b2a2157e5a4fd3909 ]

When iterating on a linked list, a result of memremap is dereferenced
without checking it for NULL.

This patch adds a check that falls back on allocating a new page in
case memremap doesn't succeed.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: 18df7577adae ("efi/memreserve: deal with memreserve entries in unmapped memory")
Signed-off-by: Anton Gusev 
[ardb: return -ENOMEM instead of breaking out of the loop]
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin

efi: fix userspace infinite retry read efivars after EFI runtime services page fault

2023-01-24T06:17:59+00:00

[ Upstream commit e006ac3003080177cf0b673441a4241f77aaecce ]

After [1][2], if we catch exceptions due to EFI runtime service, we will
clear EFI_RUNTIME_SERVICES bit to disable EFI runtime service, then the
subsequent routine which invoke the EFI runtime service should fail.

But the userspace cat efivars through /sys/firmware/efi/efivars/ will stuck
and infinite loop calling read() due to efivarfs_file_read() return -EINTR.

The -EINTR is converted from EFI_ABORTED by efi_status_to_err(), and is
an improper return value in this situation, so let virt_efi_xxx() return
EFI_DEVICE_ERROR and converted to -EIO to invoker.

Cc: 
Fixes: 3425d934fc03 ("efi/x86: Handle page faults occurring while running EFI runtime services")
Fixes: 23715a26c8d8 ("arm64: efi: Recover from synchronous exceptions occurring in firmware")
Signed-off-by: Ding Hui 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin

efi: fix NULL-deref in init error path

2023-01-18T10:42:06+00:00

[ Upstream commit 703c13fe3c9af557d312f5895ed6a5fda2711104 ]

In cases where runtime services are not supported or have been disabled,
the runtime services workqueue will never have been allocated.

Do not try to destroy the workqueue unconditionally in the unlikely
event that EFI initialisation fails to avoid dereferencing a NULL
pointer.

Fixes: 98086df8b70c ("efi: add missed destroy_workqueue when efisubsys_init fails")
Cc: stable@vger.kernel.org
Cc: Li Heng 
Signed-off-by: Johan Hovold 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin

efi: random: reduce seed size to 32 bytes

2022-11-10T16:57:55+00:00

commit 161a438d730dade2ba2b1bf8785f0759aba4ca5f upstream.

We no longer need at least 64 bytes of random seed to permit the early
crng init to complete. The RNG is now based on Blake2s, so reduce the
EFI seed size to the Blake2s hash size, which is sufficient for our
purposes.

While at it, drop the READ_ONCE(), which was supposed to prevent size
from being evaluated after seed was unmapped. However, this cannot
actually happen, so READ_ONCE() is unnecessary here.

Cc:  # v4.14+
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jason A. Donenfeld 
Acked-by: Ilias Apalodimas 
Signed-off-by: Greg Kroah-Hartman

efi: libstub: drop pointless get_memory_map() call

2022-10-26T11:23:00+00:00

commit d80ca810f096ff66f451e7a3ed2f0cd9ef1ff519 upstream.

Currently, the non-x86 stub code calls get_memory_map() redundantly,
given that the data it returns is never used anywhere. So drop the call.

Cc:  # v4.14+
Fixes: 24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping size")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman