From: ebiggers3@gmail.com (Eric Biggers)
To: linux-security-module@vger.kernel.org
Subject: [RFC][PATCH 00/15] KEYS: Fixes
Date: Tue, 17 Oct 2017 10:52:06 -0700 [thread overview]
Message-ID: <20171017175206.GB555@zzz.localdomain> (raw)
In-Reply-To: <27552.1508192842@warthog.procyon.org.uk>
On Mon, Oct 16, 2017 at 11:27:22PM +0100, David Howells wrote:
> Okay, I've fixed those issues, I think. I've renamed the instantiation labels
> to positive.
>
> Thanks,
> David
> ---
> commit f23f3bb0ba3be44e775ac74148157136b919e3b0
> Author: David Howells <dhowells@redhat.com>
> Date: Wed Oct 4 16:43:25 2017 +0100
>
> KEYS: Fix race between updating and finding a negative key
>
> Consolidate KEY_FLAG_INSTANTIATED, KEY_FLAG_NEGATIVE and the rejection
> error into one field such that:
>
> (1) The instantiation state can be modified/read atomically.
>
> (2) The error can be accessed atomically with the state.
>
> (3) The error isn't stored unioned with the payload pointers.
>
> This deals with the problem that the state is spread over three different
> objects (two bits and a separate variable) and reading or updating them
> atomically isn't practical, given that not only can uninstantiated keys
> change into instantiated or rejected keys, but rejected keys can also turn
> into instantiated keys - and someone accessing the key might not be using
> any locking.
>
> The main side effect of this problem is that what was held in the payload
> may change, depending on the state. For instance, you might observe the
> key to be in the rejected state. You then read the cached error, but if
> the key semaphore wasn't locked, the key might've become instantiated
> between the two reads - and you might now have something in hand that isn't
> actually an error code.
>
> The state is now KEY_IS_UNINSTANTIATED, KEY_IS_POSITIVE or a negative error
> code if the key is negatively instantiated. The key_is_instantiated()
> function is replaced with key_is_positive() to avoid confusion as negative
> keys are also 'instantiated'.
>
> Additionally, barriering is included:
>
> (1) Order payload-set before state-set during instantiation.
>
> (2) Order state-read before payload-read when using the key.
>
> Further separate barriering is necessary if RCU is being used to access the
> payload content after reading the payload pointers.
>
> Fixes: 146aa8b1453b ("KEYS: Merge the type-specific data with the payload data")
> Cc: stable at vger.kernel.org # v4.4+
> Reported-by: Eric Biggers <ebiggers@google.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
>
This looks good now; feel free to add
Reviewed-by: Eric Biggers <ebiggers@google.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-10-17 17:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 16:17 [RFC][PATCH 00/15] KEYS: Fixes David Howells
2017-10-12 16:26 ` David Howells
2017-10-12 18:56 ` Eric Biggers
2017-10-13 15:39 ` David Howells
2017-10-16 18:31 ` Eric Biggers
2017-10-16 22:09 ` David Howells
2017-10-16 22:27 ` David Howells
2017-10-17 17:52 ` Eric Biggers [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-10-12 20:15 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=20171017175206.GB555@zzz.localdomain \
--to=ebiggers3@gmail.com \
--cc=linux-security-module@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).