Hi Julius
-----Original Message----- From: Julius Werner jwerner@chromium.org Sent: 07 July 2022 02:58
Hi Dan, Sumit,
Just to be clear, we're not proposing any generic new method of S-EL1 loading that we expect to garner widespread adoption across the TF-A ecosystem. We're intending to provide a secondary option that can be compiled in by platforms and systems for which this may be specifically beneficial and where this can be reconciled with the platform-specific threat model. We understand that there are many benefits of loading S-EL1 at BL31 load time, and that for the majority of platforms this is the best choice -- but there are also benefits of the runtime-loaded model that we propose (e.g. firmware size constraints, decoupling S-EL1 update process from firmware update process), and there are ways to mitigate potential disadvantages, which ultimately made us decide that this would be the best path for our platform.
OK, that all sounds good to me.
At the end of the day, TF-A (and the whole concept of a Secure World execution environment) is a framework that provides the platform implementer options to execute things in a certain way and gain certain security guarantees that way -- it is always up to the platform to decide what exactly to do with it and what exact guarantees it actually needs.
+1 so far.
I don't think it makes sense at a TF-A level to say "the system automatically becomes insecure the moment you start executing Linux and there is no point in even still having a TEE anymore if you trust that" (TF-A doesn't even know whether we're running Linux or some other OS, after all, or how we configure it, or what we're even trying to protect in our TEE). Different platforms have different threats they want to protect against, and for many threats it can be possible to boot a kernel but still not open any attack surfaces until after the point where this S-EL1 loading SMC would have occurred. Ultimately, only the platform implementer can really decide what exactly they need and what's the best way to achieve that -- all we're asking for here is that we may implement the option to do it this way, to be selected by the platform at compile time, in a way that it need not have any effect on platforms that don't make this choice.
The default threat model of TF-A is to not trust the normal world in any way, and lot of the functionality there is written with that in mind (e.g. parameter sanitization, image authentication, interrupt prioritization/masking, etc...). I agree TF-A should be able to support all platforms that may have different threat models, as long as that support doesn't erode the default threat model in generic code.
Also, please remember (particularly regarding things like FIP or FF-A APIs) that the full-featured TF-A end-to-end firmware stack is not the only configuration in which people use TF-A, and that some platforms (like ours) only use a smaller subset of components with somewhat different use cases. Therefore I think TF-A should generally try to follow a "toolkit" kind of approach where it offers a variety of options and different ways to do things that platforms can pick and choose from according to their specific needs, rather than forcing everyone into a one-size-fits-all approach. We have had these sorts of situations in the past as well (e.g. with the device tree vs. bl_aux_params discussion) and as of yet we've always been able to find a solution that allows all platforms to work with something that suits their specific use case -- I hope we can achieve that here as well. (And of course none of the work we're proposing should preclude anyone else from later using the same S-EL1 runtime loading together with some sort of verification step inside EL3, or delegated to a resident BL2. It would totally make sense to expand the system with those options if that would be the preferable solution for another platform. We're just saying that we want the option to disable that verification step for our use case where we are certain that our existing OS verification mechanism already covers everything that our threat model cares about.)
+1 to all this. I think TF-A has done a good job of supporting many different configs to date. Actually, I'd say the danger for TF-A, given the age of the project, the number of different architecture versions it supports and the number of different config options, is maintaining the very large config space. We may need to start thinking about how we can constrain this to the systems/platforms that use TF-A in practice, e.g. maybe by introducing config profiles. However, that is a subject for another thread.
Regards
Dan.