Le ven. 1 juil. 2022 à 09:19, Sumit Garg via TF-A < tf-a@lists.trustedfirmware.org> a écrit :

Hi Jeffrey,

On Fri, 1 Jul 2022 at 04:33, Jeffrey Kardatzke via TF-A tf-a@lists.trustedfirmware.org wrote:

...

Hello,

I'm working on a project for ChromeOS where we would like to be able to

load the BL32 payload (OpTee) for SEL-1 after the linux kernel has booted rather than during the usual BL32 stage. We would do this via an SMC we would add which would take the OpTee image from linux and then have EL3 load it and perform the init for SEL-1 at that time.

...

The reasoning behind this is that it's much easier to update the rootfs

than the FW on our devices, and we can still ensure the integrity of the OpTee image if we load it early enough after the kernel boots.

It looks like an interesting motivation but I would like to hear about the real world use-cases that you are trying to address. Surely, you are not going to have any boot time services from OP-TEE in this case.

...

The main questions I have are if there are any issues people would be

aware of by loading it after linux boots rather than during the usual BL32 stage?

My major concern here is the authentication of the BL32 payload. Especially for pre-Armv8.4 systems where BL32 payload running in S-EL1 has a maximum level of system privileges. So you need to have a similar authentication framework in BL31 running at EL3 like we have in OP-TEE for Trusted Applications [1] as a starting point.

if the SMC is about passing the BL32 image down to EL3 for signature checking and loading that seem ok from security perpective. The cert would still have to be in FIP. If the rest of firmware is on secure flash I would also encrypt BL32 as it would now be on non secure world. Now, with FF-A firmware update API and SystemReady-IR, is this way of handling BL32 really beneficial?

I think the other thing that you need to take care of is that currently with OP-TEE, it is assumed that you enter via primary core (core 0) during initialization and you need to run "cpu_on_handler" on all the secondary cores.

It would be interesting to see if Firmware Framework-A (FF-A) specification can be extended to cover these use-cases since in the longer run people might be interested to launch secure partitions from different vendors at S-EL1 as well (especially considering post-Armv8.4 with S-EL2).

...

And I would definitely want to upstream this work if it's something we

can do.

I would be interested to see how this effort turns out and would be happy to review your contribution.

[1] https://optee.readthedocs.io/en/latest/architecture/trusted_applications.htm...

-Sumit

...

Thanks, Jeffrey Kardatzke Google, Inc. -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org

-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org

On Fri, Jul 1, 2022 at 1:10 AM Achin Gupta Achin.Gupta@arm.com wrote:

I am worried about losing the temporal isolation that the BL32 image (any TOS) might be relying on to initialise the system correctly before the Normal world boots.

For example, the TOS could be entrusted with programming access control hardware that isolates Secure memory from NS. A TOS might want to ensure that this is correctly reflected in the DT passed to the OS etc. Then there is Secure interrupt configuration and so on.

I'm new to this space, so I'm not really sure when exactly all the access control for security memory is established, but I was under the assumption it would be part of EL3 and be fully configured before we load the TOS. So then it wouldn't be the job of the TOS to program that itself. The secure interrupts look like they get configured once Optee initialization is done, so as long as that's not problematic to do after normal world boots, then that should be OK too.

The other side of the argument is that if such resources are pre-configured to be S or NS in HW then it does not matter when the TOS claims its resources.

Does the system you are targeting rely on this capability to maintain its security properties?

The agreement we came to internally was that since we have signed FW that is validated, we can trust what is in the FW. We then also sign the rootfs, which is validated by the FW so we can initially trust the rootfs and the normal world OS (up until a point). We can no longer trust the normal world OS once it does anything that could involve running code outside of the rootfs such as when the network is brought up or we mount the user modifiable partitions (i.e. once it opens up an attack surface). So as long as we load the TOS early enough after the normal world boots up, we should be able to trust it as much as if it was part of the signed FW image itself.

cheers, Achin

---

*From:* François Ozog via TF-A tf-a@lists.trustedfirmware.org *Sent:* 01 July 2022 08:52 *To:* Sumit Garg sumit.garg@linaro.org *Cc:* Jeffrey Kardatzke jkardatzke@google.com; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org *Subject:* [TF-A] Re: Runtime loading of SEL-1

Le ven. 1 juil. 2022 à 09:19, Sumit Garg via TF-A < tf-a@lists.trustedfirmware.org> a écrit :

Hi Jeffrey,

On Fri, 1 Jul 2022 at 04:33, Jeffrey Kardatzke via TF-A tf-a@lists.trustedfirmware.org wrote:

...

Hello,

I'm working on a project for ChromeOS where we would like to be able to

load the BL32 payload (OpTee) for SEL-1 after the linux kernel has booted rather than during the usual BL32 stage. We would do this via an SMC we would add which would take the OpTee image from linux and then have EL3 load it and perform the init for SEL-1 at that time.

...

The reasoning behind this is that it's much easier to update the rootfs

than the FW on our devices, and we can still ensure the integrity of the OpTee image if we load it early enough after the kernel boots.

It looks like an interesting motivation but I would like to hear about the real world use-cases that you are trying to address. Surely, you are not going to have any boot time services from OP-TEE in this case.

I don't think we have any need to access boot time services from Op-Tee. The sole purpose is for implementing Widevine DRM.

...

The main questions I have are if there are any issues people would be

aware of by loading it after linux boots rather than during the usual BL32 stage?

My major concern here is the authentication of the BL32 payload. Especially for pre-Armv8.4 systems where BL32 payload running in S-EL1 has a maximum level of system privileges. So you need to have a similar authentication framework in BL31 running at EL3 like we have in OP-TEE for Trusted Applications [1] as a starting point.

if the SMC is about passing the BL32 image down to EL3 for signature checking and loading that seem ok from security perpective. The cert would still have to be in FIP. If the rest of firmware is on secure flash I would also encrypt BL32 as it would now be on non secure world. Now, with FF-A firmware update API and SystemReady-IR, is this way of handling BL32 really beneficial?

Putting the secure OS in FW vs. rootfs is not really about technical issues...it's more procedural. It takes a MUCH longer time for us to push out FW updates than it does for rootfs updates (we regularly do rootfs updates, sometimes the FW never gets updated for a device). FW updates have a MUCH more onerous and time consuming qualification process since a bad FW update can do a lot more damage than a bad rootfs update. So the main motivation for all this is that we can do rootfs updates at a much faster pace and with much less difficulty than FW updates. Putting OpTee and the TAs in the rootfs gives us a much faster path for addressing any compromises because of all this. We don't feel there's a need to sign/encrypt the BL32 payload for the reasons I gave above, so we weren't planning on doing that (FW is signed, and rootfs is signed, so as long as we load the BL32 payload before we open up any attack surface we can trust it).

We also plan to include all TAs as Early TAs in OpTee to avoid having to sign any of the TAs (which makes the whole build process much easier).

I think the other thing that you need to take care of is that currently with OP-TEE, it is assumed that you enter via primary core (core 0) during initialization and you need to run "cpu_on_handler" on all the secondary cores.

Yeah, I was figuring there would be some consequences to loading Op-Tee after all the cores are activated, but it sounds like we should be able to handle this.

It would be interesting to see if Firmware Framework-A (FF-A) specification can be extended to cover these use-cases since in the longer run people might be interested to launch secure partitions from different vendors at S-EL1 as well (especially considering post-Armv8.4 with S-EL2).

...

And I would definitely want to upstream this work if it's something we

can do.

I would be interested to see how this effort turns out and would be happy to review your contribution.

Thanks for all the feedback so far!

[1] https://optee.readthedocs.io/en/latest/architecture/trusted_applications.htm...

-Sumit

...

Thanks, Jeffrey Kardatzke Google, Inc. -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org

-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org

-- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog

Hi

I agree with Sumit that the secure world in general cannot trust any data coming from the normal world, especially code to be loaded into the secure world, so any generic upstream solution would have to do authentication in the secure world. You'd need to be able to bake authentication keys owned by ChromeOS into the secure world chain of trust.

There's also an overall architectural goal to keep the EL3 runtime code as minimal as possible, so I'm uncomfortable with the idea of putting all the authentication framework there. I think a better solution would be to somehow leave BL2 at a lower secure EL lying around at runtime, which EL3 would forward the SMC to. This would make it easier to disable the functionality after the SMC is called and potentially allow reclamation of that memory.

Achin's right that on some platforms, the TOS does secure world config, e.g. secure world memory carveouts, which might be tricky to do if the normal world has already mapped in this memory. This might be a surmountable problem with some thought. It sounds like this would also have implications for FF-A and there may be other problems to work through, too.

Francois makes a good point that it might be easier to pursue improving the secure firmware update solution on the platforms in question (which needs to happen anyway).

Regards

Dan.

-----Original Message----- From: Sumit Garg via TF-A tf-a@lists.trustedfirmware.org Sent: 04 July 2022 07:53 To: Jeffrey Kardatzke jkardatzke@google.com Cc: Achin Gupta Achin.Gupta@arm.com; François Ozog francois.ozog@linaro.org; tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Runtime loading of SEL-1

On Fri, 1 Jul 2022 at 23:38, Jeffrey Kardatzke jkardatzke@google.com wrote:

...

On Fri, Jul 1, 2022 at 1:10 AM Achin Gupta Achin.Gupta@arm.com wrote:

...

I am worried about losing the temporal isolation that the BL32 image (any

TOS) might be relying on to initialise the system correctly before the Normal world boots.

...

...

For example, the TOS could be entrusted with programming access

control hardware that isolates Secure memory from NS. A TOS might want to ensure that this is correctly reflected in the DT passed to the OS etc. Then there is Secure interrupt configuration and so on.

...

I'm new to this space, so I'm not really sure when exactly all the access

control for security memory is established, but I was under the assumption it would be part of EL3 and be fully configured before we load the TOS. So then it wouldn't be the job of the TOS to program that itself. The secure interrupts look like they get configured once Optee initialization is done, so as long as that's not problematic to do after normal world boots, then that should be OK too.

...

...

The other side of the argument is that if such resources are pre-

configured to be S or NS in HW then it does not matter when the TOS claims its resources.

...

...

Does the system you are targeting rely on this capability to maintain its

security properties?

...

The agreement we came to internally was that since we have signed FW

that is validated, we can trust what is in the FW. We then also sign the rootfs, which is validated by the FW so we can initially trust the rootfs and the normal world OS (up until a point). We can no longer trust the normal world OS once it does anything that could involve running code outside of the rootfs such as when the network is brought up or we mount the user modifiable partitions (i.e. once it opens up an attack surface). So as long as we load the TOS early enough after the normal world boots up, we should be able to trust it as much as if it was part of the signed FW image itself.

...

Sorry, but this simply forfeits the purpose of having a TEE in the first place. One of the main design goals for a TEE is to keep the trusted computing base to a minimum which can be audited and certified. Now if you have included Linux kernel and the rootfs in that trusted computing base as a trusted loader for TEE then would it be possible to certify or audit that whole lot of code? The general rule we follow in OP-TEE upstream development is that we don't trust any unsigned payload coming from REE (Linux kernel + rootfs). Consider a case if an attacker is able to exploit a single bug in the Linux kernel or rootfs then essentially the whole of the system (Secure and Non-Secure world) can be compromised. I am sure that DRM vendors should have put certain certification requirements for an execution environment to be called a TEE.

Now, with the authentication framework in EL3 firmware in place, we can limit the trusted computing base to EL3 firmware itself and the TEE which can certainly be an easy candidate for the audit and certification process.

-Sumit

...

...

cheers, Achin ________________________________ From: François Ozog via TF-A tf-a@lists.trustedfirmware.org Sent: 01 July 2022 08:52 To: Sumit Garg sumit.garg@linaro.org Cc: Jeffrey Kardatzke jkardatzke@google.com; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Runtime loading of SEL-1

Le ven. 1 juil. 2022 à 09:19, Sumit Garg via TF-A <tf-

a@lists.trustedfirmware.org> a écrit :

...

...

Hi Jeffrey,

On Fri, 1 Jul 2022 at 04:33, Jeffrey Kardatzke via TF-A tf-a@lists.trustedfirmware.org wrote:

...

Hello,

I'm working on a project for ChromeOS where we would like to be able

to load the BL32 payload (OpTee) for SEL-1 after the linux kernel has booted rather than during the usual BL32 stage. We would do this via an SMC we would add which would take the OpTee image from linux and then have EL3 load it and perform the init for SEL-1 at that time.

...

...

...

The reasoning behind this is that it's much easier to update the rootfs

than the FW on our devices, and we can still ensure the integrity of the OpTee image if we load it early enough after the kernel boots.

...

...

It looks like an interesting motivation but I would like to hear about the real world use-cases that you are trying to address. Surely, you are not going to have any boot time services from OP-TEE in

this case.

...

I don't think we have any need to access boot time services from Op-Tee.

The sole purpose is for implementing Widevine DRM.

...

...

...

The main questions I have are if there are any issues people would be

aware of by loading it after linux boots rather than during the usual BL32 stage?

...

...

My major concern here is the authentication of the BL32 payload. Especially for pre-Armv8.4 systems where BL32 payload running in S-EL1 has a maximum level of system privileges. So you need to have a similar authentication framework in BL31 running at EL3 like we have in OP-TEE for Trusted Applications [1] as a starting point.

if the SMC is about passing the BL32 image down to EL3 for signature

checking and loading that seem ok from security perpective.

...

...

The cert would still have to be in FIP. If the rest of firmware is on secure

flash I would also encrypt BL32 as it would now be on non secure world.

...

...

Now, with FF-A firmware update API and SystemReady-IR, is this way of

handling BL32 really beneficial?

...

Putting the secure OS in FW vs. rootfs is not really about technical

issues...it's more procedural. It takes a MUCH longer time for us to push out FW updates than it does for rootfs updates (we regularly do rootfs updates, sometimes the FW never gets updated for a device). FW updates have a MUCH more onerous and time consuming qualification process since a bad FW update can do a lot more damage than a bad rootfs update. So the main motivation for all this is that we can do rootfs updates at a much faster pace and with much less difficulty than FW updates. Putting OpTee and the TAs in the rootfs gives us a much faster path for addressing any compromises because of all this. We don't feel there's a need to sign/encrypt the BL32 payload for the reasons I gave above, so we weren't planning on doing that (FW is signed, and rootfs is signed, so as long as we load the BL32 payload before we open up any attack surface we can trust it).

...

We also plan to include all TAs as Early TAs in OpTee to avoid having to sign

any of the TAs (which makes the whole build process much easier).

...

...

I think the other thing that you need to take care of is that currently with OP-TEE, it is assumed that you enter via primary core (core 0) during initialization and you need to run "cpu_on_handler" on all the secondary cores.

Yeah, I was figuring there would be some consequences to loading Op-Tee

after all the cores are activated, but it sounds like we should be able to handle this.

...

...

It would be interesting to see if Firmware Framework-A (FF-A) specification can be extended to cover these use-cases since in the longer run people might be interested to launch secure partitions from different vendors at S-EL1 as well (especially considering post-Armv8.4 with S-EL2).

...

And I would definitely want to upstream this work if it's something we

can do.

...

...

I would be interested to see how this effort turns out and would be happy to review your contribution.

Thanks for all the feedback so far!

...

[1] https://optee.readthedocs.io/en/latest/architecture/trusted_applicati ons.html#ree-filesystem-ta

-Sumit

...

Thanks, Jeffrey Kardatzke Google, Inc. -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org

-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org

-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog

-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org

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.

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

Happy to see more cases where a one-size-fits all approach does not necessarily work. 😉 +1 to the proposal to put changes in a separate configuration to isolate this use case and security risks while also acknowledging exploding config combinations needs separate discussions.

-----Original Message----- From: Julius Werner via TF-A tf-a@lists.trustedfirmware.org Sent: Tuesday, July 12, 2022 6:04 PM To: Sumit Garg sumit.garg@linaro.org Cc: Dan Handley Dan.Handley@arm.com; Jeffrey Kardatzke jkardatzke@google.com; Achin Gupta Achin.Gupta@arm.com; François Ozog francois.ozog@linaro.org; tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Runtime loading of SEL-1

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. -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org

For anybody interested, the patch for this has now been uploaded for review here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635

On Wed, Jul 13, 2022 at 10:18 PM Sumit Garg sumit.garg@linaro.org wrote:

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