[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z_e9CVsmiXD3QYkg@kernel.org>
Date: Thu, 10 Apr 2025 15:43:53 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: keyrings@...r.kernel.org
Cc: Jarkko Sakkinen <jarkko.sakkinen@...nsys.com>, stable@...r.kernel.org,
David Howells <dhowells@...hat.com>, Lukas Wunner <lukas@...ner.de>,
Ignat Korchagin <ignat@...udflare.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>,
Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Mimi Zohar <zohar@...ux.ibm.com>, linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-integrity@...r.kernel.org,
linux-security-module@...r.kernel.org
Subject: Re: [PATCH v8] KEYS: Add a list for unreferenced keys
On Tue, Apr 08, 2025 at 07:01:47PM +0300, Jarkko Sakkinen wrote:
> On Mon, Apr 07, 2025 at 03:58:01PM +0300, Jarkko Sakkinen wrote:
> > From: Jarkko Sakkinen <jarkko.sakkinen@...nsys.com>
> >
> > Add an isolated list of unreferenced keys to be queued for deletion, and
> > try to pin the keys in the garbage collector before processing anything.
> > Skip unpinnable keys.
> >
> > Use this list for blocking the reaping process during the teardown:
> >
> > 1. First off, the keys added to `keys_graveyard` are snapshotted, and the
> > list is flushed. This the very last step in `key_put()`.
> > 2. `key_put()` reaches zero. This will mark key as busy for the garbage
> > collector.
> > 3. `key_garbage_collector()` will try to increase refcount, which won't go
> > above zero. Whenever this happens, the key will be skipped.
> >
> > Cc: stable@...r.kernel.org # v6.1+
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@...nsys.com>
>
> This version is my master branch now:
>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/
>
> For the time being not in next.
I just updated it to my -next, so probably tomorrow will be in
linux-next.
I believe this is absolutely right thing to do but please be aware of
this (now it is *knowingly* applied) and ping me for any issues.
Summaery: it sets walls against using struct key in the middle of
destruction (e.g. when key_put() is accessing it after zero refcount, GC
should never touch it).
BR, Jarkko
Powered by blists - more mailing lists