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

From: "Horia Geantă" <horia.geanta@nxp.com>
To: Michael Walle <michael@walle.cc>
Cc: Pankaj Gupta <pankaj.gupta@nxp.com>,
	Ahmad Fatoum <a.fatoum@pengutronix.de>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	James Bottomley <jejb@linux.ibm.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Mimi Zohar <zohar@linux.ibm.com>,
	David Howells <dhowells@redhat.com>,
	James Morris <jmorris@namei.org>,
	Eric Biggers <ebiggers@kernel.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Jan Luebbe <j.luebbe@pengutronix.de>,
	David Gstir <david@sigma-star.at>,
	Richard Weinberger <richard@nod.at>,
	Franck Lenormand <franck.lenormand@nxp.com>,
	Matthias Schiffer <matthias.schiffer@ew.tq-group.com>,
	Sumit Garg <sumit.garg@linaro.org>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>
Subject: Re: [EXT] [PATCH v9 3/7] crypto: caam - determine whether CAAM supports blob encap/decap
Date: Thu, 12 May 2022 10:07:36 +0300	[thread overview]
Message-ID: <c22218d5-e6d0-8bb8-f129-427c69bdb1f3@nxp.com> (raw)
In-Reply-To: <6fb4414da896cbac68332ae34eab5081@walle.cc>

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/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]
> 
> 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