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

Michael Walle michael at walle.cc
Wed May 11 09:59:35 UTC 2022


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, I don't have a security manual for the LS1012A and
LS1046A so I cannot check there.

-michael



More information about the Linux-security-module-archive mailing list