Re: [RFC] Keyrings: How to make them more useful

[David 'equinox' Lamparter <equinox@diac24.net>]

On Mon, Jul 21, 2025 at 03:55:44PM +0100, David Howells wrote:
> David 'equinox' Lamparter <equinox@diac24.net> wrote:
[...]
> > As someone who has recently tried to use keyrings from userspace (in
> > order to bind key material to a TPM, and have it never enter user
> > memory), I would note two things here:
> > 
> > * the request_key() syscall seems to be blocking.  Of course you can
> >   work around that by creating a thread, but is it not possible to
> >   create a better API?
> 
> Depends what you mean by a "better API".  Unfortunately, we're somewhat stuck
> with this API - it has to go on working pretty much as-is.  However, some
> things can be changed.

I'm painfully aware of the no breaking userspace rule, and it certainly
applies here :(.

> request_key() can block, yes - that's part of the design.  It can upcall to
> userspace to go and get the content for a key - and this might involve, say,
> network calls to a KDC.  Now, the exact upcalling mechanism can be done better
> - and that's one of the things I included in my list - but it should not block
> forever and, ideally, if someone presses Ctrl-C, it should perhaps terminate
> the upcall.

Well, I'm a networking person, so my immediate association is netlink.
As in, request_key() is a KEYCTL_REQUEST_KEY message that you get a
KEYCTL_RESULT_KEY response to -- at some point later.  (With request
abort if the socket gets closed for whatever reason.)

To be entirely honest I was also surprised to see the keyring monitoring
bits have this WATCH_QUEUE thing (that nobody else seems to be using?)
rather than just throwing up netlink multicast.  There's probably some
backstory to this that I'm unaware of.

> > * the trusted key / TPM bits are incredibly poorly documented.  It's
> >   basically "cobble together things from old patch descriptions", e.g.
> >   https://marc.info/?l=linux-keyrings&m=160074197025246
> >   (I still have not figured out how to do this correctly.  Some of that
> >   is to blame on the TPM bits, but not all.)
> 
> Note that the trusted key/TPM bits aren't part of the core keyrings code.
> Trusted and encrypted keys are examples of key types.

I know -- maybe I should make another comment here:  the trusted/TPM
bits, through the keyring API, are *actually quite useful* for
userspace, especially combined with AF_ALG's ALG_SET_KEY_BY_KEY_SERIAL.
Doing crypto with a key that never enters userspace - amazing!

So maybe let me replace my message here with "please don't forget about
userspace".  Which does include documenting things ;).

> > I guess the kernel itself doesn't care about the blocking API, but for
> > trusted keys...  you'll have to tie things together from user space, and
> > I don't see how anyone can do that, especially with any level of
> > confidence that they didn't accidentally leave some wide-open hole (as
> > in - you might well get something to work, but without docs you can't
> > check you actually did it *right*.)  This is really improving keyctl
> > itself (i.e. how its commands are invoked) and also its documentation.
> 
> Are you talking about keyctl() the syscall or keyctl the program?

Sorry, keyctl the program.  I haven't tried using the syscall directly,
libkeyutils is reasonable (easier to understand than the program, maybe.)

Cheers,


equi