Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

[Manuel Traut]

Hi Mikko,

On 10:09 Wed 29 May     , Mikko Rapeli wrote:
> On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote:
> > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <mikko.rapeli@xxxxxxxxxx> wrote:
> > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote:
> > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier
> > > > <jerome.forissier@xxxxxxxxxx> wrote:
> > > > > On 5/27/24 14:13, Jens Wiklander wrote:
> > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which
> > > currently requires tee-supplicant to be started. Detecting the existence of TPM before
> > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel
> > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too.
> > 
> > One thing I am trying to find an answer about is why do we need to
> > defer tee-supplicant launch if it's bundled into initrd? Once you
> > detect OP-TEE then tee-supplicant should be launched unconditionally.
> > As per your example below, the motivation here seems to be the TPM2
> > device dependent on RPMB backend but what if other future systemd
> > services come up and depend on other services offered by
> > tee-supplicant?
> 
> There is an annoying depedency between firmware side optee and TAs, and kernel optee driver,
> tee-supplicant in userspace and kernel TA drivers like fTPM.
> 
> Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc.
> 
> This patch series is adding kernel side support for RPMB handling so that the dependency to
> tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC
> buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic.
> 
> So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers
> and firmware optee trusted applications would not depend on tee-supplicant running in userspace.
> The startup sequence is really tricky to get right. My fTPM use case is using the TPM device
> to encrypt rootfs and thus all SW components including tee-supplicant need to run early in
> initramfs. Currently also switch from initramfs to main rootfs requires unloading
> fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant
> and loading fTPM kernel driver from main rootfs. udev and automatic module loading for
> fTPM can not be used due to the tee-supplicant userspace dependency.

I decided to build fTPM as buildin-TA into OP-TEE. RPMB routing is already
implemented in u-boot so it can already write PCR registers.

With this series and the required changes in OP-TEE and a compiled in fTPM
kernel driver and systemd v256 it is possible to use the fTPM in the initrd
without tee-supplicant.

Maybe this information is helpful to you, regards
Manuel