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

Commit Message

Ahmad Fatoum May 6, 2022, 6:25 a.m. UTC

Depending on SoC variant, a CAAM may be available, but with some futures
fused out. The LS1028A (non-E) SoC is one such SoC and while it
indicates BLOB support, BLOB operations will ultimately fail, because
there is no AES support. Add a new blob_present member to reflect
whether both BLOB support and the AES support it depends on is
available.

These will be used in a follow-up commit to allow blob driver
initialization to error out on SoCs without the necessary hardware
support instead of failing at runtime with a cryptic

  caam_jr 8020000.jr: 20000b0f: CCB: desc idx 11: : Invalid CHA selected.

Co-developed-by: Michael Walle <[e-mail]>
Signed-off-by: Michael Walle <[e-mail]>
Signed-off-by: Ahmad Fatoum <[e-mail]>

---
v8 -> v9:
  - New patch

To: "Horia Geantă" <[e-mail]>
To: Pankaj Gupta <[e-mail]>
To: Herbert Xu <[e-mail]>
To: "David S. Miller" <[e-mail]>
Cc: James Bottomley <[e-mail]>
Cc: Jarkko Sakkinen <[e-mail]>
Cc: Mimi Zohar <[e-mail]>
Cc: David Howells <[e-mail]>
Cc: James Morris <[e-mail]>
Cc: Eric Biggers <[e-mail]>
Cc: "Serge E. Hallyn" <[e-mail]>
Cc: Jan Luebbe <[e-mail]>
Cc: David Gstir <[e-mail]>
Cc: Richard Weinberger <[e-mail]>
Cc: Franck LENORMAND <[e-mail]>
Cc: Matthias Schiffer <[e-mail]>
Cc: Sumit Garg <[e-mail]>
Cc: Michael Walle <[e-mail]>
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
---
 drivers/crypto/caam/ctrl.c   | 10 ++++++++--
 drivers/crypto/caam/intern.h |  1 +
 drivers/crypto/caam/regs.h   |  4 +++-
 3 files changed, 12 insertions(+), 3 deletions(-)

Comments

Pankaj Gupta May 9, 2022, 12:39 p.m. UTC | #1

Hi Ahmad,

Check for AES CHAs is done only for Era >= 10.

Please find the comments in-line.

Regards
Pankaj

> -----Original Message-----
> From: Ahmad Fatoum <[e-mail]>
> Sent: Friday, May 6, 2022 11:56 AM
> To: Horia Geanta <[e-mail]>; Pankaj Gupta
> <[e-mail]>; Herbert Xu <[e-mail]>; David
> S. Miller <[e-mail]>
> Cc: [e-mail]; Michael Walle <[e-mail]>; Ahmad Fatoum
> <[e-mail]>; James Bottomley <[e-mail]>; Jarkko
> Sakkinen <[e-mail]>; Mimi Zohar <[e-mail]>; David
> Howells <[e-mail]>; James Morris <[e-mail]>; Eric
> Biggers <[e-mail]>; Serge E. Hallyn <[e-mail]>; Jan
> Luebbe <[e-mail]>; David Gstir <[e-mail]>; Richard
> Weinberger <[e-mail]>; Franck Lenormand
> <[e-mail]>; Matthias Schiffer <[e-mail]-
> group.com>; Sumit Garg <[e-mail]>; linux-
> [e-mail]; [e-mail]; linux-
> [e-mail]; [e-mail]; linux-security-
> [e-mail]
> Subject: [EXT] [PATCH v9 3/7] crypto: caam - determine whether CAAM supports
> blob encap/decap
> 
> Caution: EXT Email
> 
> Depending on SoC variant, a CAAM may be available, but with some futures
> fused out. The LS1028A (non-E) SoC is one such SoC and while it indicates BLOB
> support, BLOB operations will ultimately fail, because there is no AES support.
> Add a new blob_present member to reflect whether both BLOB support and the
> AES support it depends on is available.
> 
> These will be used in a follow-up commit to allow blob driver initialization to
> error out on SoCs without the necessary hardware support instead of failing at
> runtime with a cryptic
> 
>   caam_jr 8020000.jr: 20000b0f: CCB: desc idx 11: : Invalid CHA selected.
> 
> Co-developed-by: Michael Walle <[e-mail]>
> Signed-off-by: Michael Walle <[e-mail]>
> Signed-off-by: Ahmad Fatoum <[e-mail]>
> 
> ---
> v8 -> v9:
>   - New patch
> 
> To: "Horia Geantă" <[e-mail]>
> To: Pankaj Gupta <[e-mail]>
> To: Herbert Xu <[e-mail]>
> To: "David S. Miller" <[e-mail]>
> Cc: James Bottomley <[e-mail]>
> Cc: Jarkko Sakkinen <[e-mail]>
> Cc: Mimi Zohar <[e-mail]>
> Cc: David Howells <[e-mail]>
> Cc: James Morris <[e-mail]>
> Cc: Eric Biggers <[e-mail]>
> Cc: "Serge E. Hallyn" <[e-mail]>
> Cc: Jan Luebbe <[e-mail]>
> Cc: David Gstir <[e-mail]>
> Cc: Richard Weinberger <[e-mail]>
> Cc: Franck LENORMAND <[e-mail]>
> Cc: Matthias Schiffer <[e-mail]>
> Cc: Sumit Garg <[e-mail]>
> Cc: Michael Walle <[e-mail]>
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> ---
>  drivers/crypto/caam/ctrl.c   | 10 ++++++++--
>  drivers/crypto/caam/intern.h |  1 +
>  drivers/crypto/caam/regs.h   |  4 +++-
>  3 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c index
> ca0361b2dbb0..6426ffec5980 100644
> --- a/drivers/crypto/caam/ctrl.c
> +++ b/drivers/crypto/caam/ctrl.c
> @@ -820,12 +820,18 @@ static int caam_probe(struct platform_device *pdev)
>                 return -ENOMEM;
>         }
> 
> -       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.

> -       else
> +       } else {
>                 rng_vid = (rd_reg32(&ctrl->vreg.rng) & CHA_VER_VID_MASK) >>
>                            CHA_VER_VID_SHIFT;
> +               ctrlpriv->blob_present = ctrlpriv->blob_present &&
> +                       (rd_reg32(&ctrl->vreg.aesa) & CHA_VER_MISC_AES_NUM_MASK);
> +       }
> 
>         /*
>          * If SEC has RNG version >= 4 and RNG state handle has not been diff --git
> a/drivers/crypto/caam/intern.h b/drivers/crypto/caam/intern.h index
> 7d45b21bd55a..e92210e2ab76 100644
> --- a/drivers/crypto/caam/intern.h
> +++ b/drivers/crypto/caam/intern.h
> @@ -92,6 +92,7 @@ struct caam_drv_private {
>          */
>         u8 total_jobrs;         /* Total Job Rings in device */
>         u8 qi_present;          /* Nonzero if QI present in device */
> +       u8 blob_present;        /* Nonzero if BLOB support present in device */
>         u8 mc_en;               /* Nonzero if MC f/w is active */
>         int secvio_irq;         /* Security violation interrupt number */
>         int virt_en;            /* Virtualization enabled in CAAM */
> diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h index
> 3738625c0250..66d6dad841bb 100644
> --- a/drivers/crypto/caam/regs.h
> +++ b/drivers/crypto/caam/regs.h
> @@ -320,7 +320,8 @@ struct version_regs {
>  #define CHA_VER_VID_MASK       (0xffull << CHA_VER_VID_SHIFT)
> 
>  /* CHA Miscellaneous Information - AESA_MISC specific */
> -#define CHA_VER_MISC_AES_GCM   BIT(1 + CHA_VER_MISC_SHIFT)
> +#define CHA_VER_MISC_AES_NUM_MASK      GENMASK(7, 0)
> +#define CHA_VER_MISC_AES_GCM           BIT(1 + CHA_VER_MISC_SHIFT)
> 
>  /* CHA Miscellaneous Information - PKHA_MISC specific */
>  #define CHA_VER_MISC_PKHA_NO_CRYPT     BIT(7 + CHA_VER_MISC_SHIFT)
> @@ -414,6 +415,7 @@ struct caam_perfmon {
>  #define CTPR_MS_PG_SZ_MASK     0x10
>  #define CTPR_MS_PG_SZ_SHIFT    4
>         u32 comp_parms_ms;      /* CTPR - Compile Parameters Register   */
> +#define CTPR_LS_BLOB           BIT(1)
>         u32 comp_parms_ls;      /* CTPR - Compile Parameters Register   */
>         u64 rsvd1[2];
> 
> --
> 2.30.2

Ahmad Fatoum May 9, 2022, 1:04 p.m. UTC | #2

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

Pankaj Gupta May 11, 2022, 9:16 a.m. UTC | #3

Hi Ahmad,

Comments in-line.

Regards
Pankaj

> -----Original Message-----
> From: Ahmad Fatoum <[e-mail]>
> Sent: Monday, May 9, 2022 6:34 PM
> To: Pankaj Gupta <[e-mail]>; Horia Geanta
> <[e-mail]>; Herbert Xu <[e-mail]>; David S.
> Miller <[e-mail]>
> Cc: [e-mail]; Michael Walle <[e-mail]>; James
> Bottomley <[e-mail]>; Jarkko Sakkinen <[e-mail]>; Mimi
> Zohar <[e-mail]>; David Howells <[e-mail]>; James
> Morris <[e-mail]>; Eric Biggers <[e-mail]>; Serge E.
> Hallyn <[e-mail]>; Jan Luebbe <[e-mail]>; David Gstir
> <[e-mail]>; Richard Weinberger <[e-mail]>; Franck
> Lenormand <[e-mail]>; Matthias Schiffer
> <[e-mail]>; Sumit Garg <[e-mail]>;
> [e-mail]; [e-mail]; linux-
> [e-mail]; [e-mail]; linux-security-
> [e-mail]
> 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

Ahmad Fatoum May 11, 2022, 9:21 a.m. UTC | #4

Hello Pankaj,

On 11.05.22 11:16, Pankaj Gupta wrote:
>> -----Original Message-----
>> From: Ahmad Fatoum <[e-mail]>
>>>> +       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
>

Michael Walle May 11, 2022, 9:21 a.m. UTC | #5

Hi,

Am 2022-05-11 11:16, schrieb Pankaj Gupta:
>> -----Original Message-----
>> From: Ahmad Fatoum <[e-mail]>
>> Sent: Monday, May 9, 2022 6:34 PM
>> To: Pankaj Gupta <[e-mail]>; Horia Geanta
>> <[e-mail]>; Herbert Xu <[e-mail]>; 
>> David S.
>> Miller <[e-mail]>
>> Cc: [e-mail]; Michael Walle <[e-mail]>; James
>> Bottomley <[e-mail]>; Jarkko Sakkinen <[e-mail]>; 
>> Mimi
>> Zohar <[e-mail]>; David Howells <[e-mail]>; 
>> James
>> Morris <[e-mail]>; Eric Biggers <[e-mail]>; Serge 
>> E.
>> Hallyn <[e-mail]>; Jan Luebbe <[e-mail]>; David 
>> Gstir
>> <[e-mail]>; Richard Weinberger <[e-mail]>; Franck
>> Lenormand <[e-mail]>; Matthias Schiffer
>> <[e-mail]>; Sumit Garg 
>> <[e-mail]>;
>> [e-mail]; [e-mail]; linux-
>> [e-mail]; [e-mail]; linux-security-
>> [e-mail]
>> 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

Horia Geanta May 11, 2022, 9:48 a.m. UTC | #6

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 <[e-mail]>
>>> Sent: Monday, May 9, 2022 6:34 PM
>>> To: Pankaj Gupta <[e-mail]>; Horia Geanta
>>> <[e-mail]>; Herbert Xu <[e-mail]>; 
>>> David S.
>>> Miller <[e-mail]>
>>> Cc: [e-mail]; Michael Walle <[e-mail]>; James
>>> Bottomley <[e-mail]>; Jarkko Sakkinen <[e-mail]>; 
>>> Mimi
>>> Zohar <[e-mail]>; David Howells <[e-mail]>; 
>>> James
>>> Morris <[e-mail]>; Eric Biggers <[e-mail]>; Serge 
>>> E.
>>> Hallyn <[e-mail]>; Jan Luebbe <[e-mail]>; David 
>>> Gstir
>>> <[e-mail]>; Richard Weinberger <[e-mail]>; Franck
>>> Lenormand <[e-mail]>; Matthias Schiffer
>>> <[e-mail]>; Sumit Garg 
>>> <[e-mail]>;
>>> [e-mail]; [e-mail]; linux-
>>> [e-mail]; [e-mail]; linux-security-
>>> [e-mail]
>>> 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/[e-mail]/#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.

Horia

Michael Walle May 11, 2022, 9:59 a.m. UTC | #7

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 <[e-mail]>
>>>> Sent: Monday, May 9, 2022 6:34 PM
>>>> To: Pankaj Gupta <[e-mail]>; Horia Geanta
>>>> <[e-mail]>; Herbert Xu <[e-mail]>;
>>>> David S.
>>>> Miller <[e-mail]>
>>>> Cc: [e-mail]; Michael Walle <[e-mail]>; James
>>>> Bottomley <[e-mail]>; Jarkko Sakkinen <[e-mail]>;
>>>> Mimi
>>>> Zohar <[e-mail]>; David Howells <[e-mail]>;
>>>> James
>>>> Morris <[e-mail]>; Eric Biggers <[e-mail]>; 
>>>> Serge
>>>> E.
>>>> Hallyn <[e-mail]>; Jan Luebbe <[e-mail]>; 
>>>> David
>>>> Gstir
>>>> <[e-mail]>; Richard Weinberger <[e-mail]>; Franck
>>>> Lenormand <[e-mail]>; Matthias Schiffer
>>>> <[e-mail]>; Sumit Garg
>>>> <[e-mail]>;
>>>> [e-mail]; [e-mail]; linux-
>>>> [e-mail]; [e-mail]; 
>>>> linux-security-
>>>> [e-mail]
>>>> 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/[e-mail]/#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

Horia Geanta May 11, 2022, 10:28 a.m. UTC | #8

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 <[e-mail]>
>>>>> Sent: Monday, May 9, 2022 6:34 PM
>>>>> To: Pankaj Gupta <[e-mail]>; Horia Geanta
>>>>> <[e-mail]>; Herbert Xu <[e-mail]>;
>>>>> David S.
>>>>> Miller <[e-mail]>
>>>>> Cc: [e-mail]; Michael Walle <[e-mail]>; James
>>>>> Bottomley <[e-mail]>; Jarkko Sakkinen <[e-mail]>;
>>>>> Mimi
>>>>> Zohar <[e-mail]>; David Howells <[e-mail]>;
>>>>> James
>>>>> Morris <[e-mail]>; Eric Biggers <[e-mail]>; 
>>>>> Serge
>>>>> E.
>>>>> Hallyn <[e-mail]>; Jan Luebbe <[e-mail]>; 
>>>>> David
>>>>> Gstir
>>>>> <[e-mail]>; Richard Weinberger <[e-mail]>; Franck
>>>>> Lenormand <[e-mail]>; Matthias Schiffer
>>>>> <[e-mail]>; Sumit Garg
>>>>> <[e-mail]>;
>>>>> [e-mail]; [e-mail]; linux-
>>>>> [e-mail]; [e-mail]; 
>>>>> linux-security-
>>>>> [e-mail]
>>>>> 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/[e-mail]/#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

Michael Walle May 11, 2022, 11:54 a.m. UTC | #9

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/[e-mail]/#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

Horia Geanta May 12, 2022, 7:07 a.m. UTC | #10

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/[e-mail]/#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

Patch

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index ca0361b2dbb0..6426ffec5980 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -820,12 +820,18 @@  static int caam_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	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;
-	else
+	} else {
 		rng_vid = (rd_reg32(&ctrl->vreg.rng) & CHA_VER_VID_MASK) >>
 			   CHA_VER_VID_SHIFT;
+		ctrlpriv->blob_present = ctrlpriv->blob_present &&
+			(rd_reg32(&ctrl->vreg.aesa) & CHA_VER_MISC_AES_NUM_MASK);
+	}
 
 	/*
 	 * If SEC has RNG version >= 4 and RNG state handle has not been
diff --git a/drivers/crypto/caam/intern.h b/drivers/crypto/caam/intern.h
index 7d45b21bd55a..e92210e2ab76 100644
--- a/drivers/crypto/caam/intern.h
+++ b/drivers/crypto/caam/intern.h
@@ -92,6 +92,7 @@  struct caam_drv_private {
 	 */
 	u8 total_jobrs;		/* Total Job Rings in device */
 	u8 qi_present;		/* Nonzero if QI present in device */
+	u8 blob_present;	/* Nonzero if BLOB support present in device */
 	u8 mc_en;		/* Nonzero if MC f/w is active */
 	int secvio_irq;		/* Security violation interrupt number */
 	int virt_en;		/* Virtualization enabled in CAAM */
diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index 3738625c0250..66d6dad841bb 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -320,7 +320,8 @@  struct version_regs {
 #define CHA_VER_VID_MASK	(0xffull << CHA_VER_VID_SHIFT)
 
 /* CHA Miscellaneous Information - AESA_MISC specific */
-#define CHA_VER_MISC_AES_GCM	BIT(1 + CHA_VER_MISC_SHIFT)
+#define CHA_VER_MISC_AES_NUM_MASK	GENMASK(7, 0)
+#define CHA_VER_MISC_AES_GCM		BIT(1 + CHA_VER_MISC_SHIFT)
 
 /* CHA Miscellaneous Information - PKHA_MISC specific */
 #define CHA_VER_MISC_PKHA_NO_CRYPT	BIT(7 + CHA_VER_MISC_SHIFT)
@@ -414,6 +415,7 @@  struct caam_perfmon {
 #define CTPR_MS_PG_SZ_MASK	0x10
 #define CTPR_MS_PG_SZ_SHIFT	4
 	u32 comp_parms_ms;	/* CTPR - Compile Parameters Register	*/
+#define CTPR_LS_BLOB           BIT(1)
 	u32 comp_parms_ls;	/* CTPR - Compile Parameters Register	*/
 	u64 rsvd1[2];