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