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

[Bryan O'Donoghue]

On 24/01/18 12:52, Auer, Lukas wrote:
> 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.

So I just sent out a patch-set for i.MX7 covering this - I added you to 
the CC list for that.

The guidance from NXP (and my experience) is that the current kernel 
driver bugs-out when it can't touch the deco registers.

I have a bunch of fixes around that.

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

Yes I agree. Then again there is currently no CAAM/OPTEE driver so 
nothing to-do.