Messages in this thread | | | Date | Wed, 11 May 2022 13:28:36 +0300 | Subject | Re: [EXT] [PATCH v9 3/7] crypto: caam - determine whether CAAM supports blob encap/decap | From | 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@pengutronix.de> >>>>> Sent: Monday, May 9, 2022 6:34 PM >>>>> To: Pankaj Gupta <pankaj.gupta@nxp.com>; Horia Geanta >>>>> <horia.geanta@nxp.com>; Herbert Xu <herbert@gondor.apana.org.au>; >>>>> David S. >>>>> Miller <davem@davemloft.net> >>>>> Cc: kernel@pengutronix.de; Michael Walle <michael@walle.cc>; 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; keyrings@vger.kernel.org; linux- >>>>> crypto@vger.kernel.org; linux-kernel@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 >>>>> >>>>> 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
| |