Hi Alex, On Fri, Jun 2, 2023 at 10:26 AM Ilias Apalodimas <ilias.apalodimas@xxxxxxxxxx> wrote: > > On Thu, 1 Jun 2023 at 08:49, Sumit Garg <sumit.garg@xxxxxxxxxx> wrote: > > > > On Thu, 1 Jun 2023 at 11:02, Ilias Apalodimas > > <ilias.apalodimas@xxxxxxxxxx> wrote: > > > > > > Hi Bing > > > > > > On Thu, 1 Jun 2023 at 04:03, Zhu, Bing <bing.zhu@xxxxxxxxx> wrote: > > > > > > > > As an alternative, Is it possible to change ftpm design not to depend on RPMB access at the earlier/boot stage? Because to my understanding, typically PCRs don't require persistent/NV storage (for example, before RPMB or tee-supplicant is ready, use TEE memory instead as temporary storage) > > > > > > I am not entirely sure this will solve our problem here. You are > > > right that we shouldn't depend on the supplicant to extend PCRs. But > > > what happens if an object is sealed against certain PCR values? We > > > are back to the same problem > > > > +1 > > > > Temporary storage may be a stop gap solution for some use-cases but > > having a fast path access to RPMB via kernel should be our final goal. > > I would suggest we start small with the MMC subsystem to expose RPMB > > access APIs for OP-TEE driver rather than a complete RPMB subsystem. > > I discussed with the OP-TEE maintainers about adding parts of the > supplicant in the kernel. The supplicant 'just' sends an ioctl to > store/read stuff anyway. So it would make sense to have a closer and > see if that looks reasonable. > Thanks I was trying to create a setup to test this. I've added the kernel patches on top of https://github.com/linaro-swg/linux/tree/optee. The QEMU branch is a bit dated and I had to add 3a845a214b42 target/arm: allow setting SCR_EL3.EnTP2 when FEAT_SME is implemented d4a7b0ef1a03 hw/arm/boot: set CPTR_EL3.ESM and SCR_EL3.EnTP2 when booting Linux with EL3 9745a003f878 hw/intc/arm_gicv3: fix prio masking on pmr write beeec926d24a target/arm: mark SP_EL1 with ARM_CP_EL3_NO_EL2_KEEP on top of that branch to be able to boot to the Linux kernel. I have the vhost-user-rpmb process running and connected with QEMU, but around (guessing really) when the RPMB subsystem is initializing the process dies with: ================ Vhost user message ================ Request: VHOST_USER_SET_VRING_ADDR (9) Flags: 0x1 Size: 40 vhost-user-rpmb-INFO: 18:58:08.312: vrpmb_process_msg: msg VHOST_USER_SET_VRING_ADDR(9) vhost_vring_addr: index: 0 flags: 0 desc_user_addr: 0x00007ff15fa91000 used_user_addr: 0x00007ff15fa91080 avail_user_addr: 0x00007ff15fa91040 log_guest_addr: 0x0000000041c91080 Setting virtq addresses: vring_desc at (nil) vring_used at (nil) vring_avail at (nil) (vhost-user-rpmb:3236474): vhost-user-rpmb-CRITICAL **: 18:58:08.312: Invalid vring_addr message Among other options, I'm starting QEMU with -machine virt,secure=on,mte=off,gic-version=3,virtualization=false to enable the secure world. Do you have an idea of what might be wrong? Where should I start looking? Thanks, Jens > > /Ilias > > > > > -Sumit > > > > > > > > Thanks > > > /Ilias > > > > > > > > Bing > > > > > > > > IPAS Security Brown Belt (https://www.credly.com/badges/69ea809f-3a96-4bc7-bb2f-442c1b17af26) > > > > System Software Engineering > > > > Software and Advanced Technology Group > > > > Zizhu Science Park, Shanghai, China > > > > > > > > -----Original Message----- > > > > From: Shyam Saini <shyamsaini@xxxxxxxxxxxxxxxxxxx> > > > > Sent: Thursday, June 1, 2023 3:10 AM > > > > To: alex.bennee@xxxxxxxxxx > > > > Cc: code@xxxxxxxxxxx; Matti.Moell@xxxxxxxxxxxxxxx; arnd@xxxxxxxxxx; Zhu, Bing <bing.zhu@xxxxxxxxx>; hmo@xxxxxxxxxxxxxxx; ilias.apalodimas@xxxxxxxxxx; joakim.bech@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-mmc@xxxxxxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx; maxim.uvarov@xxxxxxxxxx; ruchika.gupta@xxxxxxxxxx; Winkler, Tomas <tomas.winkler@xxxxxxxxx>; ulf.hansson@xxxxxxxxxx; Huang, Yang <yang.huang@xxxxxxxxx>; sumit.garg@xxxxxxxxxx; jens.wiklander@xxxxxxxxxx; op-tee@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > Subject: [PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver > > > > > > > > Hi Alex, > > > > > > > > [ Resending, Sorry for the noise ] > > > > > > > > Are you still working on it or planning to resubmit it ? > > > > > > > > [1] The current optee tee kernel driver implementation doesn't work when IMA is used with optee implemented ftpm. > > > > > > > > The ftpm has dependency on tee-supplicant which comes once the user space is up and running and IMA attestation happens at boot time and it requires to extend ftpm PCRs. > > > > > > > > But IMA can't use PCRs if ftpm use secure emmc RPMB partition. As optee can only access RPMB via tee-supplicant(user space). So, there should be a fast path to allow optee os to access the RPMB parititon without waiting for user-space tee supplicant. > > > > > > > > To achieve this fast path linux optee driver and mmc driver needs some work and finally it will need RPMB driver which you posted. > > > > > > > > Please let me know what's your plan on this. > > > > > > > > [1] https://optee.readthedocs.io/en/latest/architecture/secure_storage.html > > > > > > > > Best Regards, > > > > Shyam
