Hello, чт, 23 апр. 2020 г. в 09:47, Milan Broz <gmazyland@xxxxxxxxx>: > > 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. 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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
