| Message ID | 20220506062553.1068296-1-a.fatoum@pengutronix.de |
|---|---|
| Headers | show |
| Series | KEYS: trusted: Introduce support for NXP CAAM-based trusted keys | expand |
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? Cheers, Ahmad
Hi Ahmad, Comments in-line. Regards Pankaj > -----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. (rd_reg32(&priv->ctrl->perfmon.cha_num_ls) & CHA_ID_LS_AES_MASK) >> CHA_ID_LS_AES_SHIFT; > Cheers, > Ahmad
Hello Pankaj, On 11.05.22 11:16, Pankaj Gupta wrote: >> -----Original Message----- >> From: Ahmad Fatoum <a.fatoum@pengutronix.de> >>>> + 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. Do you know any SoC where this is the case? (i.e. era < 10 && CTPR_LS_BLOB && AES_CHA == 0) > 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. > > (rd_reg32(&priv->ctrl->perfmon.cha_num_ls) & > CHA_ID_LS_AES_MASK) >> CHA_ID_LS_AES_SHIFT; Sorry, I am not fond of adding quirk handling for Hardware that might not even exist. Cheers, Ahmad > >> Cheers, >> Ahmad >
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). -michael
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) "
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, I don't have a security manual for the LS1012A and LS1046A so I cannot check there. -michael
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
Hello Michael, On 06.05.22 12:52, Michael Walle wrote: > Am 2022-05-06 08:25, schrieb Ahmad Fatoum: >> Series applies on top of v5.18-rc5. Would be great if this could make it >> into v5.19. >> >> v8 was here: >> https://lore.kernel.org/linux-integrity/09e2552c-7392-e1da-926b-53c7db0b118d@pengutronix.de >> >> Changelog is beneath each individual patch. Compared to v8, only code >> change is checking whether CAAM can support blobbing at init-time as >> apparently some Layerscape SoCs are available in a non-E(ncryption) >> variant that doesn't do AES. Previously, adding trusted keys on such >> SoCs would return an error with a cryptic error message. >> >> >> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core >> built into many newer i.MX and QorIQ SoCs by NXP. >> >> Its blob mechanism can AES encrypt/decrypt user data using a unique >> never-disclosed device-specific key. >> >> There has been multiple discussions on how to represent this within the kernel: >> >> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core >> built into many newer i.MX and QorIQ SoCs by NXP. >> >> Its blob mechanism can AES encrypt/decrypt user data using a unique >> never-disclosed device-specific key. There has been multiple >> discussions on how to represent this within the kernel: >> >> - [RFC] crypto: caam - add red blobifier >> Steffen implemented[1] a PoC sysfs driver to start a discussion on how to >> best integrate the blob mechanism. >> Mimi suggested that it could be used to implement trusted keys. >> Trusted keys back then were a TPM-only feature. >> >> - security/keys/secure_key: Adds the secure key support based on CAAM. >> Udit Agarwal added[2] a new "secure" key type with the CAAM as backend. >> The key material stays within the kernel only. >> Mimi and James agreed that this needs a generic interface, not specific >> to CAAM. Mimi suggested trusted keys. Jan noted that this could serve as >> basis for TEE-backed keys. >> >> - [RFC] drivers: crypto: caam: key: Add caam_tk key type >> Franck added[3] a new "caam_tk" key type based on Udit's work. This time >> it uses CAAM "black blobs" instead of "red blobs", so key material stays >> within the CAAM and isn't exposed to kernel in plaintext. >> James voiced the opinion that there should be just one user-facing generic >> wrap/unwrap key type with multiple possible handlers. >> David suggested trusted keys. >> >> - Introduce TEE based Trusted Keys support >> Sumit reworked[4] trusted keys to support multiple possible backends with >> one chosen at boot time and added a new TEE backend along with TPM. >> This now sits in Jarkko's master branch to be sent out for v5.13 >> >> This patch series builds on top of Sumit's rework to have the CAAM as >> yet another >> trusted key backend. >> >> The CAAM bits are based on Steffen's initial patch from 2015. His work had been >> used in the field for some years now, so I preferred not to deviate >> too much from it. >> >> This series has been tested with dmcrypt[5] on an i.MX6Q/DL and an i.MX8M[6]. >> >> Looking forward to your feedback. > > For the whole series: > > Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Thanks! Did you test checkpatch.pl and make htmldocs/pdfdocs too or should I add the Tested-by just for the first 5 patches? Cheers, Ahmad > > -michael >
Hi, Am 2022-05-11 12:47, schrieb Ahmad Fatoum: > On 06.05.22 12:52, Michael Walle wrote: >> Am 2022-05-06 08:25, schrieb Ahmad Fatoum: >>> Series applies on top of v5.18-rc5. Would be great if this could make >>> it >>> into v5.19. >>> >>> v8 was here: >>> https://lore.kernel.org/linux-integrity/09e2552c-7392-e1da-926b-53c7db0b118d@pengutronix.de >>> >>> Changelog is beneath each individual patch. Compared to v8, only code >>> change is checking whether CAAM can support blobbing at init-time as >>> apparently some Layerscape SoCs are available in a non-E(ncryption) >>> variant that doesn't do AES. Previously, adding trusted keys on such >>> SoCs would return an error with a cryptic error message. >>> >>> >>> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP >>> core >>> built into many newer i.MX and QorIQ SoCs by NXP. >>> >>> Its blob mechanism can AES encrypt/decrypt user data using a unique >>> never-disclosed device-specific key. >>> >>> There has been multiple discussions on how to represent this within >>> the kernel: >>> >>> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP >>> core >>> built into many newer i.MX and QorIQ SoCs by NXP. >>> >>> Its blob mechanism can AES encrypt/decrypt user data using a unique >>> never-disclosed device-specific key. There has been multiple >>> discussions on how to represent this within the kernel: >>> >>> - [RFC] crypto: caam - add red blobifier >>> Steffen implemented[1] a PoC sysfs driver to start a discussion on >>> how to >>> best integrate the blob mechanism. >>> Mimi suggested that it could be used to implement trusted keys. >>> Trusted keys back then were a TPM-only feature. >>> >>> - security/keys/secure_key: Adds the secure key support based on >>> CAAM. >>> Udit Agarwal added[2] a new "secure" key type with the CAAM as >>> backend. >>> The key material stays within the kernel only. >>> Mimi and James agreed that this needs a generic interface, not >>> specific >>> to CAAM. Mimi suggested trusted keys. Jan noted that this could >>> serve as >>> basis for TEE-backed keys. >>> >>> - [RFC] drivers: crypto: caam: key: Add caam_tk key type >>> Franck added[3] a new "caam_tk" key type based on Udit's work. >>> This time >>> it uses CAAM "black blobs" instead of "red blobs", so key material >>> stays >>> within the CAAM and isn't exposed to kernel in plaintext. >>> James voiced the opinion that there should be just one user-facing >>> generic >>> wrap/unwrap key type with multiple possible handlers. >>> David suggested trusted keys. >>> >>> - Introduce TEE based Trusted Keys support >>> Sumit reworked[4] trusted keys to support multiple possible >>> backends with >>> one chosen at boot time and added a new TEE backend along with >>> TPM. >>> This now sits in Jarkko's master branch to be sent out for v5.13 >>> >>> This patch series builds on top of Sumit's rework to have the CAAM as >>> yet another >>> trusted key backend. >>> >>> The CAAM bits are based on Steffen's initial patch from 2015. His >>> work had been >>> used in the field for some years now, so I preferred not to deviate >>> too much from it. >>> >>> This series has been tested with dmcrypt[5] on an i.MX6Q/DL and an >>> i.MX8M[6]. >>> >>> Looking forward to your feedback. >> >> For the whole series: >> >> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) > > Thanks! Did you test checkpatch.pl and make htmldocs/pdfdocs too > or should I add the Tested-by just for the first 5 patches? I just tested the series on the mentioned hardware. So no htmldocs or checkpatch.pl. -michael
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, 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/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