Hi Grant, > Hi Ilias, > > > On 26 Apr 2019, at 06:56, Ilias Apalodimas <[email protected]> > > wrote: > > > > Hi all, > > > > This started as an internal discussion for U-Booa and SSL which quickly span > > out of control, so the mailing list is a better suited place for this > > discussion. > > > > Akashi-san had an interesting idea. Since we will try to implement > > StandaloneMM > > as an OP-TEE TA, why not add payload authentication capabilities on it. > > Since it's already doing variable authentication on the secure side, the > > needed > > changes would be minimal (at least that's what i think, please correct me > > if i > > am wrong), since most of the code should already be there. > > > > This means that the payload authentication will be moved to the secure > > world. > > Although doing the authentication in secure world won't offer any security > > enhancements, the common code across firmware implementations is probably > > nice > > to have. > > So, as discussed on the private thread, I do not think this is a good idea. > The main reasons to use StandaloneMM are to protect secrets (private keys) or > to protect storage against unauthorised writes (protect against reset or > rollback). When it come to firmware image updates and secure variable > changes, using StandaloneMM makes sense. > > However, image authentication doesn’t involve access to any secrets. Nor does > it change any secure variables. Moving image authentication into the secure > world increases complexity without any additional security benefit, and it > precludes any secure boot implementations when StandaloneMM is not available. > I don't have any strong opinion for this either.
To be honest i can live with StandaloneMM used for this, although as you pointed out crosses the boundary of the it's current functionality. The reason is, i like the common abstraction for firmware implementation on these kind of things. That being said i think imposing a limitation on who can run a 'secure boot' by moving the authentication in the secure world is a no-go. It will probably produce more fragmentation than the one we are trying to fix :) > I’d rather see Secure Boot image authentication implemented generically for > all u-boot platforms, even when secure world variable updates are not > available. Akashi and Sughosh already have code on that. It's not 100% complete or tested yet, but the basic concept works. That's how this dicussion came up. Since that's ready we tried to consider how to properly add the proper functions in U-Boot (for image authentication) and considered the secure-world option. P.S: i'd still like to hear arguments if someone thinks this should happen Thanks /Ilias _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
