On Fri, Sep 25, 2026 at 11:39:28AM +0300, Jarkko Sakkinen wrote: > 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 <[email protected]> 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 <[email protected]> >
Gentle ping :) Are we happy with these to get picked up? Thanks, Andrew
