Re: [PATCH v5 3/3] efi: Add tee-based EFI variable driver

On Tue, 6 Jun 2023 at 12:28, Ard Biesheuvel [off-list ref] wrote:

On Tue, 6 Jun 2023 at 08:52, Sumit Garg [off-list ref] wrote:

quoted

Hi Jan,

On Tue, 6 Jun 2023 at 12:09, Jan Kiszka [off-list ref] wrote:

quoted

On 26.05.23 03:07, Masahisa Kojima wrote:

quoted

When the flash is not owned by the non-secure world, accessing the EFI
variables is straightforward 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 only accessible
from the secure world.

On the other hand, the small embedded devices don't have the special
dedicated secure storage. The eMMC device with an RPMB partition is
becoming more common, we can use an RPMB partition to store the
EFI Variables.

The eMMC device is typically owned by the non-secure world(linux in
this 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 <redacted>
Co-developed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Masahisa Kojima <redacted>
---
 drivers/firmware/efi/Kconfig                 |  15 +
 drivers/firmware/efi/Makefile                |   1 +
 drivers/firmware/efi/stmm/mm_communication.h | 236 +++++++
 drivers/firmware/efi/stmm/tee_stmm_efi.c     | 638 +++++++++++++++++++
 4 files changed, 890 insertions(+)
 create mode 100644 drivers/firmware/efi/stmm/mm_communication.h
 create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c

...

quoted

quoted

I think we have a probe ordering issue with this driver:
efivarfs_fill_super() may be called before the TEE bus was probed, thus
with the default efivar ops still registered. And that means
efivar_supports_writes() will return false, and the fs declares itself
as readonly. I've seen systemd mounting it r/o initialling, and you need
to remount the fs to enable writability.

Is there anything that could be done to re-order things reliably, probe
the tee bus earlier etc.?

This driver has a dependency on user-space daemon: tee-supplicant to
be running for RPMB access. So once you start that daemon the
corresponding device will be enumerated on the TEE bus and this driver
probe will be invoked. So I would suggest you to load this daemon very
early in the boot process or better to make it a part of initramfs.

That is not the point, really.

If this dependency exists, the code should be aware of that, and made
to work correctly in spite of it. Requiring a module to be part of
initramfs is not a reasonable fix.

I am not sure if I followed you here. Until we have the tee-stmm-efi
module loaded we won't get corresponding EFI operations registered.
The key here is that the underlying OP-TEE device won't be available
until tee-supplicant (see enumeration with PTA_CMD_GET_DEVICES_SUPP)
is running.

Do you have any better ideas regarding how this should be handled?

IIUC, this also means that the efivar ops are updated while there is
already a client. This seems less than ideal as well

That's true. An ideal situation would be to allow in-kernel RPMB
access APIs for OP-TEE or other kernel drivers to use. With that we
should be able to remove this tee-supplicant dependency. I hope you
are already aware about the earlier efforts to add the RPMB subsystem
to the kernel. But with these real world use-cases emerging like EFI
variables and fTPM, we should be able to convince corresponding
subsystem maintainers.

-Sumit

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel