Hi Grant, On Fri, May 31, 2019 at 12:03:42PM +0000, Grant Likely 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. Linux > already has one. > We've in fact upstreamed support for an OP-TEE "supplicant" (with RPMB support) to U-Boot not that long ago. So we can tick this one off from the todo list. How to enable RPMB with OP-TEE in U-Boot can be seen section 4 here: https://github.com/u-boot/u-boot/blob/master/doc/README.avb2
> On systems with secure-world mapped secure storage: Option 3 > - The trusted app doesn't need to coordinate with the normal world. > - It can directly write to storage. > > Option 2 is not an option because we don't want device drivers (ie, for > secure storage devices) in EL3 TFA. It is supposed to be as small as > possible. > > g. > _______________________________________________ > boot-architecture mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/boot-architecture -- Regards, Joakim _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
