[0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

Message

Ahmad Fatoum July 21, 2021, 4:48 p.m. UTC

Series applies on top of
https://lore.kernel.org/linux-integrity/[e-mail]/T/#u

v2 -> v3:
 - Split off first Kconfig preparation patch. It fixes a regression,
   so sent that out, so it can be applied separately (Sumit)
 - Split off second key import patch. I'll send that out separately
   as it's a development aid and not required within the CAAM series
 - add MAINTAINERS entry

v1 -> v2:
 - Added new commit to make trusted key Kconfig option independent
   of TPM and added new Kconfig file for trusted keys
 - Add new commit for importing existing key material
 - Allow users to force use of kernel RNG (Jarkko)
 - Enforce maximum keymod size (Horia)
 - Use append_seq_(in|out)_ptr_intlen instead of append_seq_(in|out)_ptr
   (Horia)
 - Make blobifier handle private to CAAM glue code file (Horia)
 - Extend trusted keys documentation for CAAM
 - Rebased and updated original cover letter:

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 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.MX6DL.

Looking forward to your feedback.

Cheers,
Ahmad

 [1]: https://lore.kernel.org/linux-crypto/[e-mail]/
 [2]: https://lore.kernel.org/linux-integrity/[e-mail]/
 [3]: https://lore.kernel.org/lkml/[e-mail]/
 [4]: https://lore.kernel.org/lkml/[e-mail]/
 [5]: https://lore.kernel.org/linux-integrity/[e-mail]/

---
To: Jarkko Sakkinen <[e-mail]>
To: "Horia Geantă" <[e-mail]>
To: Mimi Zohar <[e-mail]>
To: Aymen Sghaier <[e-mail]>
To: Herbert Xu <[e-mail]>
To: "David S. Miller" <[e-mail]>
To: James Bottomley <[e-mail]>
Cc: David Howells <[e-mail]>
Cc: James Morris <[e-mail]>
Cc: "Serge E. Hallyn" <[e-mail]>
Cc: Steffen Trumtrar <[e-mail]>
Cc: Udit Agarwal <[e-mail]>
Cc: Jan Luebbe <[e-mail]>
Cc: David Gstir <[e-mail]>
Cc: Eric Biggers <[e-mail]>
Cc: Richard Weinberger <[e-mail]>
Cc: Franck LENORMAND <[e-mail]>
Cc: Sumit Garg <[e-mail]>
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]

Ahmad Fatoum (4):
  KEYS: trusted: allow users to use kernel RNG for key material
  KEYS: trusted: allow trust sources to use kernel RNG for key material
  crypto: caam - add in-kernel interface for blob generator
  KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

 Documentation/admin-guide/kernel-parameters.txt   |   8 +-
 Documentation/security/keys/trusted-encrypted.rst |  60 +++-
 MAINTAINERS                                       |   9 +-
 drivers/crypto/caam/Kconfig                       |   3 +-
 drivers/crypto/caam/Makefile                      |   1 +-
 drivers/crypto/caam/blob_gen.c                    | 230 +++++++++++++++-
 include/keys/trusted-type.h                       |   2 +-
 include/keys/trusted_caam.h                       |  11 +-
 include/soc/fsl/caam-blob.h                       |  56 ++++-
 security/keys/trusted-keys/Kconfig                |  11 +-
 security/keys/trusted-keys/Makefile               |   2 +-
 security/keys/trusted-keys/trusted_caam.c         |  74 +++++-
 security/keys/trusted-keys/trusted_core.c         |  23 +-
 13 files changed, 477 insertions(+), 13 deletions(-)
 create mode 100644 drivers/crypto/caam/blob_gen.c
 create mode 100644 include/keys/trusted_caam.h
 create mode 100644 include/soc/fsl/caam-blob.h
 create mode 100644 security/keys/trusted-keys/trusted_caam.c

base-commit: 97408d81ed533b953326c580ff2c3f1948b3fcee

Comments

Ahmad Fatoum Aug. 6, 2021, 3:12 p.m. UTC | #1

Dear trusted key maintainers,

On 21.07.21 18:48, Ahmad Fatoum wrote:
> Series applies on top of
> https://lore.kernel.org/linux-integrity/[e-mail]/T/#u
> 
> v2 -> v3:
>  - Split off first Kconfig preparation patch. It fixes a regression,
>    so sent that out, so it can be applied separately (Sumit)
>  - Split off second key import patch. I'll send that out separately
>    as it's a development aid and not required within the CAAM series
>  - add MAINTAINERS entry

Gentle ping. I'd appreciate feedback on this series.

Cheers,
Ahmad

> 
> v1 -> v2:
>  - Added new commit to make trusted key Kconfig option independent
>    of TPM and added new Kconfig file for trusted keys
>  - Add new commit for importing existing key material
>  - Allow users to force use of kernel RNG (Jarkko)
>  - Enforce maximum keymod size (Horia)
>  - Use append_seq_(in|out)_ptr_intlen instead of append_seq_(in|out)_ptr
>    (Horia)
>  - Make blobifier handle private to CAAM glue code file (Horia)
>  - Extend trusted keys documentation for CAAM
>  - Rebased and updated original cover letter:
> 
> 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 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.MX6DL.
> 
> Looking forward to your feedback.
> 
> Cheers,
> Ahmad
> 
>  [1]: https://lore.kernel.org/linux-crypto/[e-mail]/
>  [2]: https://lore.kernel.org/linux-integrity/[e-mail]/
>  [3]: https://lore.kernel.org/lkml/[e-mail]/
>  [4]: https://lore.kernel.org/lkml/[e-mail]/
>  [5]: https://lore.kernel.org/linux-integrity/[e-mail]/
> 
> ---
> To: Jarkko Sakkinen <[e-mail]>
> To: "Horia Geantă" <[e-mail]>
> To: Mimi Zohar <[e-mail]>
> To: Aymen Sghaier <[e-mail]>
> To: Herbert Xu <[e-mail]>
> To: "David S. Miller" <[e-mail]>
> To: James Bottomley <[e-mail]>
> Cc: David Howells <[e-mail]>
> Cc: James Morris <[e-mail]>
> Cc: "Serge E. Hallyn" <[e-mail]>
> Cc: Steffen Trumtrar <[e-mail]>
> Cc: Udit Agarwal <[e-mail]>
> Cc: Jan Luebbe <[e-mail]>
> Cc: David Gstir <[e-mail]>
> Cc: Eric Biggers <[e-mail]>
> Cc: Richard Weinberger <[e-mail]>
> Cc: Franck LENORMAND <[e-mail]>
> Cc: Sumit Garg <[e-mail]>
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> 
> Ahmad Fatoum (4):
>   KEYS: trusted: allow users to use kernel RNG for key material
>   KEYS: trusted: allow trust sources to use kernel RNG for key material
>   crypto: caam - add in-kernel interface for blob generator
>   KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
> 
>  Documentation/admin-guide/kernel-parameters.txt   |   8 +-
>  Documentation/security/keys/trusted-encrypted.rst |  60 +++-
>  MAINTAINERS                                       |   9 +-
>  drivers/crypto/caam/Kconfig                       |   3 +-
>  drivers/crypto/caam/Makefile                      |   1 +-
>  drivers/crypto/caam/blob_gen.c                    | 230 +++++++++++++++-
>  include/keys/trusted-type.h                       |   2 +-
>  include/keys/trusted_caam.h                       |  11 +-
>  include/soc/fsl/caam-blob.h                       |  56 ++++-
>  security/keys/trusted-keys/Kconfig                |  11 +-
>  security/keys/trusted-keys/Makefile               |   2 +-
>  security/keys/trusted-keys/trusted_caam.c         |  74 +++++-
>  security/keys/trusted-keys/trusted_core.c         |  23 +-
>  13 files changed, 477 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/crypto/caam/blob_gen.c
>  create mode 100644 include/keys/trusted_caam.h
>  create mode 100644 include/soc/fsl/caam-blob.h
>  create mode 100644 security/keys/trusted-keys/trusted_caam.c
> 
> base-commit: 97408d81ed533b953326c580ff2c3f1948b3fcee
>

Jarkko Sakkinen Aug. 9, 2021, 9:35 a.m. UTC | #2

On Fri, Aug 06, 2021 at 05:12:19PM +0200, Ahmad Fatoum wrote:
> Dear trusted key maintainers,
> 
> On 21.07.21 18:48, Ahmad Fatoum wrote:
> > Series applies on top of
> > https://lore.kernel.org/linux-integrity/[e-mail]/T/#u
> > 
> > v2 -> v3:
> >  - Split off first Kconfig preparation patch. It fixes a regression,
> >    so sent that out, so it can be applied separately (Sumit)
> >  - Split off second key import patch. I'll send that out separately
> >    as it's a development aid and not required within the CAAM series
> >  - add MAINTAINERS entry
> 
> Gentle ping. I'd appreciate feedback on this series.

Simple question: what is fscrypt?

/Jarkko

Ahmad Fatoum Aug. 9, 2021, 10:16 a.m. UTC | #3

On 09.08.21 11:35, Jarkko Sakkinen wrote:
> On Fri, Aug 06, 2021 at 05:12:19PM +0200, Ahmad Fatoum wrote:
>> Dear trusted key maintainers,
>>
>> On 21.07.21 18:48, Ahmad Fatoum wrote:
>>> Series applies on top of
>>> https://lore.kernel.org/linux-integrity/[e-mail]/T/#u
>>>
>>> v2 -> v3:
>>>  - Split off first Kconfig preparation patch. It fixes a regression,
>>>    so sent that out, so it can be applied separately (Sumit)
>>>  - Split off second key import patch. I'll send that out separately
>>>    as it's a development aid and not required within the CAAM series
>>>  - add MAINTAINERS entry
>>
>> Gentle ping. I'd appreciate feedback on this series.
> 
> Simple question: what is fscrypt?

For supported file systems, fscrypt[1] allows you to encrypt at a directory level.
It has no trusted key integration yet, which is something I am trying to upstream
in parallel to this series, so I eventually can use fscrypt together with CAAM-backed
trusted keys on an unpatched kernel.

If it interests you, I described[2] my CAAM+ubifs+fscrypt use case in the
discussion thread on my fscrypt-trusted-keys v1. Jan, a colleague of mine, held a
talk[3] on the different solutions for authenticated and encrypted storage, which
you may want to check out.

I'd really appreciate feedback here on the the CAAM parts of this series, so this can
eventually go mainline.

Thanks,
Ahmad


[1]: https://www.kernel.org/doc/html/v5.13/filesystems/fscrypt.html
[2]: https://lore.kernel.org/linux-fscrypt/[e-mail]/
[3]: https://www.youtube.com/watch?v=z_y84v9076c

> 
> /Jarkko
>

David Gstir Aug. 10, 2021, 11:28 a.m. UTC | #4

Hi Ahmad,

> On 09.08.2021, at 12:16, Ahmad Fatoum <[e-mail]> wrote:

[...]

> If it interests you, I described[2] my CAAM+ubifs+fscrypt use case in the
> discussion thread on my fscrypt-trusted-keys v1. Jan, a colleague of mine, held a
> talk[3] on the different solutions for authenticated and encrypted storage, which
> you may want to check out.
>
> I'd really appreciate feedback here on the the CAAM parts of this series, so this can
> eventually go mainline.

Since you mention the fscrypt trusted-keys use case:

I noticed that the key length for trusted-keys is limited to
256 - 1024bit keys. fscrypt does however also support keys
with e.g. 128bit keys (AES-128-CBC-ESSIV, AES-128-CTS-CBC).
AFAIK, CAAM and TEE key blobs would also support key lengths outside the 256 - 1024bit range.

Wouldn’t it make sense to align the supported key lengths?
I.e. extend the range of supported key lengths for trusted keys.
Or is there a specific reason why key lengths below 256bit are
not supported by trusted-keys?

Cheers,
David

Tim Harvey Aug. 20, 2021, 3:39 p.m. UTC | #5

On Wed, Jul 21, 2021 at 9:49 AM Ahmad Fatoum <[e-mail]> wrote:
>
> Series applies on top of
> https://lore.kernel.org/linux-integrity/[e-mail]/T/#u
>
> v2 -> v3:
>  - Split off first Kconfig preparation patch. It fixes a regression,
>    so sent that out, so it can be applied separately (Sumit)
>  - Split off second key import patch. I'll send that out separately
>    as it's a development aid and not required within the CAAM series
>  - add MAINTAINERS entry
>
> v1 -> v2:
>  - Added new commit to make trusted key Kconfig option independent
>    of TPM and added new Kconfig file for trusted keys
>  - Add new commit for importing existing key material
>  - Allow users to force use of kernel RNG (Jarkko)
>  - Enforce maximum keymod size (Horia)
>  - Use append_seq_(in|out)_ptr_intlen instead of append_seq_(in|out)_ptr
>    (Horia)
>  - Make blobifier handle private to CAAM glue code file (Horia)
>  - Extend trusted keys documentation for CAAM
>  - Rebased and updated original cover letter:
>
> 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 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.MX6DL.
>
> Looking forward to your feedback.
>
> Cheers,
> Ahmad
>
>  [1]: https://lore.kernel.org/linux-crypto/[e-mail]/
>  [2]: https://lore.kernel.org/linux-integrity/[e-mail]/
>  [3]: https://lore.kernel.org/lkml/[e-mail]/
>  [4]: https://lore.kernel.org/lkml/[e-mail]/
>  [5]: https://lore.kernel.org/linux-integrity/[e-mail]/
>
> ---
> To: Jarkko Sakkinen <[e-mail]>
> To: "Horia Geantă" <[e-mail]>
> To: Mimi Zohar <[e-mail]>
> To: Aymen Sghaier <[e-mail]>
> To: Herbert Xu <[e-mail]>
> To: "David S. Miller" <[e-mail]>
> To: James Bottomley <[e-mail]>
> Cc: David Howells <[e-mail]>
> Cc: James Morris <[e-mail]>
> Cc: "Serge E. Hallyn" <[e-mail]>
> Cc: Steffen Trumtrar <[e-mail]>
> Cc: Udit Agarwal <[e-mail]>
> Cc: Jan Luebbe <[e-mail]>
> Cc: David Gstir <[e-mail]>
> Cc: Eric Biggers <[e-mail]>
> Cc: Richard Weinberger <[e-mail]>
> Cc: Franck LENORMAND <[e-mail]>
> Cc: Sumit Garg <[e-mail]>
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
>
> Ahmad Fatoum (4):
>   KEYS: trusted: allow users to use kernel RNG for key material
>   KEYS: trusted: allow trust sources to use kernel RNG for key material
>   crypto: caam - add in-kernel interface for blob generator
>   KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
>
>  Documentation/admin-guide/kernel-parameters.txt   |   8 +-
>  Documentation/security/keys/trusted-encrypted.rst |  60 +++-
>  MAINTAINERS                                       |   9 +-
>  drivers/crypto/caam/Kconfig                       |   3 +-
>  drivers/crypto/caam/Makefile                      |   1 +-
>  drivers/crypto/caam/blob_gen.c                    | 230 +++++++++++++++-
>  include/keys/trusted-type.h                       |   2 +-
>  include/keys/trusted_caam.h                       |  11 +-
>  include/soc/fsl/caam-blob.h                       |  56 ++++-
>  security/keys/trusted-keys/Kconfig                |  11 +-
>  security/keys/trusted-keys/Makefile               |   2 +-
>  security/keys/trusted-keys/trusted_caam.c         |  74 +++++-
>  security/keys/trusted-keys/trusted_core.c         |  23 +-
>  13 files changed, 477 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/crypto/caam/blob_gen.c
>  create mode 100644 include/keys/trusted_caam.h
>  create mode 100644 include/soc/fsl/caam-blob.h
>  create mode 100644 security/keys/trusted-keys/trusted_caam.c
>
> base-commit: 97408d81ed533b953326c580ff2c3f1948b3fcee
> --
> git-series 0.9.1

Ahmad,

Thanks for your work!

I've been asked to integrate the capability of using CAAM to
blob/deblob data to an older 5.4 kernel such as NXP's downstream
vendor kernel does [1] and I'm trying to understand how your series
works. I'm not at all familiar with the Linux Key Management API's or
trusted keys. Can you provide an example of how this can be used for
such a thing?

Best regards,

Tim
[1] https://source.codeaurora.org/external/imxsupport/imx_sec_apps/tree/demo-caam-blobs/README.txt

Ahmad Fatoum Aug. 20, 2021, 4:19 p.m. UTC | #6

Hello Tim,

On 20.08.21 17:39, Tim Harvey wrote:
> On Wed, Jul 21, 2021 at 9:49 AM Ahmad Fatoum <[e-mail]> wrote:
>>
>> Series applies on top of
>> https://lore.kernel.org/linux-integrity/[e-mail]/T/#u
>>
>> v2 -> v3:
>>  - Split off first Kconfig preparation patch. It fixes a regression,
>>    so sent that out, so it can be applied separately (Sumit)
>>  - Split off second key import patch. I'll send that out separately
>>    as it's a development aid and not required within the CAAM series
>>  - add MAINTAINERS entry
>>
>> v1 -> v2:
>>  - Added new commit to make trusted key Kconfig option independent
>>    of TPM and added new Kconfig file for trusted keys
>>  - Add new commit for importing existing key material
>>  - Allow users to force use of kernel RNG (Jarkko)
>>  - Enforce maximum keymod size (Horia)
>>  - Use append_seq_(in|out)_ptr_intlen instead of append_seq_(in|out)_ptr
>>    (Horia)
>>  - Make blobifier handle private to CAAM glue code file (Horia)
>>  - Extend trusted keys documentation for CAAM
>>  - Rebased and updated original cover letter:
>>
>> 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 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.MX6DL.
>>
>> Looking forward to your feedback.
>>
>> Cheers,
>> Ahmad
>>
>>  [1]: https://lore.kernel.org/linux-crypto/[e-mail]/
>>  [2]: https://lore.kernel.org/linux-integrity/[e-mail]/
>>  [3]: https://lore.kernel.org/lkml/[e-mail]/
>>  [4]: https://lore.kernel.org/lkml/[e-mail]/
>>  [5]: https://lore.kernel.org/linux-integrity/[e-mail]/
>>
>> ---
>> To: Jarkko Sakkinen <[e-mail]>
>> To: "Horia Geantă" <[e-mail]>
>> To: Mimi Zohar <[e-mail]>
>> To: Aymen Sghaier <[e-mail]>
>> To: Herbert Xu <[e-mail]>
>> To: "David S. Miller" <[e-mail]>
>> To: James Bottomley <[e-mail]>
>> Cc: David Howells <[e-mail]>
>> Cc: James Morris <[e-mail]>
>> Cc: "Serge E. Hallyn" <[e-mail]>
>> Cc: Steffen Trumtrar <[e-mail]>
>> Cc: Udit Agarwal <[e-mail]>
>> Cc: Jan Luebbe <[e-mail]>
>> Cc: David Gstir <[e-mail]>
>> Cc: Eric Biggers <[e-mail]>
>> Cc: Richard Weinberger <[e-mail]>
>> Cc: Franck LENORMAND <[e-mail]>
>> Cc: Sumit Garg <[e-mail]>
>> Cc: [e-mail]
>> Cc: [e-mail]
>> Cc: [e-mail]
>> Cc: [e-mail]
>> Cc: [e-mail]
>>
>> Ahmad Fatoum (4):
>>   KEYS: trusted: allow users to use kernel RNG for key material
>>   KEYS: trusted: allow trust sources to use kernel RNG for key material
>>   crypto: caam - add in-kernel interface for blob generator
>>   KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
>>
>>  Documentation/admin-guide/kernel-parameters.txt   |   8 +-
>>  Documentation/security/keys/trusted-encrypted.rst |  60 +++-
>>  MAINTAINERS                                       |   9 +-
>>  drivers/crypto/caam/Kconfig                       |   3 +-
>>  drivers/crypto/caam/Makefile                      |   1 +-
>>  drivers/crypto/caam/blob_gen.c                    | 230 +++++++++++++++-
>>  include/keys/trusted-type.h                       |   2 +-
>>  include/keys/trusted_caam.h                       |  11 +-
>>  include/soc/fsl/caam-blob.h                       |  56 ++++-
>>  security/keys/trusted-keys/Kconfig                |  11 +-
>>  security/keys/trusted-keys/Makefile               |   2 +-
>>  security/keys/trusted-keys/trusted_caam.c         |  74 +++++-
>>  security/keys/trusted-keys/trusted_core.c         |  23 +-
>>  13 files changed, 477 insertions(+), 13 deletions(-)
>>  create mode 100644 drivers/crypto/caam/blob_gen.c
>>  create mode 100644 include/keys/trusted_caam.h
>>  create mode 100644 include/soc/fsl/caam-blob.h
>>  create mode 100644 security/keys/trusted-keys/trusted_caam.c
>>
>> base-commit: 97408d81ed533b953326c580ff2c3f1948b3fcee
>> --
>> git-series 0.9.1
> 
> Ahmad,
> 
> Thanks for your work!
> 
> I've been asked to integrate the capability of using CAAM to
> blob/deblob data to an older 5.4 kernel such as NXP's downstream
> vendor kernel does [1] and I'm trying to understand how your series
> works. I'm not at all familiar with the Linux Key Management API's or
> trusted keys. Can you provide an example of how this can be used for
> such a thing?

Here's an example with dm-crypt:

  https://lore.kernel.org/linux-integrity/[e-mail]/

dm-crypt is a bit special at the moment, because it has direct support for
trusted keys. For interfacing with other parts of the kernel like ecryptfs
or EVM, you have to create encrypted keys rooted to the trusted keys and use
those. The kernel documentation has an example:

  https://www.kernel.org/doc/html/v5.13/security/keys/trusted-encrypted.html

If you backport this series, you can include the typo fix spotted by David.

I'll send out a revised series, but given that a regression fix I want to
rebase on hasn't been picked up for 3 weeks now, I am not in a hurry.

Cheers,
Ahmad

> 
> Best regards,
> 
> Tim
> [1] https://source.codeaurora.org/external/imxsupport/imx_sec_apps/tree/demo-caam-blobs/README.txt
> 
>

Ahmad Fatoum Aug. 20, 2021, 4:25 p.m. UTC | #7

Hello David,

On 10.08.21 13:28, David Gstir wrote:
> Hi Ahmad,
> 
>> On 09.08.2021, at 12:16, Ahmad Fatoum <[e-mail]> wrote:
> 
> [...]
> 
>> If it interests you, I described[2] my CAAM+ubifs+fscrypt use case in the
>> discussion thread on my fscrypt-trusted-keys v1. Jan, a colleague of mine, held a
>> talk[3] on the different solutions for authenticated and encrypted storage, which
>> you may want to check out.
>>
>> I'd really appreciate feedback here on the the CAAM parts of this series, so this can
>> eventually go mainline.
> 
> Since you mention the fscrypt trusted-keys use case:
> 
> I noticed that the key length for trusted-keys is limited to
> 256 - 1024bit keys. fscrypt does however also support keys
> with e.g. 128bit keys (AES-128-CBC-ESSIV, AES-128-CTS-CBC).
> AFAIK, CAAM and TEE key blobs would also support key lengths outside the 256 - 1024bit range.
> 
> Wouldn’t it make sense to align the supported key lengths?
> I.e. extend the range of supported key lengths for trusted keys.
> Or is there a specific reason why key lengths below 256bit are
> not supported by trusted-keys?

No idea. I would suggest staying clear about arguing in its favor though
until CAAM and DCP are merged. My parallel fscrypt endeavors seem to have
only diverted maintainer attention. ;-)

Cheers,
Ahmad

> 
> Cheers,
> David
> 
> 
>

Tim Harvey Aug. 20, 2021, 8:20 p.m. UTC | #8

On Fri, Aug 20, 2021 at 9:20 AM Ahmad Fatoum <[e-mail]> wrote:
>
> Hello Tim,
>
> On 20.08.21 17:39, Tim Harvey wrote:
> > On Wed, Jul 21, 2021 at 9:49 AM Ahmad Fatoum <[e-mail]> wrote:
> >>
> >> Series applies on top of
> >> https://lore.kernel.org/linux-integrity/[e-mail]/T/#u
> >>
> >> v2 -> v3:
> >>  - Split off first Kconfig preparation patch. It fixes a regression,
> >>    so sent that out, so it can be applied separately (Sumit)
> >>  - Split off second key import patch. I'll send that out separately
> >>    as it's a development aid and not required within the CAAM series
> >>  - add MAINTAINERS entry
> >>
> >> v1 -> v2:
> >>  - Added new commit to make trusted key Kconfig option independent
> >>    of TPM and added new Kconfig file for trusted keys
> >>  - Add new commit for importing existing key material
> >>  - Allow users to force use of kernel RNG (Jarkko)
> >>  - Enforce maximum keymod size (Horia)
> >>  - Use append_seq_(in|out)_ptr_intlen instead of append_seq_(in|out)_ptr
> >>    (Horia)
> >>  - Make blobifier handle private to CAAM glue code file (Horia)
> >>  - Extend trusted keys documentation for CAAM
> >>  - Rebased and updated original cover letter:
> >>
> >> 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 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.MX6DL.
> >>
> >> Looking forward to your feedback.
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>  [1]: https://lore.kernel.org/linux-crypto/[e-mail]/
> >>  [2]: https://lore.kernel.org/linux-integrity/[e-mail]/
> >>  [3]: https://lore.kernel.org/lkml/[e-mail]/
> >>  [4]: https://lore.kernel.org/lkml/[e-mail]/
> >>  [5]: https://lore.kernel.org/linux-integrity/[e-mail]/
> >>
> >> ---
> >> To: Jarkko Sakkinen <[e-mail]>
> >> To: "Horia Geantă" <[e-mail]>
> >> To: Mimi Zohar <[e-mail]>
> >> To: Aymen Sghaier <[e-mail]>
> >> To: Herbert Xu <[e-mail]>
> >> To: "David S. Miller" <[e-mail]>
> >> To: James Bottomley <[e-mail]>
> >> Cc: David Howells <[e-mail]>
> >> Cc: James Morris <[e-mail]>
> >> Cc: "Serge E. Hallyn" <[e-mail]>
> >> Cc: Steffen Trumtrar <[e-mail]>
> >> Cc: Udit Agarwal <[e-mail]>
> >> Cc: Jan Luebbe <[e-mail]>
> >> Cc: David Gstir <[e-mail]>
> >> Cc: Eric Biggers <[e-mail]>
> >> Cc: Richard Weinberger <[e-mail]>
> >> Cc: Franck LENORMAND <[e-mail]>
> >> Cc: Sumit Garg <[e-mail]>
> >> Cc: [e-mail]
> >> Cc: [e-mail]
> >> Cc: [e-mail]
> >> Cc: [e-mail]
> >> Cc: [e-mail]
> >>
> >> Ahmad Fatoum (4):
> >>   KEYS: trusted: allow users to use kernel RNG for key material
> >>   KEYS: trusted: allow trust sources to use kernel RNG for key material
> >>   crypto: caam - add in-kernel interface for blob generator
> >>   KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
> >>
> >>  Documentation/admin-guide/kernel-parameters.txt   |   8 +-
> >>  Documentation/security/keys/trusted-encrypted.rst |  60 +++-
> >>  MAINTAINERS                                       |   9 +-
> >>  drivers/crypto/caam/Kconfig                       |   3 +-
> >>  drivers/crypto/caam/Makefile                      |   1 +-
> >>  drivers/crypto/caam/blob_gen.c                    | 230 +++++++++++++++-
> >>  include/keys/trusted-type.h                       |   2 +-
> >>  include/keys/trusted_caam.h                       |  11 +-
> >>  include/soc/fsl/caam-blob.h                       |  56 ++++-
> >>  security/keys/trusted-keys/Kconfig                |  11 +-
> >>  security/keys/trusted-keys/Makefile               |   2 +-
> >>  security/keys/trusted-keys/trusted_caam.c         |  74 +++++-
> >>  security/keys/trusted-keys/trusted_core.c         |  23 +-
> >>  13 files changed, 477 insertions(+), 13 deletions(-)
> >>  create mode 100644 drivers/crypto/caam/blob_gen.c
> >>  create mode 100644 include/keys/trusted_caam.h
> >>  create mode 100644 include/soc/fsl/caam-blob.h
> >>  create mode 100644 security/keys/trusted-keys/trusted_caam.c
> >>
> >> base-commit: 97408d81ed533b953326c580ff2c3f1948b3fcee
> >> --
> >> git-series 0.9.1
> >
> > Ahmad,
> >
> > Thanks for your work!
> >
> > I've been asked to integrate the capability of using CAAM to
> > blob/deblob data to an older 5.4 kernel such as NXP's downstream
> > vendor kernel does [1] and I'm trying to understand how your series
> > works. I'm not at all familiar with the Linux Key Management API's or
> > trusted keys. Can you provide an example of how this can be used for
> > such a thing?
>
> Here's an example with dm-crypt:
>
>   https://lore.kernel.org/linux-integrity/[e-mail]/
>
> dm-crypt is a bit special at the moment, because it has direct support for
> trusted keys. For interfacing with other parts of the kernel like ecryptfs
> or EVM, you have to create encrypted keys rooted to the trusted keys and use
> those. The kernel documentation has an example:
>
>   https://www.kernel.org/doc/html/v5.13/security/keys/trusted-encrypted.html
>
> If you backport this series, you can include the typo fix spotted by David.
>
> I'll send out a revised series, but given that a regression fix I want to
> rebase on hasn't been picked up for 3 weeks now, I am not in a hurry.
>

Ahmad,

Thanks for the reference.

I'm still trying to understand the keyctl integration with caam. For
the 'data' param to keyctl you are using tings like 'new <len>' and
'load <data>'. Where are these 'commands' identified?

I may still be missing something. I'm using 4.14-rc6 with your series
and seeing the following:
# cat /proc/cmdline
trusted.source=caam
# keyctl add trusted mykey 'new 32' @s)# create new trusted key named
'mykey' of 32 bytes in the session keyring
480104283
# keyctl print 480104283 # dump the key
keyctl_read_alloc: Unknown error 126
^^^ not clear what this is

Best regards,

Tim

Ahmad Fatoum Aug. 20, 2021, 8:36 p.m. UTC | #9

On 20.08.21 22:20, Tim Harvey wrote:
> On Fri, Aug 20, 2021 at 9:20 AM Ahmad Fatoum <[e-mail]> wrote:
>> On 20.08.21 17:39, Tim Harvey wrote:
>>> Thanks for your work!
>>>
>>> I've been asked to integrate the capability of using CAAM to
>>> blob/deblob data to an older 5.4 kernel such as NXP's downstream
>>> vendor kernel does [1] and I'm trying to understand how your series
>>> works. I'm not at all familiar with the Linux Key Management API's or
>>> trusted keys. Can you provide an example of how this can be used for
>>> such a thing?
>>
>> Here's an example with dm-crypt:
>>
>>   https://lore.kernel.org/linux-integrity/[e-mail]/
>>
>> dm-crypt is a bit special at the moment, because it has direct support for
>> trusted keys. For interfacing with other parts of the kernel like ecryptfs
>> or EVM, you have to create encrypted keys rooted to the trusted keys and use
>> those. The kernel documentation has an example:
>>
>>   https://www.kernel.org/doc/html/v5.13/security/keys/trusted-encrypted.html
>>
>> If you backport this series, you can include the typo fix spotted by David.
>>
>> I'll send out a revised series, but given that a regression fix I want to
>> rebase on hasn't been picked up for 3 weeks now, I am not in a hurry.
>>
> Thanks for the reference.
> 
> I'm still trying to understand the keyctl integration with caam. For
> the 'data' param to keyctl you are using tings like 'new <len>' and
> 'load <data>'. Where are these 'commands' identified?

Search for match_table_t in security/keys/trusted-keys/trusted_core.c

> I may still be missing something. I'm using 4.14-rc6 with your series
> and seeing the following:

That's an odd version to backport stuff to..

> # cat /proc/cmdline
> trusted.source=caam
> # keyctl add trusted mykey 'new 32' @s)# create new trusted key named
> 'mykey' of 32 bytes in the session keyring
> 480104283
> # keyctl print 480104283 # dump the key
> keyctl_read_alloc: Unknown error 126
> ^^^ not clear what this is

Not sure what returns -ENOKEY for you. I haven't been using trusted
keys on v4.14, but you can try tracing the keyctl syscall.

Cheers,
Ahmad

> 
> Best regards,
> 
> Tim
>

Tim Harvey Aug. 20, 2021, 9:19 p.m. UTC | #10

On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <[e-mail]> wrote:
>
> On 20.08.21 22:20, Tim Harvey wrote:
> > On Fri, Aug 20, 2021 at 9:20 AM Ahmad Fatoum <[e-mail]> wrote:
> >> On 20.08.21 17:39, Tim Harvey wrote:
> >>> Thanks for your work!
> >>>
> >>> I've been asked to integrate the capability of using CAAM to
> >>> blob/deblob data to an older 5.4 kernel such as NXP's downstream
> >>> vendor kernel does [1] and I'm trying to understand how your series
> >>> works. I'm not at all familiar with the Linux Key Management API's or
> >>> trusted keys. Can you provide an example of how this can be used for
> >>> such a thing?
> >>
> >> Here's an example with dm-crypt:
> >>
> >>   https://lore.kernel.org/linux-integrity/[e-mail]/
> >>
> >> dm-crypt is a bit special at the moment, because it has direct support for
> >> trusted keys. For interfacing with other parts of the kernel like ecryptfs
> >> or EVM, you have to create encrypted keys rooted to the trusted keys and use
> >> those. The kernel documentation has an example:
> >>
> >>   https://www.kernel.org/doc/html/v5.13/security/keys/trusted-encrypted.html
> >>
> >> If you backport this series, you can include the typo fix spotted by David.
> >>
> >> I'll send out a revised series, but given that a regression fix I want to
> >> rebase on hasn't been picked up for 3 weeks now, I am not in a hurry.
> >>
> > Thanks for the reference.
> >
> > I'm still trying to understand the keyctl integration with caam. For
> > the 'data' param to keyctl you are using tings like 'new <len>' and
> > 'load <data>'. Where are these 'commands' identified?
>
> Search for match_table_t in security/keys/trusted-keys/trusted_core.c
>
> > I may still be missing something. I'm using 4.14-rc6 with your series
> > and seeing the following:
>
> That's an odd version to backport stuff to..
>
> > # cat /proc/cmdline
> > trusted.source=caam
> > # keyctl add trusted mykey 'new 32' @s)# create new trusted key named
> > 'mykey' of 32 bytes in the session keyring
> > 480104283
> > # keyctl print 480104283 # dump the key
> > keyctl_read_alloc: Unknown error 126
> > ^^^ not clear what this is
>
> Not sure what returns -ENOKEY for you. I haven't been using trusted
> keys on v4.14, but you can try tracing the keyctl syscall.

yikes... that would be painful. I typo'd and meant 5.14-rc6 :) I'm
working with mainline first to make sure I understand everything. If I
backport this it would be to 5.4 but that looks to be extremely
painful. It looks like there was a lot of activity around trusted keys
in 5.13.

It works for a user keyring but not a session keyring... does that
explain anything?
# keyctl add trusted mykey 'new 32' @u
941210782
# keyctl print 941210782
83b7845cb45216496aead9ee2c6a406f587d64aad47bddc539d8947a247e618798d9306b36398b5dc2722a4c3f220a3a763ee175f6bd64758fdd49ca4db597e8ce328121b60edbba9b8d8d55056be896
# keyctl add trusted mykey 'new 32' @s
310571960
# keyctl print 310571960
keyctl_read_alloc: Unknown error 126

Sorry, I'm still trying to wrap my head around the differences in
keyrings and trusted vs user keys.

Tim

Ahmad Fatoum Aug. 23, 2021, 1:29 p.m. UTC | #11

Hello Tim,

On 20.08.21 23:19, Tim Harvey wrote:
> On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <[e-mail]> wrote:
>>
>> On 20.08.21 22:20, Tim Harvey wrote:
>>> On Fri, Aug 20, 2021 at 9:20 AM Ahmad Fatoum <[e-mail]> wrote:
>>>> On 20.08.21 17:39, Tim Harvey wrote:
>>>>> Thanks for your work!
>>>>>
>>>>> I've been asked to integrate the capability of using CAAM to
>>>>> blob/deblob data to an older 5.4 kernel such as NXP's downstream
>>>>> vendor kernel does [1] and I'm trying to understand how your series
>>>>> works. I'm not at all familiar with the Linux Key Management API's or
>>>>> trusted keys. Can you provide an example of how this can be used for
>>>>> such a thing?
>>>>
>>>> Here's an example with dm-crypt:
>>>>
>>>>   https://lore.kernel.org/linux-integrity/[e-mail]/
>>>>
>>>> dm-crypt is a bit special at the moment, because it has direct support for
>>>> trusted keys. For interfacing with other parts of the kernel like ecryptfs
>>>> or EVM, you have to create encrypted keys rooted to the trusted keys and use
>>>> those. The kernel documentation has an example:
>>>>
>>>>   https://www.kernel.org/doc/html/v5.13/security/keys/trusted-encrypted.html
>>>>
>>>> If you backport this series, you can include the typo fix spotted by David.
>>>>
>>>> I'll send out a revised series, but given that a regression fix I want to
>>>> rebase on hasn't been picked up for 3 weeks now, I am not in a hurry.
>>>>
>>> Thanks for the reference.
>>>
>>> I'm still trying to understand the keyctl integration with caam. For
>>> the 'data' param to keyctl you are using tings like 'new <len>' and
>>> 'load <data>'. Where are these 'commands' identified?
>>
>> Search for match_table_t in security/keys/trusted-keys/trusted_core.c
>>
>>> I may still be missing something. I'm using 4.14-rc6 with your series
>>> and seeing the following:
>>
>> That's an odd version to backport stuff to..
>>
>>> # cat /proc/cmdline
>>> trusted.source=caam
>>> # keyctl add trusted mykey 'new 32' @s)# create new trusted key named
>>> 'mykey' of 32 bytes in the session keyring
>>> 480104283
>>> # keyctl print 480104283 # dump the key
>>> keyctl_read_alloc: Unknown error 126
>>> ^^^ not clear what this is
>>
>> Not sure what returns -ENOKEY for you. I haven't been using trusted
>> keys on v4.14, but you can try tracing the keyctl syscall.
> 
> yikes... that would be painful. I typo'd and meant 5.14-rc6 :) 

^^

> I'm working with mainline first to make sure I understand everything. If I
> backport this it would be to 5.4 but that looks to be extremely
> painful. It looks like there was a lot of activity around trusted keys
> in 5.13.

Ye. It used to be limited to TPM before that.

> It works for a user keyring but not a session keyring... does that
> explain anything?
> # keyctl add trusted mykey 'new 32' @u
> 941210782
> # keyctl print 941210782
> 83b7845cb45216496aead9ee2c6a406f587d64aad47bddc539d8947a247e618798d9306b36398b5dc2722a4c3f220a3a763ee175f6bd64758fdd49ca4db597e8ce328121b60edbba9b8d8d55056be896
> # keyctl add trusted mykey 'new 32' @s
> 310571960
> # keyctl print 310571960
> keyctl_read_alloc: Unknown error 126

Both sequences work for me.

My getty is started by systemd. I think systemd allocates a new session
keyring for the getty that's inherited by the shell and the commands I run
it in. If you don't do that, each command will get its own session key.
 
> Sorry, I'm still trying to wrap my head around the differences in
> keyrings and trusted vs user keys.

No problem. HTH.

Cheers,
Ahmad

> 
> Tim
>

Tim Harvey Aug. 23, 2021, 5:50 p.m. UTC | #12

On Mon, Aug 23, 2021 at 6:29 AM Ahmad Fatoum <[e-mail]> wrote:
>
> Hello Tim,
>
> On 20.08.21 23:19, Tim Harvey wrote:
> > On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <[e-mail]> wrote:
> >>
> >> On 20.08.21 22:20, Tim Harvey wrote:
> >>> On Fri, Aug 20, 2021 at 9:20 AM Ahmad Fatoum <[e-mail]> wrote:
> >>>> On 20.08.21 17:39, Tim Harvey wrote:
> >>>>> Thanks for your work!
> >>>>>
> >>>>> I've been asked to integrate the capability of using CAAM to
> >>>>> blob/deblob data to an older 5.4 kernel such as NXP's downstream
> >>>>> vendor kernel does [1] and I'm trying to understand how your series
> >>>>> works. I'm not at all familiar with the Linux Key Management API's or
> >>>>> trusted keys. Can you provide an example of how this can be used for
> >>>>> such a thing?
> >>>>
> >>>> Here's an example with dm-crypt:
> >>>>
> >>>>   https://lore.kernel.org/linux-integrity/[e-mail]/
> >>>>
> >>>> dm-crypt is a bit special at the moment, because it has direct support for
> >>>> trusted keys. For interfacing with other parts of the kernel like ecryptfs
> >>>> or EVM, you have to create encrypted keys rooted to the trusted keys and use
> >>>> those. The kernel documentation has an example:
> >>>>
> >>>>   https://www.kernel.org/doc/html/v5.13/security/keys/trusted-encrypted.html
> >>>>
> >>>> If you backport this series, you can include the typo fix spotted by David.
> >>>>
> >>>> I'll send out a revised series, but given that a regression fix I want to
> >>>> rebase on hasn't been picked up for 3 weeks now, I am not in a hurry.
> >>>>
> >>> Thanks for the reference.
> >>>
> >>> I'm still trying to understand the keyctl integration with caam. For
> >>> the 'data' param to keyctl you are using tings like 'new <len>' and
> >>> 'load <data>'. Where are these 'commands' identified?
> >>
> >> Search for match_table_t in security/keys/trusted-keys/trusted_core.c
> >>
> >>> I may still be missing something. I'm using 4.14-rc6 with your series
> >>> and seeing the following:
> >>
> >> That's an odd version to backport stuff to..
> >>
> >>> # cat /proc/cmdline
> >>> trusted.source=caam
> >>> # keyctl add trusted mykey 'new 32' @s)# create new trusted key named
> >>> 'mykey' of 32 bytes in the session keyring
> >>> 480104283
> >>> # keyctl print 480104283 # dump the key
> >>> keyctl_read_alloc: Unknown error 126
> >>> ^^^ not clear what this is
> >>
> >> Not sure what returns -ENOKEY for you. I haven't been using trusted
> >> keys on v4.14, but you can try tracing the keyctl syscall.
> >
> > yikes... that would be painful. I typo'd and meant 5.14-rc6 :)
>
> ^^
>
> > I'm working with mainline first to make sure I understand everything. If I
> > backport this it would be to 5.4 but that looks to be extremely
> > painful. It looks like there was a lot of activity around trusted keys
> > in 5.13.
>
> Ye. It used to be limited to TPM before that.
>
> > It works for a user keyring but not a session keyring... does that
> > explain anything?
> > # keyctl add trusted mykey 'new 32' @u
> > 941210782
> > # keyctl print 941210782
> > 83b7845cb45216496aead9ee2c6a406f587d64aad47bddc539d8947a247e618798d9306b36398b5dc2722a4c3f220a3a763ee175f6bd64758fdd49ca4db597e8ce328121b60edbba9b8d8d55056be896
> > # keyctl add trusted mykey 'new 32' @s
> > 310571960
> > # keyctl print 310571960
> > keyctl_read_alloc: Unknown error 126
>
> Both sequences work for me.
>
> My getty is started by systemd. I think systemd allocates a new session
> keyring for the getty that's inherited by the shell and the commands I run
> it in. If you don't do that, each command will get its own session key.
>
> > Sorry, I'm still trying to wrap my head around the differences in
> > keyrings and trusted vs user keys.
>
> No problem. HTH.

Ahmad,

Ok that explains it - my testing is using a very basic buildroot
ramdisk rootfs. If I do a 'keyctl new_session' first I can use the
system keyring fine as well.

Thanks - hoping to see this merged soon!

Tim

Ahmad Fatoum Aug. 24, 2021, 7:33 a.m. UTC | #13

On 23.08.21 19:50, Tim Harvey wrote:
> On Mon, Aug 23, 2021 at 6:29 AM Ahmad Fatoum <[e-mail]> wrote:
>> On 20.08.21 23:19, Tim Harvey wrote:
>>> On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <[e-mail]> wrote:
>>>> On 20.08.21 22:20, Tim Harvey wrote:
>>> It works for a user keyring but not a session keyring... does that
>>> explain anything?
>>> # keyctl add trusted mykey 'new 32' @u
>>> 941210782
>>> # keyctl print 941210782
>>> 83b7845cb45216496aead9ee2c6a406f587d64aad47bddc539d8947a247e618798d9306b36398b5dc2722a4c3f220a3a763ee175f6bd64758fdd49ca4db597e8ce328121b60edbba9b8d8d55056be896
>>> # keyctl add trusted mykey 'new 32' @s
>>> 310571960
>>> # keyctl print 310571960
>>> keyctl_read_alloc: Unknown error 126
>>
>> Both sequences work for me.
>>
>> My getty is started by systemd. I think systemd allocates a new session
>> keyring for the getty that's inherited by the shell and the commands I run
>> it in. If you don't do that, each command will get its own session key.
>>
>>> Sorry, I'm still trying to wrap my head around the differences in
>>> keyrings and trusted vs user keys.
>>
>> No problem. HTH.
> 
> Ahmad,
> 
> Ok that explains it - my testing is using a very basic buildroot
> ramdisk rootfs. If I do a 'keyctl new_session' first I can use the
> system keyring fine as well.

Great. Does this mean I can get your Tested-by: ? :)

> Thanks - hoping to see this merged soon!

You and me both.

Cheers,
Ahmad


> 
> Tim
>

Tim Harvey Aug. 24, 2021, 3:23 p.m. UTC | #14

On Tue, Aug 24, 2021 at 12:33 AM Ahmad Fatoum <[e-mail]> wrote:
>
> On 23.08.21 19:50, Tim Harvey wrote:
> > On Mon, Aug 23, 2021 at 6:29 AM Ahmad Fatoum <[e-mail]> wrote:
> >> On 20.08.21 23:19, Tim Harvey wrote:
> >>> On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <[e-mail]> wrote:
> >>>> On 20.08.21 22:20, Tim Harvey wrote:
> >>> It works for a user keyring but not a session keyring... does that
> >>> explain anything?
> >>> # keyctl add trusted mykey 'new 32' @u
> >>> 941210782
> >>> # keyctl print 941210782
> >>> 83b7845cb45216496aead9ee2c6a406f587d64aad47bddc539d8947a247e618798d9306b36398b5dc2722a4c3f220a3a763ee175f6bd64758fdd49ca4db597e8ce328121b60edbba9b8d8d55056be896
> >>> # keyctl add trusted mykey 'new 32' @s
> >>> 310571960
> >>> # keyctl print 310571960
> >>> keyctl_read_alloc: Unknown error 126
> >>
> >> Both sequences work for me.
> >>
> >> My getty is started by systemd. I think systemd allocates a new session
> >> keyring for the getty that's inherited by the shell and the commands I run
> >> it in. If you don't do that, each command will get its own session key.
> >>
> >>> Sorry, I'm still trying to wrap my head around the differences in
> >>> keyrings and trusted vs user keys.
> >>
> >> No problem. HTH.
> >
> > Ahmad,
> >
> > Ok that explains it - my testing is using a very basic buildroot
> > ramdisk rootfs. If I do a 'keyctl new_session' first I can use the
> > system keyring fine as well.
>
> Great. Does this mean I can get your Tested-by: ? :)
>

Absolutely,

For the series:

I tested this series on top of v5.14.rc-7 on a Gateworks
imx8mm-venice-gw73xx board with kernel param trusted.source=caam and
keyutils-1.6:
# keyctl new_session
22544757
# keyctl add trusted mykey 'new 32' @s
160701809
# keyctl print 160701809
990e03aa4515aee420eede17e26a58d0c5568c8bd2c9c2ee2f22a0583181d20d4f65cf9cb1f944a3cc92c0e3184a44a29a7e511f0a55a6af11a70ac2b2924514002475e73ae09820042896b9ee00a5ec

Tested-By: Tim Harvey <[e-mail]>

One more question: I've got a user that wants to blob/deblob generic
data. They can use the caam_encap_blob/caam_decap_blob functions in
kernel code but could you give me a suggestion for how they could use
this in:
a) userspace code (using the keyctl syscall I assume)
b) userspace cmdline (via keyutils I assume)

Many thanks,

Tim

Ahmad Fatoum Aug. 25, 2021, 9:34 a.m. UTC | #15

On 24.08.21 17:23, Tim Harvey wrote:
> On Tue, Aug 24, 2021 at 12:33 AM Ahmad Fatoum <[e-mail]> wrote:
>>
>> On 23.08.21 19:50, Tim Harvey wrote:
>>> On Mon, Aug 23, 2021 at 6:29 AM Ahmad Fatoum <[e-mail]> wrote:
>>>> On 20.08.21 23:19, Tim Harvey wrote:
>>>>> On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <[e-mail]> wrote:
>>>>>> On 20.08.21 22:20, Tim Harvey wrote:
>>>>> It works for a user keyring but not a session keyring... does that
>>>>> explain anything?
>>>>> # keyctl add trusted mykey 'new 32' @u
>>>>> 941210782
>>>>> # keyctl print 941210782
>>>>> 83b7845cb45216496aead9ee2c6a406f587d64aad47bddc539d8947a247e618798d9306b36398b5dc2722a4c3f220a3a763ee175f6bd64758fdd49ca4db597e8ce328121b60edbba9b8d8d55056be896
>>>>> # keyctl add trusted mykey 'new 32' @s
>>>>> 310571960
>>>>> # keyctl print 310571960
>>>>> keyctl_read_alloc: Unknown error 126
>>>>
>>>> Both sequences work for me.
>>>>
>>>> My getty is started by systemd. I think systemd allocates a new session
>>>> keyring for the getty that's inherited by the shell and the commands I run
>>>> it in. If you don't do that, each command will get its own session key.
>>>>
>>>>> Sorry, I'm still trying to wrap my head around the differences in
>>>>> keyrings and trusted vs user keys.
>>>>
>>>> No problem. HTH.
>>>
>>> Ahmad,
>>>
>>> Ok that explains it - my testing is using a very basic buildroot
>>> ramdisk rootfs. If I do a 'keyctl new_session' first I can use the
>>> system keyring fine as well.
>>
>> Great. Does this mean I can get your Tested-by: ? :)
>>
> 
> Absolutely,
> 
> For the series:
> 
> I tested this series on top of v5.14.rc-7 on a Gateworks
> imx8mm-venice-gw73xx board with kernel param trusted.source=caam and
> keyutils-1.6:
> # keyctl new_session
> 22544757
> # keyctl add trusted mykey 'new 32' @s
> 160701809
> # keyctl print 160701809
> 990e03aa4515aee420eede17e26a58d0c5568c8bd2c9c2ee2f22a0583181d20d4f65cf9cb1f944a3cc92c0e3184a44a29a7e511f0a55a6af11a70ac2b2924514002475e73ae09820042896b9ee00a5ec
> 
> Tested-By: Tim Harvey <[e-mail]>

Thanks. I'll apply it to the whole series then.

> One more question: I've got a user that wants to blob/deblob generic
> data. They can use the caam_encap_blob/caam_decap_blob functions in
> kernel code but could you give me a suggestion for how they could use
> this in:
> a) userspace code (using the keyctl syscall I assume)
> b) userspace cmdline (via keyutils I assume)

Trusted keys aren't disclosed to userspace in plain text, only in sealed
form (bar vulnerabilities of course).

Cheers,
Ahmad

> 
> Many thanks,
> 
> Tim
>