From: Mike Snitzer <snitzer@redhat.com>
To: Milan Broz <gmazyland@gmail.com>
Cc: Dmitry Baryshkov <dbaryshkov@gmail.com>,
Dmitry Baryshkov <dmitry_baryshkov@mentor.com>,
David Howells <dhowells@redhat.com>,
dm-devel@redhat.com, Alasdair Kergon <agk@redhat.com>
Subject: Re: dm-crypt: support using encrypted keys
Date: Wed, 22 Apr 2020 17:40:52 -0400 [thread overview]
Message-ID: <20200422214052.GA10695@redhat.com> (raw)
In-Reply-To: <e3b78a32-4307-c60c-f9c3-dd6d71b6633c@gmail.com>
On Wed, Apr 22 2020 at 12:47pm -0400,
Milan Broz <gmazyland@gmail.com> wrote:
> On 21/04/2020 20:27, Mike Snitzer wrote:
> > On Mon, Apr 20 2020 at 9:46P -0400,
> > Dmitry Baryshkov <dbaryshkov@gmail.com> wrote:
> >
> >> From: Dmitry Baryshkov <dmitry_baryshkov@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@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?
> Mike, I think you should revert this patch from the tree until it is solved.
>
> Once fixed, we should also support "trusted" key type.
>
> Also please - do no forget to increase dm-crypt minor version here...
I fixed the patch up and staged it in linux-next to get test coverage,
see:
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=5eb07fda05fbf87d9a37939d1cd445203c55e126
Doesn't mean I intend to keep it staged; just would like to validate the
patch before tabling it (if that's what is ultimately decided for now).
Mike
next prev parent reply other threads:[~2020-04-22 21:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-20 13:46 [PATCH] dm-crypt: support using encrypted keys Dmitry Baryshkov
2020-04-21 18:27 ` Mike Snitzer
2020-04-21 18:32 ` Dmitry Baryshkov
2020-04-21 18:59 ` Mike Snitzer
2020-04-23 11:20 ` Dmitry Baryshkov
2020-04-22 16:47 ` Milan Broz
2020-04-22 21:40 ` Mike Snitzer [this message]
2020-04-23 6:47 ` Milan Broz
2020-04-23 11:02 ` Dmitry Baryshkov
2020-04-23 14:06 ` Mike Snitzer
2020-04-23 14:41 ` Milan Broz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200422214052.GA10695@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=dbaryshkov@gmail.com \
--cc=dhowells@redhat.com \
--cc=dm-devel@redhat.com \
--cc=dmitry_baryshkov@mentor.com \
--cc=gmazyland@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.