[U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent

[Breno Matheus Lima]

Hi Bryan,

Em dom, 7 de abr de 2019 às 05:05, Bryan O'Donoghue
<bryan.odonoghue at linaro.org> escreveu:
>
>
>
> On 06/04/2019 22:41, Breno Matheus Lima wrote:
> > Hi Bryan,
> >
> > Em sáb, 6 de abr de 2019 às 12:21, Bryan O'Donoghue
> > <bryan.odonoghue at linaro.org> escreveu:
> >>
> >>
> >>
> >> On 05/04/2019 17:16, Breno Matheus Lima wrote:
> >> Basically you've described and additional dependency the BootROM has, so
> >> lets just "switch context" prior to calling into the BootROM and restore
> >> to a default non-secure job-ring assignment after.
> >
> > Yes, this can work for OP-TEE users decrypting additional boot images
> > at U-Boot level, however all users won't be able to
> > authenticate/decrypt the initial boot image at BootROM level.
>
> I don't understand that comment, perhaps you can give an example.
>

You can take a look in application note AN12056:
https://www.nxp.com/docs/en/application-note/AN12056.pdf

Section 2.2 provides more details on the encrypted boot sequence, as
you can see in Figure 1 the U-Boot image is decrypted at bootROM level
after a system reset. Section 4 explains how to encrypt and sign an
U-Boot image.

As I mentioned in commit log, the ROM code expects DEK blobs
encapsulated by the Secure World environments which commonly have
JROWN_NS = 0.

> > Out of
> > reset CAAM job rings are assigned to TrustZone secure world and
> > BootROM code is expecting blobs generated by the same environment.
> >
> > What about moving the job rings assignment to OP-TEE level? Something
> > similar as we currently have in imx-optee-os project?
>
> TBH, I see that as something that should be done _anyway_ not instead
> i.e. after u-boot, if you want to do 'stuff' with the CAAM you are either
>
> 1. Running in non-secure Linux, in which case you need the job-rings
>     assigned to non-secure mode or
>
> 2. You are running inside of a TEE, in which case you absolutely need
>     to have at least one job-ring
>
> ... and for the second case the right thing to do is to arbitrate
> ownership of job-rings via a DTB
>
> > https://source.codeaurora.org/external/imx/imx-optee-os/tree/core/drivers/caam/hal/imx_6_7/hal_jr.c?h=imx_4.14.78_1.0.0_ga#n31
> >
> > U-Boot is running in TrustZone secure world in most of targets, in my
> > opinion it makes sense to have at least 1 job ring assigned to
> > TrustZone secure world.
>
> But if u-boot is running in secure-world
>
> save_jr_context();
> setup_some_new_jr_context();
> hab_authenticate_something();
> restore_jr_context();

This can only work if we do similar operation in CMD_DEKBLOB:

save_jr_context();
setup_some_new_jr_context();
blob_dek()
restore_jr_context();

Both operations blob_dek() and hab_authenticate_image() at U-Boot
level must have the Job Ring assigned for TrustZone secure world. The
first authentication/decryption at bootROM level is expecting a DEK
blobs generated by TrustZone secure world.

>
> As a "quick fix", that's the way I'd do it. Just pivoting on
> CONFIG_OPTEE is pretty easy to break i.e. you can have CONFIG_OPTEE
> defined in your u-boot config but not actually be executing a TEE, in
> which case by the time you boot Linux your JR assignment is wrong..

Can you please provide more details on how this can break users that
has CONFIG_OPTEE defined and are not executing a TEE? From my
understanding Linux Kernel will be running in TZ secure world and JRs
assigned to TZ non-secure world, CAAM driver can still be used on this
condition (Similar as we currently have for mx7dsabresd target).

In order to have a quick fix available, what about delaying the Job
Ring assignment in U-Boot?

Perhaps we can provide an U-Boot command to set the Job Ring
ownership, users can add this command in their boot script just before
booting Kernel and/or OP-TEE.

>
> The correct and flexible fix is passing a DTB descriptor that u-boot,
> OPTEE and Kernel can put data into so that there's a canonical
> description of which execution environment owns what.
>

Yes, I agree. We need a more flexible fix here.

Best regards,
Breno Lima