On 31/05/2019 13:20, Sumit Garg wrote: > On Fri, 31 May 2019 at 17:33, Grant Likely <[email protected]> wrote: >> >> >> >> On 27/05/2019 10:05, Ilias Apalodimas wrote: >>> Hi Udit, >>>> Hi Ilias >>>> >>>>> -----Original Message----- >>>>> From: Ilias Apalodimas <[email protected]> >>>>> Sent: Friday, May 24, 2019 9:57 PM >>>>> To: Udit Kumar <[email protected]> >>>>> Cc: [email protected]; Varun Sethi <[email protected]> >>>>> Subject: Re: [EXT] Securing the boot flow in U-Boot >>>>> >>>>> Caution: EXT Email >>>>> >>>>> Hi Udit, >>>>>>> >>>>>>> What do you think? >>>>>> >>>>>> Here we are talking about image signing and image validation. >>>>>> I am not sure, what are your plan to make keys data base (platform >>>>>> key, KeK and DBs) secure while writing. >>>>>> AFAIU, This is one of requirement of secure uefi that these secure >>>>>> variable >>>>> should be written in MM mode. >>>>> The plan on that is run stMM as an OP-TEE TA. >>>>> This will allow us to run StMM + fTPM simultaneously. >>>>> The current plan is to support UEFI specs on U-Boot without having secure >>>>> variable storage. That one is our next step. >>>> >>>> May be I am asking too early about your next step >>> Indeed :) >>> We'll try to have the UEFI secure boot spec in u-boot first, *without* >>> storing >>> the variables in a secure storage. Once we complete this we can start >>> planning >>> the secure part of the varibles. >>> >>> A bit of history on this. One of the things we are going to try is split >>> U-Boot ENV and UEFI variables. By decoupling those, storing the variables >>> in a >>> different storage should be straightforward (or at least a lot easier than >>> it >>> is today). >>>> Where you see flash driver sitting, >>>> Possible options I see, >>>> 1/ In OP-TEE and StMM is making sys-call to access it >>>> 2/ in TFA (EL3) itself and stMM is making smc calls >>>> 3/ OP-TEE is doing sort of mmap to flash controller area and driver is >>>> residing in Sec-EL0 itself >>> All three sound valid. This also depends on the hardware design as well. >>> This is >>> too soon for us, if anyone else has any suggestions it might be a good idea >>> to >>> sum those up in a new thread? >> >> On systems with normal-world mapped eMMC/UFS with RPMB: Option 1 >> - trusted app needs to coordinate with normal world firmware & OS >> - The trusted app will prepare and sign RPMB update transactions and >> depend on a supplicant in the normal world to perform the transaction. >> U-Boot will need an implementation of the optee supplicant. > > Just an update, U-Boot already have optee supplicant support for RPMB > storage access. Have a look here [1]. > > [1] https://github.com/u-boot/u-boot/blob/master/drivers/tee/optee/rpmb.c
Even better! Thanks! g. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
