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