Re: [RFC PATCH v2 00/11] KEYS: Sanitize the garbage collector

[Jarkko Sakkinen]

On Tue, Nov 03, 2026 at 06:58:45PM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 03, 2026 at 03:32:26PM +0000, David Howells wrote:
> > Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote:
> > 
> > > > Actually, it can be done if the rxrpc and rxrpc_s key types are moved out
> > > > into their own module upon which rxrpc.ko depends.
> > > 
> > > Hmm... I'll experiment with this, thanks. This was useful.
> > 
> > It's not entirely trivial.  I've attached a patch that makes a start on it,
> > but it needs access to bits of the security class implementations (rxkad and
> > rxgk).  Those bits only parse the key (and in the case of rxgk access the krb5
> > code), so in theory it should be possible to extract them out.
> > 
> > One thing that needs to be considered, though, is the security class selected
> > should really be up to the application, not merely switched on by the
> > security_id.  This is one of the reasons I would like to add an add_key2()
> > syscall that adds an additional parameter string argument.
> 
> Thanks I'll investigate this.

Well, this really unknotted:

    dns_resolver: Move the key type into a separate module

    Once keys bind their type, having the DNS key type in the same modules as
    the resolver will introduce a circular dependency preventing module_exit()
    from ever running.

    Introduce dns_resolver_key.ko containing key_type_dns_resolver. On a module
    exit, drop the credentials and call key_gc_flush() in order the drain the
    remaining RCU callbacks.

    Signed-off-by: Jarkko Sakkinen <jarkko@xxxxxxxxxx>

And yes, I was over-complicating this, just like I told earlier :-)

This means I should be able to submit v3, which continues to build
around the same ideas.

Br, Jarkko