On Wed, 13 Jul 2022 at 06:34, Julius Werner jwerner@chromium.org wrote:
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.
Yes, absolutely, the config option for this should come with explicit warnings about the security implications.
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.
I think compile-time configuration options are probably the best way to differentiate this. I don't know what the exact best approach for combining this with some sort of verification option is -- I think that could be either platform-specific or it could be some generic mechanism. That would be easiest to decide once someone actually has a use case for that, so I'd say we just implement the base functionality needed for our use case for now and then whenever the next use case with different requirements comes up we can decide how to best extend it to allow for that.
I disagree here. We shouldn't forget that TF-A is a reference implementation and should recommend best security practices. Although in the end it's the platform owners to decide which ones to implement or not describing their threat model considerations. Also, we shouldn't turn generic code into platform specific code using #ifdefry which is quite hard to parse and IIRC, it's a common practice in TF-A to use platform specific hooks.
-Sumit