On Fri, Aug 20, 2021 at 9:20 AM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > > Hello Tim, > > On 20.08.21 17:39, Tim Harvey wrote: > > On Wed, Jul 21, 2021 at 9:49 AM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > >> > >> Series applies on top of > >> https://lore.kernel.org/linux-integrity/20210721160258.7024-1-a.fatoum@xxxxxxxxxxxxxx/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/1447082306-19946-2-git-send-email-s.trumtrar@xxxxxxxxxxxxxx/ > >> [2]: https://lore.kernel.org/linux-integrity/20180723111432.26830-1-udit.agarwal@xxxxxxx/ > >> [3]: https://lore.kernel.org/lkml/1551456599-10603-2-git-send-email-franck.lenormand@xxxxxxx/ > >> [4]: https://lore.kernel.org/lkml/1604419306-26105-1-git-send-email-sumit.garg@xxxxxxxxxx/ > >> [5]: https://lore.kernel.org/linux-integrity/20210122084321.24012-2-a.fatoum@xxxxxxxxxxxxxx/ > >> > >> --- > >> To: Jarkko Sakkinen <jarkko@xxxxxxxxxx> > >> To: "Horia Geantă" <horia.geanta@xxxxxxx> > >> To: Mimi Zohar <zohar@xxxxxxxxxxxxx> > >> To: Aymen Sghaier <aymen.sghaier@xxxxxxx> > >> To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > >> To: "David S. Miller" <davem@xxxxxxxxxxxxx> > >> To: James Bottomley <jejb@xxxxxxxxxxxxx> > >> Cc: David Howells <dhowells@xxxxxxxxxx> > >> Cc: James Morris <jmorris@xxxxxxxxx> > >> Cc: "Serge E. Hallyn" <serge@xxxxxxxxxx> > >> Cc: Steffen Trumtrar <s.trumtrar@xxxxxxxxxxxxxx> > >> Cc: Udit Agarwal <udit.agarwal@xxxxxxx> > >> Cc: Jan Luebbe <j.luebbe@xxxxxxxxxxxxxx> > >> Cc: David Gstir <david@xxxxxxxxxxxxx> > >> Cc: Eric Biggers <ebiggers@xxxxxxxxxx> > >> Cc: Richard Weinberger <richard@xxxxxx> > >> Cc: Franck LENORMAND <franck.lenormand@xxxxxxx> > >> Cc: Sumit Garg <sumit.garg@xxxxxxxxxx> > >> Cc: linux-integrity@xxxxxxxxxxxxxxx > >> Cc: keyrings@xxxxxxxxxxxxxxx > >> Cc: linux-crypto@xxxxxxxxxxxxxxx > >> Cc: linux-kernel@xxxxxxxxxxxxxxx > >> Cc: linux-security-module@xxxxxxxxxxxxxxx > >> > >> 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/5d44e50e-4309-830b-79f6-f5d888b1ef69@xxxxxxxxxxxxxx/ > > 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
