[EXT] [PATCH v9 3/7] crypto: caam - determine whether CAAM supports blob encap/decap

[Horia Geantă]

On 5/11/2022 12:59 PM, Michael Walle wrote:
> Am 2022-05-11 11:48, schrieb Horia Geantă:
>> On 5/11/2022 12:21 PM, Michael Walle wrote:
>>> Hi,
>>>
>>> Am 2022-05-11 11:16, schrieb Pankaj Gupta:
>>>>> -----Original Message-----
>>>>> From: Ahmad Fatoum <a.fatoum at pengutronix.de>
>>>>> Sent: Monday, May 9, 2022 6:34 PM
>>>>> To: Pankaj Gupta <pankaj.gupta at nxp.com>; Horia Geanta
>>>>> <horia.geanta at nxp.com>; Herbert Xu <herbert at gondor.apana.org.au>;
>>>>> David S.
>>>>> Miller <davem at davemloft.net>
>>>>> Cc: kernel at pengutronix.de; Michael Walle <michael at walle.cc>; James
>>>>> Bottomley <jejb at linux.ibm.com>; Jarkko Sakkinen <jarkko at kernel.org>;
>>>>> Mimi
>>>>> Zohar <zohar at linux.ibm.com>; David Howells <dhowells at redhat.com>;
>>>>> James
>>>>> Morris <jmorris at namei.org>; Eric Biggers <ebiggers at kernel.org>; 
>>>>> Serge
>>>>> E.
>>>>> Hallyn <serge at hallyn.com>; Jan Luebbe <j.luebbe at pengutronix.de>; 
>>>>> David
>>>>> Gstir
>>>>> <david at sigma-star.at>; Richard Weinberger <richard at nod.at>; Franck
>>>>> Lenormand <franck.lenormand at nxp.com>; Matthias Schiffer
>>>>> <matthias.schiffer at ew.tq-group.com>; Sumit Garg
>>>>> <sumit.garg at linaro.org>;
>>>>> linux-integrity at vger.kernel.org; keyrings at vger.kernel.org; linux-
>>>>> crypto at vger.kernel.org; linux-kernel at vger.kernel.org; 
>>>>> linux-security-
>>>>> module at vger.kernel.org
>>>>> Subject: Re: [EXT] [PATCH v9 3/7] crypto: caam - determine whether
>>>>> CAAM
>>>>> supports blob encap/decap
>>>>>
>>>>> Caution: EXT Email
>>>>>
>>>>> Hello Pankaj,
>>>>>
>>>>> On Mon, 2022-05-09 at 12:39 +0000, Pankaj Gupta wrote:
>>>>>>> -       if (ctrlpriv->era < 10)
>>>>>>> +       comp_params = rd_reg32(&ctrl->perfmon.comp_parms_ls);
>>>>>>> +       ctrlpriv->blob_present = !!(comp_params & CTPR_LS_BLOB);
>>>>>>> +
>>>>>>> +       if (ctrlpriv->era < 10) {
>>>>>>>                 rng_vid = (rd_reg32(&ctrl->perfmon.cha_id_ls) &
>>>>>>>                            CHA_ID_LS_RNG_MASK) >>
>>>>>>> CHA_ID_LS_RNG_SHIFT;
>>>>>>
>>>>>> Check for AES CHAs for Era < 10, should be added.
>>>>>
>>>>> Do I need this? I only do this check for Era >= 10, because 
>>>>> apparently
>>>>> there are
>>>>> Layerscape non-E processors that indicate BLOB support via
>>>>> CTPR_LS_BLOB, but
>>>>> fail at runtime. Are there any Era < 10 SoCs that are similarly
>>>>> broken?
>>>>>
>>>>
>>>> For non-E variants, it might happen that Blob protocol is enabled, 
>>>> but
>>>> number of AES CHA are zero.
>>>> If the output of below expression is > 0, then only blob_present
>>>> should be marked present or true.
>>>> For era > 10, you handled. But for era < 10, please add the below 
>>>> code.
>>>
>>> Are there any CAAMs which can be just enabled partially for era < 10?
>>> I didn't found anything. To me it looks like the non-export controlled
>>> CAAM is only available for era >= 10. For era < 10, the CAAM is either
>>> fully featured there or it is not available at all and thus the node
>>> is removed in the bootloader (at least that is the case for 
>>> layerscape).
>>>
>> Qouting from our previous discussion in U-boot:
>> https://patchwork.ozlabs.org/project/uboot/patch/20200602150904.1997-1-michael@walle.cc/#2457448
>>
>> "
>> Based on previous (NXP-internal) discussions, non-E crypto module is:
>> -fully disabled on: LS1021A (ARMv7), LS1043A, LS1088A, LS2088A
>> (and their personalities)
>> -partially [*] disabled on: LS1012A, LS1028A, LS1046A, LX2160A
>> (and their personalities)
>> "
>>
>> From the partially disabled list, LS1028A and LX2160A have CAAM Era 10,
>> while LS1012A and LS1046A integrate CAAM Era 8.
> 
> Thanks for clarification. Do you know it that is a layerscape feature?
> I had a look at the imx8mn which have a era 9 and it doesn't have the
> PKHA_VERSION register which indicates the partially disabled PKHA
> block. Thus I concluded that there is no partially disabled feature
> on era < 10.
> 
Unfortunately when moving from Era 9 to Era 10, the register map
is not 100% backwards-compatible.
This is why you're not seeing PKHA_VERSION register for i.MX8MN.

For Era >= 10, the CHA version and CHA number fields are conveniently found
found in the same *_VERSION register, e.g. PKHA_VID and PKHA_NUM are both
located in PKHA_VERSION.

For Era < 10, these fields are scattered:
CHAVID_LS[PKVID]
CHANUM_LS[PKNUM]

> Unfortunately, I don't have a security manual for the LS1012A and
> LS1046A so I cannot check there.
> 
Looks like for LS1046A the manual is public:
https://www.nxp.com/docs/en/reference-manual/LS1046ASECRM.pdf

while for LS1012A you need to have an account on nxp.com:
https://www.nxp.com/webapp/Download?colCode=LS1012ASECRM&location=null

Horia