Re: [PATCH 2/2] crypto: caam - support tagged keys for skcipher algorithms

[Horia Geantă]

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