On Wed, 7 Feb 2024 at 08:11, Sumit Garg <sumit.garg@xxxxxxxxxx> wrote: > > Hi Ilias, Ulf, > > On Tue, 6 Feb 2024 at 20:41, Ilias Apalodimas > <ilias.apalodimas@xxxxxxxxxx> wrote: > > > > Hi Ulf, > > > > On Tue, 6 Feb 2024 at 14:34, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > > > > > On Wed, 31 Jan 2024 at 18:44, Jens Wiklander <jens.wiklander@xxxxxxxxxx> wrote: > > > > > > > > A number of storage technologies support a specialised hardware > > > > partition designed to be resistant to replay attacks. The underlying > > > > HW protocols differ but the operations are common. The RPMB partition > > > > cannot be accessed via standard block layer, but by a set of specific > > > > RPMB commands: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. Such a > > > > partition provides authenticated and replay protected access, hence > > > > suitable as a secure storage. > > > > > > > > The initial aim of this patch is to provide a simple RPMB Driver which > > > > can be accessed by the optee driver to facilitate early RPMB access to > > > > OP-TEE OS (secure OS) during the boot time. > > > > > > How early do we expect OP-TEE to need RPMB access? > > > > It depends on the requested services. I am currently aware of 2 > > services that depend on the RPMB > > - FirmwareTPM > > - UEFI variables stored there via optee. > > > > For the FirmwareTPM it depends on when you want to use it. This > > typically happens when the initramfs is loaded or systemd requests > > access to the TPM. I guess this is late enough to not cause problems? > > Actually RPMB access is done as early as during fTPM probe, probably > to cache NVRAM from RPMB during fTPM init. Also, there is a kernel > user being IMA which would require fTPM access too. So we really need > to manage dependencies here. Ah true. I was wrongly assuming loading is a module and having systemd or something similar handling that dependency. But in case this is built-in we do need to handle that internally. > > > > > For the latter, we won't need the supplicant until a write is > > requested. This will only happen once the userspace is up and running. > > The UEFI driver that sits behind OP-TEE has an in-memory cache of the > > variables, so all the reads (the kernel invokes get_next_variable > > during boot) are working without it. > > > > Thanks > > /Ilias > > > > > > The way things work for mmc today, is that the eMMC card gets > > > discovered/probed via a workqueue. The work is punted by the mmc host > > > driver (typically a module-platform-driver), when it has probed > > > successfully. > > It would be nice if RPMB is available as early as possible but for the > time being we can try to see if probe deferral suffices for all > use-cases. > > > > > > > The point is, it looks like we need some kind of probe deferral > > > mechanism too. Whether we want the OP-TEE driver to manage this itself > > > or whether we should let rpmb_dev_find_device() deal with it, I don't > > > know. > > I wouldn't like to see the OP-TEE driver probe being deferred due to > this since there are other kernel drivers like OP-TEE RNG (should be > available as early as we can) etc. which don't have any dependency on > RPMB. > > How about for the time being we defer fTPM probe until RPMB is available? > > -Sumit
