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

[Mike Snitzer]

On Thu, Apr 23 2020 at  2:47am -0400,
Milan Broz <gmazyland at gmail.com> wrote:

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

Seems you didn't look at the fixed patch, here is what I ultimately
staged yesterday:
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-5.8&id=a2b35bd064baf1f4e7504c23d493a3e149172dd1

dm-crypt doesn't have a hard dependency on CONFIG_ENCRYPTED_KEYS.  If it
is enabled support will be available, if not enabled support isn't.

The concern about initramfs not having dep modules is a kernel tooling
support issue.  Not seeing any point withholding capabilities out of
paranoia that a particular distribution's tooling (initramfs generation
upon kernel update) isn't working as needed.

Mike