[U-Boot] [PATCH 0/2] Fix CAAM for TrustZone enable for warp7

[Auer, Lukas]

On Tue, 2018-01-23 at 21:10 +0000, Bryan O'Donoghue wrote:
> This series is the u-boot fix to a problem we encountered when
> enabling
> OPTEE/TrustZone on the WaRP7. The symptom is once TrustZone is
> activated
> the first page of CAAM registers becomes read-only, read-zero from
> the
> perspective of Linux and other non TrustZone contexts.
> 
> Offlining the problem with Peng Fan[1] we eventually came to realise
> the
> problem could be worked around by
> 
> 1. Making Linux skip RNG initialisation - a set of patches should be
>    hitting LKML to do just that.
> 
> 2. Initialising the RNG either from u-boot or OPTEE. In this case u-
> boot is
>    the right place to-do that because there's upstream code in u-boot 
> that
>    just works. Patch #2 does that for the WaRP7.
> 
> 3. Ensuring the job-ring registers are assigned to the non TrustZone
> mode.
>    On the i.MX7 after the BootROM runs the job-ring registers are
> assigned
>    to TrustZone. Patch #1 does that for all CAAM hardware.
> 

I did have the same issue, not with booting OPTEE, but booting Linux in
non-secure mode. #2 and #3 are required to handle this problem, but #1
is not needed.

The CAAM kernel driver always tries to instantiate all RNG state
handles directly using DEC0 (which is only accessible from secure
mode). The u-boot driver however only instantiates the first state
handle, which is why the kernel driver then goes on and tries to
instantiate the second one. This is solved by simply instantiating all
RNG state handles in the CAAM u-boot driver.

I can prepare a patch to implement this, if there is interest. This is
tested to work with the mainline kernel and I assume that it would work
with the NXP kernel as well. Further patches are however needed to
support the imx7 in the CAAM kernel driver.

> On point #3 this ordinarily isn't a problem because unless TrustZone
> is
> activated the restrictions on the job-ring registers don't kick in,
> its
> only after enabling TrustZone that Linux will loose access to the
> job-ring
> registers.
> 
> Finally should OPTEE or another TEE want to do things with the job-
> ring
> registers it will have sufficient privilege to assign whichever job-
> ring
> registers it wants to OPTEE/TEE but will naturally then have to
> arbitrate
> with Linux to inform the Kernel CAAM driver which job-ring registers
> it can
> and cannot access.
> 
> That arbitration process is for a future putative OPTEE/TEE CAAM
> driver to
> solve and is out of scope of this patchset.

This is actually quite simple to solve, since each job ring has a
separate device tree node. Simply disabling all job rings used by OPTEE
/ secure world software should be sufficient.

Thanks,
Lukas

> [1] Thanks for all of your help BTW - Peng, there's no way this would
> be
>     working without you giving direction on how.
> 
> Bryan O'Donoghue (2):
>   drivers/crypto/fsl: assign job-rings to non-TrustZone
>   warp7 : run sec_init for CAAM RNG
> 
>  board/warp7/warp7.c     | 6 +++++-
>  drivers/crypto/fsl/jr.c | 9 +++++++++
>  drivers/crypto/fsl/jr.h | 1 +
>  3 files changed, 15 insertions(+), 1 deletion(-)
>