On 9/16/2020 12:50 AM, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- >> Von: "horia geanta" <horia.geanta@xxxxxxx> >>>> How to use it with cryptsetup? >>>> I'm asking because it is not clear to me why you are not implementing >>>> a new kernel key type (KEYS subsystem) >>>> to utilize tagged keys. >>>> Many tools already support the keyctl userspace interface (cryptsetup, >>>> fscrypt, ...). >>> >>> *friendly ping* >>> >> We didn't include the key management part in this series, >> just the crypto API support for algorithms with protected keys, >> to get early feedback. >> >> Wrt. key management: >> The NXP vendor / downstream kernel (to be included in i.MX BSP Q3 release) >> will have support for protected keys generation. >> Besides this, a dedicated ioctl-based interface will allow userspace to >> generate and export these keys. After this, user can use standard keyctl >> to add a key (as user / logon type) in the keyring, such that it would be >> available to dm-crypt. >> >> We know that adding new ioctls is frowned upon, so before trying to upstream >> the ioctl-based solution the plan is checking the feasibility of >> extending keyctl as David Howells suggested: >> https://lore.kernel.org/lkml/8060.1533226481@xxxxxxxxxxxxxxxxxxxxxx >> (Note the difference b/w adding new key type - which was rejected - >> and a key "subtype extension".) > > We have also a keyctl based patch series which should go upstream. > Since we also added a new keytype, it got rejected so far. > Could you please point me to the discussion? > Do you have git repo with the WIP patches available? > Not that we do the work twice. :-) Unfortunately we haven't developed any code yet. > Our patch series also supports DCP beside of CAAM. > By looking at the DCP capabilities, I assume the OTP key that is copied in the key RAM at boot time is used as KEK. If you don't mind sharing, I could review the code. Thanks, Horia
