Re: [RFC PATCH 1/1] dm-integrity: support keys in the kernel keyring

[Eric Biggers]

On Fri, Oct 02, 2026 at 01:48:23PM +0200, Mikulas Patocka wrote:
> > > These four functions are copied from dm-crypt.c and dm-inlinecrypt.c.
> > > Copying code is generally malpattern, they should be unified and moved to
> > > an include file (that would be included in all three targets) or to the
> > > key management code (that would be called from all three targets).
> > > 
> > 
> > Yes that is the issue I described in the cover letters. But I don't
> > actually know which way is the preferred one. Afaik there are now
> > three options:
> > 
> > 1. static inline helpers in a drivers/md header, so dm-crypt and
> >    dm-integrity each compile their own copy
> > 2. a small library module, similar to dm-bufio, so there is one copy
> >    that follows the value (y/m) of dm-crypt and dm-integrity
> > 3. integration into key management code
> > 
> > Please tell me which option you prefer.
> 
> Try 3, if not possible then 1. I think that introducing a module with this 
> would be overkill.
> 
> The "if (!strncmp(key_string, "logon:", key_desc - key_string + 1)) {" 
> lines are duplicated as well, so I would refactor them and move them to 
> the helper too.
> 
> I don't know why dm-inlinecrypt only uses the "logon:" key while dm-crypt 
> uses "user:", "encrypted:", "trusted:" as well (Eric - could you 
> explain?). So, perhaps, dm-inlinecrypt could be extended to use all four 
> key types as well.

The keyring support didn't exist in my version of the dm-inlinecrypt
patch.  It seems to have been requested by Milan here:
https://lore.kernel.org/dm-devel/682506ea-c9c2-458b-8123-8d78fc53cc7f@xxxxxxxxx/
then added by Linlin.

>From what I understand, the point of the keyring support in
dm-{crypt,inlinecrypt,integrity} is:

- To support "trusted" keys.  But that is not what was actually
  implemented in dm-inlinecrypt.

- To avoid having the key be readable with STATUSTYPE_TABLE.  But that
  is not what was actually implemented in dm-inlinecrypt.  Keyrings are
  also unnecesary to solve that problem.

- To cause security bugs such as https://lwn.net/Articles/1090568/ .
  Since otherwise things aren't exciting enough, I guess.

Not sure what I'm missing.

But if you really do want to support all four key types in all three of
these targets anyway though, then sure, the code might as well be
shared since it would otherwise be the same code in each.

- Eric