Hello Michael, On 06.05.22 12:52, Michael Walle wrote: > Am 2022-05-06 08:25, schrieb Ahmad Fatoum: >> Series applies on top of v5.18-rc5. Would be great if this could make it >> into v5.19. >> >> v8 was here: >> https://lore.kernel.org/linux-integrity/09e2552c-7392-e1da-926b-53c7db0b118d@xxxxxxxxxxxxxx >> >> Changelog is beneath each individual patch. Compared to v8, only code >> change is checking whether CAAM can support blobbing at init-time as >> apparently some Layerscape SoCs are available in a non-E(ncryption) >> variant that doesn't do AES. Previously, adding trusted keys on such >> SoCs would return an error with a cryptic error message. >> >> >> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core >> built into many newer i.MX and QorIQ SoCs by NXP. >> >> Its blob mechanism can AES encrypt/decrypt user data using a unique >> never-disclosed device-specific key. >> >> There has been multiple discussions on how to represent this within the kernel: >> >> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core >> built into many newer i.MX and QorIQ SoCs by NXP. >> >> Its blob mechanism can AES encrypt/decrypt user data using a unique >> never-disclosed device-specific key. There has been multiple >> discussions on how to represent this within the kernel: >> >> - [RFC] crypto: caam - add red blobifier >> Steffen implemented[1] a PoC sysfs driver to start a discussion on how to >> best integrate the blob mechanism. >> Mimi suggested that it could be used to implement trusted keys. >> Trusted keys back then were a TPM-only feature. >> >> - security/keys/secure_key: Adds the secure key support based on CAAM. >> Udit Agarwal added[2] a new "secure" key type with the CAAM as backend. >> The key material stays within the kernel only. >> Mimi and James agreed that this needs a generic interface, not specific >> to CAAM. Mimi suggested trusted keys. Jan noted that this could serve as >> basis for TEE-backed keys. >> >> - [RFC] drivers: crypto: caam: key: Add caam_tk key type >> Franck added[3] a new "caam_tk" key type based on Udit's work. This time >> it uses CAAM "black blobs" instead of "red blobs", so key material stays >> within the CAAM and isn't exposed to kernel in plaintext. >> James voiced the opinion that there should be just one user-facing generic >> wrap/unwrap key type with multiple possible handlers. >> David suggested trusted keys. >> >> - Introduce TEE based Trusted Keys support >> Sumit reworked[4] trusted keys to support multiple possible backends with >> one chosen at boot time and added a new TEE backend along with TPM. >> This now sits in Jarkko's master branch to be sent out for v5.13 >> >> This patch series builds on top of Sumit's rework to have the CAAM as >> yet another >> trusted key backend. >> >> The CAAM bits are based on Steffen's initial patch from 2015. His work had been >> used in the field for some years now, so I preferred not to deviate >> too much from it. >> >> This series has been tested with dmcrypt[5] on an i.MX6Q/DL and an i.MX8M[6]. >> >> Looking forward to your feedback. > > For the whole series: > > Tested-by: Michael Walle <michael@xxxxxxxx> # on ls1028a (non-E and E) Thanks! Did you test checkpatch.pl and make htmldocs/pdfdocs too or should I add the Tested-by just for the first 5 patches? Cheers, Ahmad > > -michael > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
