[dm-devel] dm-crypt: support using encrypted keys

[Milan Broz]

On 22/04/2020 23:40, Mike Snitzer wrote:
> On Wed, Apr 22 2020 at 12:47pm -0400,
> Milan Broz <gmazyland at gmail.com> wrote:
> 
>> On 21/04/2020 20:27, Mike Snitzer wrote:
>>> On Mon, Apr 20 2020 at  9:46P -0400,
>>> Dmitry Baryshkov <dbaryshkov at gmail.com> wrote:
>>>
>>>> From: Dmitry Baryshkov <dmitry_baryshkov at mentor.com>
>>>>
>>>> Allow one to use encrypted in addition to user and login key types for
>>>> device encryption.
>>>>
>>>> Signed-off-by: Dmitry Baryshkov <dmitry_baryshkov at mentor.com>
>>>
>>> I fixed up some issues, please see the following incremental patch,
>>> I'll get this folded in and staged for 5.8.
>>
>> And you just created hard dependence on encrypted key type...
>>
>> If you disable this type (CONFIG_ENCRYPTED_KEYS option), it cannot load the module anymore:
>> ERROR: modpost: "key_type_encrypted" [drivers/md/dm-crypt.ko] undefined!
> 
> Yes, I was made aware via linux-next last night.
> 
>> We had this idea before, and this implementation in dm-crypt just requires dynamic
>> key type loading implemented first.
>>
>> David Howells (cc) promised that moths ago, but apparently nothing was yet submitted
>> (and the proof-of-concept patch no longer works).
> 
> Why is it so bad for dm-crypt to depend on CONFIG_ENCRYPTED_KEYS while
> we wait for the innovation from David?

People need to compile kernel with specific features disabled, even without keyring sometimes.
We also support whole CONFIG_KEYS disable - and it makes sense for some small appliances.

In fact I had similar patch (support for encrypted+trusted keyes) for dm-crypt for months,
with additional patch that loads key types per requests (so it can fail if the type is not available).
It uses key_type_lookup function exported. IMO this is the way to go.

So the idea is good, but please keep possibility to disable it.
Additional dependencies not only cause problems above, but also can get some failures from initrd
where the new module is missing (that happened several times, it is just problem
that can be easily avoided).

Milan