On Tue, 12 Jul 2022 at 04:48, Julius Werner jwerner@chromium.org wrote:
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.
I am unsure about how we are going to sustain a default threat model along with platform specific threat models overriding it. Although I agree that in the end it's the platform owner who decides their own threat model. So probably a security disclaimer print like what we have in OP-TEE [1] makes sense for TF-A as well so that silicon vendors/OEMs are aware of security guarantees.
[1] https://github.com/OP-TEE/optee_os/blob/master/mk/config.mk#L798
Okay, thank you, sounds like we're basically on the same page to go ahead with this plan in principle then?
I will leave this decision with TF-A maintainers (you are one of them :)).
I absolutely understand that it's important that we need to strictly separate this code path from configurations that don't enable it and make sure it doesn't weaken security guarantees on any platforms that depend on the secure world not trusting the normal world at any point. We'll absolutely keep that in mind during development and will gladly take any suggestions to make that separation more strict and fool-proof in the code (this is probably easier to evaluate once we have a prototype implementation to look at).
I can't think of a way that this solution can work without platform specific hooks in the generic code. So if we are going ahead with this approach then I would suggest adding a platform specific S-EL1 authentication hook as well which you can define as a dummy describing the threat model consideration for your platform.
-Sumit
I understand that too many configuration options can be a maintenance burden, but at the same time we appreciate you allowing for this flexibility where it is needed. We will of course sign up to keep maintaining this code we contribute upstream and deal with any issues or forward-porting needs that come up with it in the future (this is something we plan to use long-term on all our future platforms, we won't just drop it in the repo and walk away).