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. 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
