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 -Sumit > Linux > already has one. > > 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 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
