From: David Howells <dhowells@redhat.com>
To: Eric Biggers <ebiggers3@gmail.com>
Cc: dhowells@redhat.com, Geert Uytterhoeven <geert@linux-m68k.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
kernel-hardening@lists.openwall.com,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Kirill Marinushkin <k.marinushkin@gmail.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Ilhan Gurel <ilhan.gurel@gmail.com>,
security@kernel.org, stable <stable@vger.kernel.org>
Subject: Re: Modular BIG_KEYS (was: Re: [PATCH v4] security/keys: rewrite all of big_key crypto)
Date: Tue, 03 Oct 2017 10:04:30 +0100 [thread overview]
Message-ID: <22433.1507021470@warthog.procyon.org.uk> (raw)
In-Reply-To: <20171002170111.GA6713@gmail.com>
Eric Biggers <ebiggers3@gmail.com> wrote:
> (I also still need to convince myself that there aren't any race conditions
> in key type unregistering. It's a little weird how it changes the key type
> to the ".dead" key type, rather than pinning the key type in memory while
> it's still used.)
Keys are converted to the dead type and their destructors called by the gc
whilst it holds a write lock on the key's semaphore, so keyctl() calls
shouldn't be a problem as they all hold a read-lock or a write-lock on the
content.
/proc/keys does things under the key_serial_lock and RCU, so if a key type's
->describe() function looks at the payload, then it should use RCU conditions.
Note that this doesn't affect the keyring_describe() as that only looks at a
value that is stored in the key struct - and the same for user_describe() and
big_key_describe(). asymmetric_key_describe(), OTOH... Maybe the simplest
thing to do is to take key_serial_lock in key_garbage_collector() around the
code that changes the key type.
Inside the kernel, things are murkier as the kernel can reach inside a key
without taking the semaphore. If it does so, it must use RCU or some other
mechanism to prevent the key payload from being destroyed under it.
With AF_RXRPC, I think I'm doing this wrong. I think I need to move the
destruction of the key type to after I've unregistered the network namespace
handling as the latter destroys connections which might be using the key.
David
next prev parent reply other threads:[~2017-10-03 9:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-02 7:14 Modular BIG_KEYS (was: Re: [PATCH v4] security/keys: rewrite all of big_key crypto) Geert Uytterhoeven
2017-10-02 17:01 ` Eric Biggers
2017-10-03 9:04 ` David Howells [this message]
2017-10-02 21:12 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22433.1507021470@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=Jason@zx2c4.com \
--cc=ard.biesheuvel@linaro.org \
--cc=ebiggers3@gmail.com \
--cc=geert@linux-m68k.org \
--cc=herbert@gondor.apana.org.au \
--cc=ilhan.gurel@gmail.com \
--cc=k.marinushkin@gmail.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=security@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).