Re: [PATCH 1/3] keys: add KEY_SPEC_DM_VERITY_KEYRING

[Jarkko Sakkinen]

On Fri, Sep 18, 2026 at 02:59:49PM -0500, Andrew Halaney wrote:
> On Fri, Sep 18, 2026 at 09:05:26AM +0100, David Howells wrote:
> > Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote:
> > 
> > > This is great for discussion but what we want for the commit message
> > > is just motivation and resolution.
> > 
> > Actually, I think it's useful that Andrew wrote up the issues in the commit
> > message - and I think it shows part of the motivation.  The 'writing a fake
> > /proc/keys line in the description' is something I hadn't considered.
> 
> I'll defer to what you all want in the message here, I found it valuable
> but I trend on the side of overly verbose admittedly!
> 
> > 
> > > I don't think we need all this just to say that /proc/keys in a racy
> > > query mechanism for production, which is an issue for dm-verity, given
> > > that nothing else is available.
> > 
> > I think at some point, we will need a system call to search all for all
> > accessible keys matching certain criteria by actually walking the key
> > database.  The problem there is that there may be multiple hits, so we may
> > need something like:
> > 
> > 	int count = find_key(key_serial_t start_id,
> > 			     const char *type, const char *desc_prefix,
> > 			     key_serial_t *results, size_t results_size,
> > 			     unsigned int flags);
> > 
> > Allowing you to do:
> > 
> > 	key_serial_t dm_key;
> > 	int n = find_key(0, "keyring", ".dm_verity", &dm_key, 1,
> > 			 FIND_KEY_EXACT_DESC);
> > 
> > This wouldn't be as fast as a direct lookup since it would have to walk the
> > key tree, doing name comparisons and perm checks on each key of the type.
> > 
> > > And secondly special keys are meant for implicit keyrings so isn't
> > > that all there's to it?
> > 
> > I have no particular objection to setting aside a block of negative key IDs
> > for special keyrings that need to be accessed a lot - though I would make
> > common reg/unreg functions that take the ID to be registered and, say, set the
> > block at -257..-512.  Moving the BFP keyring to -257 and DM to -258.
> 
> To be clear are you suggesting I do that for v2 here? Happy to make the
> change and add some reuse to the registration functions, etc. I'm
> guessing its fine to change the bpf id since its still only in -next?
> 
> The only awkward bit with making that more generic is that dm-verity
> isn't __ro_after_init since its coming from a module possibly, and
> because of the module usage I also protected it with a spinlock in case
> someone's accessing it while you unload the module. Could just use one
> spinlock for the whole generic array, and drop the __ro_after_init I
> suppose.
> 
> Let me know if I'm not following properly!

I just read David's response and I think he made fair arguments,
and patches look fine to me.

David, did you have anything? I could pick these.

Reviewed-by: Jarkko Sakkinen <jarkko@xxxxxxxxxx>

> 
> Thanks,
> Andrew


Br, Jarkko