Commit graph

5 commits

Author SHA1 Message Date
Jan Kiszka
134ed10939 efi: stmm: Drop unneeded null pointer check
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 <jan.kiszka@siemens.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-08-26 14:49:42 +02:00
Jan Kiszka
01a3044af5 efi: stmm: Drop unused EFI error from setup_mm_hdr arguments
No caller ever evaluates what we return in 'ret'. They only use the
return code of the function.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-08-26 14:49:42 +02:00
Jan Kiszka
80c6c10486 efi: stmm: Do not return EFI_OUT_OF_RESOURCES on internal errors
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 <jan.kiszka@siemens.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-08-26 14:49:42 +02:00
Jan Kiszka
c5e81e6726 efi: stmm: Fix incorrect buffer allocation method
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 9aec2fb0fd
("slab: allocate frozen pages"), though it was broken before as well.

Fix this by using alloc_pages_exact() instead of kmalloc().

Fixes: c44b6be62e ("efi: Add tee-based EFI variable driver")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-08-26 14:47:53 +02:00
Masahisa Kojima
c44b6be62e efi: Add tee-based EFI variable driver
When the flash is not owned by the non-secure world, accessing the EFI
variables is straight-forward and done via EFI Runtime Variable
Services.  In this case, critical variables for system integrity and
security are normally stored in the dedicated secure storage and can
only be manipulated directly from the secure world.

Usually, small embedded devices don't have the special dedicated secure
storage. 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 our
case). There is an existing solution utilizing eMMC RPMB partition for
EFI Variables, it is implemented by interacting with TEE (OP-TEE in this
case), StandaloneMM (as EFI Variable Service Pseudo TA), eMMC driver and
tee-supplicant. The last piece is the tee-based variable access driver
to interact with TEE and StandaloneMM.

So let's add the kernel functions needed.

This feature is implemented as a kernel module.  StMM PTA has
TA_FLAG_DEVICE_ENUM_SUPP flag when registered to OP-TEE so that this
tee_stmm_efi module is probed after tee-supplicant starts, since
"SetVariable" EFI Runtime Variable Service requires to interact with
tee-supplicant.

Acked-by: Sumit Garg <sumit.garg@linaro.org>
Co-developed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2023-12-11 11:19:18 +01:00