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