On Wed, Apr 22 2020 at 12:47pm -0400, Milan Broz <gmazyland@xxxxxxxxx> wrote: > On 21/04/2020 20:27, Mike Snitzer wrote: > > On Mon, Apr 20 2020 at 9:46P -0400, > > Dmitry Baryshkov <dbaryshkov@xxxxxxxxx> wrote: > > > >> From: Dmitry Baryshkov <dmitry_baryshkov@xxxxxxxxxx> > >> > >> Allow one to use encrypted in addition to user and login key types for > >> device encryption. > >> > >> Signed-off-by: Dmitry Baryshkov <dmitry_baryshkov@xxxxxxxxxx> > > > > 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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel