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

[Dmitry Baryshkov]

Hello,

чт, 23 апр. 2020 г. в 09:47, Milan Broz <gmazyland at gmail.com>:
>
> 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.

I'm sorry for this.

> >
> >> 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.

I've also had a patch using key_type_lookup(). However I ended up
dropping it becasue each key type still needs type-specific function
to access key payload. Unless we also add an API to access payloads in
a type-neutral way, it does not make sense.

> 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).

It looks like Mike has already fixed it. So thanks a lot and sorry for
the issues caused by the patch.


-- 
With best wishes
Dmitry