On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > > On 20.08.21 22:20, Tim Harvey wrote: > > On Fri, Aug 20, 2021 at 9:20 AM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> 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/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. > >> > > 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
