On Thu, Apr 23 2020 at 2:47am -0400, Milan Broz <gmazyland@xxxxxxxxx> wrote: > On 22/04/2020 23:40, Mike Snitzer wrote: > > 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? > > 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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
