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