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/[email protected]
>
> 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 <[email protected]> # on ls1028a (non-E and E)
-michael
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/[email protected]
>>
>> 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 <[email protected]> # 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 |
Hi,
Am 2022-05-11 12:47, schrieb Ahmad Fatoum:
> On 06.05.22 12:52, Michael Walle wrote:
>> Am 2022-05-06 08:25, schrieb Ahmad Fatoum:
>>> Series applies on top of v5.18-rc5. Would be great if this could make
>>> it
>>> into v5.19.
>>>
>>> v8 was here:
>>> https://lore.kernel.org/linux-integrity/[email protected]
>>>
>>> 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 <[email protected]> # on ls1028a (non-E and E)
>
> Thanks! Did you test checkpatch.pl and make htmldocs/pdfdocs too
> or should I add the Tested-by just for the first 5 patches?
I just tested the series on the mentioned hardware. So no htmldocs
or checkpatch.pl.
-michael