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.
Okay, thank you, sounds like we're basically on the same page to go ahead with this plan in principle then? 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 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).