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 <[email protected]>
>>>>> Sent: Monday, May 9, 2022 6:34 PM
>>>>> To: Pankaj Gupta <[email protected]>; Horia Geanta
>>>>> <[email protected]>; Herbert Xu <[email protected]>;
>>>>> David S.
>>>>> Miller <[email protected]>
>>>>> Cc: [email protected]; Michael Walle <[email protected]>; James
>>>>> Bottomley <[email protected]>; Jarkko Sakkinen <[email protected]>;
>>>>> Mimi
>>>>> Zohar <[email protected]>; David Howells <[email protected]>;
>>>>> James
>>>>> Morris <[email protected]>; Eric Biggers <[email protected]>;
>>>>> Serge
>>>>> E.
>>>>> Hallyn <[email protected]>; Jan Luebbe <[email protected]>;
>>>>> David
>>>>> Gstir
>>>>> <[email protected]>; Richard Weinberger <[email protected]>; Franck
>>>>> Lenormand <[email protected]>; Matthias Schiffer
>>>>> <[email protected]>; Sumit Garg
>>>>> <[email protected]>;
>>>>> [email protected]; [email protected]; linux-
>>>>> [email protected]; [email protected];
>>>>> linux-security-
>>>>> [email protected]
>>>>> 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/[email protected]/#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
Am 2022-05-11 12:28, schrieb Horia Geantă:
>>>>> 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/[email protected]/#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]
Ok, but there is only the number of instances. I couldn't find a
similar bit to the PKHA_VERSION[PKHA_MISC[7]] bit, which indicates
PKHA decryption/encryption capability is disabled. That seems to
be only for era >= 10, right? That was what caused my confusion,
because until now I was under the impression that non-E variants
will always have that bit.
Rereading your comment, you don't mention PKHA at all. So for
era <10 if you blow the EXPORT_CONTROL fuse, you'll have zero
in any *NUM except for MDNUM, RNGNUM and CRCNUM. Is that correct?
In that case, I agree, we should also check CHANUM_LS[AESNUM] for
era < 10.
-michael
On 5/11/2022 2:54 PM, Michael Walle wrote:
> Am 2022-05-11 12:28, schrieb Horia Geantă:
>
>>>>>> 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/[email protected]/#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]
>
> Ok, but there is only the number of instances. I couldn't find a
> similar bit to the PKHA_VERSION[PKHA_MISC[7]] bit, which indicates
> PKHA decryption/encryption capability is disabled. That seems to
> be only for era >= 10, right? That was what caused my confusion,
Yes, there's no corresponding information for PKHA_MISC on CAAM versions
earlier than Era 10.
Only starting with Era 10 PKHA can be _partially_ disabled on non-E CAAM.
> because until now I was under the impression that non-E variants
> will always have that bit.
>
> Rereading your comment, you don't mention PKHA at all. So for
> era <10 if you blow the EXPORT_CONTROL fuse, you'll have zero
> in any *NUM except for MDNUM, RNGNUM and CRCNUM. Is that correct?
>
Partially true.
For some SoCs, CAAM does not support CRCA at all, irrespective of the state
of the fuse.
> In that case, I agree, we should also check CHANUM_LS[AESNUM] for
> era < 10.
>
Btw, newer manuals have the subsection
"SEC/ CAAM implementation" -> "SEC/CAAM Versions with Encryption Disabled"
which details what happens in case encryption is disabled.
Horia