[U-Boot,1/4] crypto/fsl: Introduce API to save/restore job-ring context

We need to handle the case where DEK blobs are passed to the BootROM. In
this case, unlike in HAB authentication the BootROM checks job-ring
ownership set to secure world.

One possible solution is to set the job-ring ownership to the expected
state for DEK blobs and then restore to whatever the run-time wants.

For the case where Linux runs in normal-world we would want to set the
job-ring ownership to normal-world.

The first step in the ownership context switch dance is making an API to do
it.

This patch introduces:

void __weak sec_set_jr_context_secure(void);
void __weak sec_set_jr_context_normal(void);

This can be over-ridden for a given architecture, as will be necessary for
the MPC85xxx

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
 drivers/crypto/fsl/jr.c | 38 ++++++++++++++++++++++++++++++++++++++
 include/fsl_sec.h       |  3 +++
 2 files changed, 41 insertions(+)

Hi Bryan,

Em ter, 23 de abr de 2019 às 07:20, Bryan O'Donoghue
<bryan.odonoghue@linaro.org> escreveu:
>
> We need to handle the case where DEK blobs are passed to the BootROM. In
> this case, unlike in HAB authentication the BootROM checks job-ring
> ownership set to secure world.
>
> One possible solution is to set the job-ring ownership to the expected
> state for DEK blobs and then restore to whatever the run-time wants.
>
> For the case where Linux runs in normal-world we would want to set the
> job-ring ownership to normal-world.
>
> The first step in the ownership context switch dance is making an API to do
> it.
>
> This patch introduces:
>
> void __weak sec_set_jr_context_secure(void);
> void __weak sec_set_jr_context_normal(void);
>
> This can be over-ridden for a given architecture, as will be necessary for
> the MPC85xxx
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
>  drivers/crypto/fsl/jr.c | 38 ++++++++++++++++++++++++++++++++++++++
>  include/fsl_sec.h       |  3 +++
>  2 files changed, 41 insertions(+)
>
> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
> index cc8d3b02a5..7b13aa4a61 100644
> --- a/drivers/crypto/fsl/jr.c
> +++ b/drivers/crypto/fsl/jr.c
> @@ -574,6 +574,44 @@ static int rng_init(uint8_t sec_idx)
>         return ret;
>  }
>  #endif
> +
> +static void __sec_set_jr_context_secure(uint8_t sec_idx)
> +{
> +       ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
> +       uint32_t jrown_ns;
> +       int i;
> +
> +       for (i = 0; i < ARRAY_SIZE(sec->jrliodnr); i++) {
> +               jrown_ns = sec_in32(&sec->jrliodnr[i].ms);
> +               jrown_ns &= ~(JROWN_NS | JRMID_NS);

We have the following definition at drivers/crypto/fsl/jr.h:

#define JRMID_NS 0x00000001

Seems that we are setting JROWN_MID field which is not TrustZone
related, from i.MX7D Security Reference Manual:

Job Ring Owner's MID. This field defines the MID of the bus master
that is permitted to read or write the registers that are specific to
a particular Job Ring. These registers include the job ring
configuration registers, the interrupt registers, the CAAM Secure
Memory Access Permissions and Secure Memory Access Group registers and
the ring buffer registers.

Could you please double check?

Thanks,
Breno Lima

On 25/04/2019 23:13, Breno Matheus Lima wrote:
> Hi Bryan,
> 
> Em ter, 23 de abr de 2019 às 07:20, Bryan O'Donoghue
> <bryan.odonoghue@linaro.org> escreveu:
>>
>> We need to handle the case where DEK blobs are passed to the BootROM. In
>> this case, unlike in HAB authentication the BootROM checks job-ring
>> ownership set to secure world.
>>
>> One possible solution is to set the job-ring ownership to the expected
>> state for DEK blobs and then restore to whatever the run-time wants.
>>
>> For the case where Linux runs in normal-world we would want to set the
>> job-ring ownership to normal-world.
>>
>> The first step in the ownership context switch dance is making an API to do
>> it.
>>
>> This patch introduces:
>>
>> void __weak sec_set_jr_context_secure(void);
>> void __weak sec_set_jr_context_normal(void);
>>
>> This can be over-ridden for a given architecture, as will be necessary for
>> the MPC85xxx
>>
>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>> ---
>>   drivers/crypto/fsl/jr.c | 38 ++++++++++++++++++++++++++++++++++++++
>>   include/fsl_sec.h       |  3 +++
>>   2 files changed, 41 insertions(+)
>>
>> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
>> index cc8d3b02a5..7b13aa4a61 100644
>> --- a/drivers/crypto/fsl/jr.c
>> +++ b/drivers/crypto/fsl/jr.c
>> @@ -574,6 +574,44 @@ static int rng_init(uint8_t sec_idx)
>>          return ret;
>>   }
>>   #endif
>> +
>> +static void __sec_set_jr_context_secure(uint8_t sec_idx)
>> +{
>> +       ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
>> +       uint32_t jrown_ns;
>> +       int i;
>> +
>> +       for (i = 0; i < ARRAY_SIZE(sec->jrliodnr); i++) {
>> +               jrown_ns = sec_in32(&sec->jrliodnr[i].ms);
>> +               jrown_ns &= ~(JROWN_NS | JRMID_NS);
> 
> We have the following definition at drivers/crypto/fsl/jr.h:
> 
> #define JRMID_NS 0x00000001
> 
> Seems that we are setting JROWN_MID field which is not TrustZone
> related, from i.MX7D Security Reference Manual:
> 
> Job Ring Owner's MID. This field defines the MID of the bus master
> that is permitted to read or write the registers that are specific to
> a particular Job Ring. These registers include the job ring
> configuration registers, the interrupt registers, the CAAM Secure
> Memory Access Permissions and Secure Memory Access Group registers and
> the ring buffer registers.

Hrmm, just seeing your response now Breno.

What we have is:
include/fsl_sec.h:#define JR_MID    2    /* Matches ROM configuration */

There's a decent argument to read what the BootROM has set for JR_MID 
and write it back ...

Let me include that in v2.

---
bod