LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Kees Cook <keescook@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
tcharding <me@tobin.cc>
Subject: Re: [PATCH] vsprintf: Fix memory barriers of ptr_key to have_filed_random_ptr_key
Date: Tue, 15 May 2018 14:57:44 -0400 [thread overview]
Message-ID: <20180515145744.3bdcbbe9@gandalf.local.home> (raw)
In-Reply-To: <CA+55aFyBHRmXLo07f_7qt7szaDvppMStfX5Sq9Df6mZSy+qYvA@mail.gmail.com>
On Tue, 15 May 2018 09:55:13 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, May 15, 2018 at 7:06 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> > - smp_mb();
> > + smp_wmb();
> > WRITE_ONCE(have_filled_random_ptr_key, true);
>
>
> > + /* Read ptr_key after reading have_filled_random_ptr_key */
> > + smp_rmb();
> > +
> > #ifdef CONFIG_64BIT
> > hashval = (unsigned long)siphash_1u64((u64)ptr, &ptr_key);
>
> Hmm. smp_wmb/rmb are basically free on x86, but on some architectures
> smp_rmb() in particular can be pretty expensive.
>
> So when you have a "handoff" situation like this, it's _probably_ better to
> use use "smp_store_release()" and "smp_load_acquire()". To some degree that
> might also be better for documentation purposes, because that's exactly the
> "release-acquire" pattern.
>
> That said, I'm not convinced this really matters all that much for a
> boot-time flag like this. The race is pretty theoretical.
>
I was thinking the same. But since the smp_mb() is there, then it
should be correct, which it currently isn't.
We could change this to a static key, and enable it after we set up
the ptr_key. That would be a one time change at boot up, wont have
races, and have no overhead.
-- Steve
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 30c0cb8cc9bc..da4ea056a309 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1669,19 +1669,21 @@ char *pointer_string(char *buf, char *end, const void *ptr,
return number(buf, end, (unsigned long int)ptr, spec);
}
-static bool have_filled_random_ptr_key __read_mostly;
+static DEFINE_STATIC_KEY_TRUE(not_filled_random_ptr_key);
static siphash_key_t ptr_key __read_mostly;
+static void enable_ptr_key_workfn(struct work_struct *work)
+{
+ /* Needs to run from preemptable context */
+ static_branch_disable(¬_filled_random_ptr_key);
+}
+
+static DECLARE_WORK(enable_ptr_key_work, enable_ptr_key_workfn);
+
static void fill_random_ptr_key(struct random_ready_callback *unused)
{
get_random_bytes(&ptr_key, sizeof(ptr_key));
- /*
- * have_filled_random_ptr_key==true is dependent on get_random_bytes().
- * ptr_to_id() needs to see have_filled_random_ptr_key==true
- * after get_random_bytes() returns.
- */
- smp_mb();
- WRITE_ONCE(have_filled_random_ptr_key, true);
+ queue_work(system_unbound_wq, &enable_ptr_key_work);
}
static struct random_ready_callback random_ready = {
@@ -1709,7 +1711,7 @@ static char *ptr_to_id(char *buf, char *end, void *ptr, struct printf_spec spec)
unsigned long hashval;
const int default_width = 2 * sizeof(ptr);
- if (unlikely(!have_filled_random_ptr_key)) {
+ if (static_branch_unlikely(¬_filled_random_ptr_key)) {
spec.field_width = default_width;
/* string length must be less than default_width */
return string(buf, end, "(ptrval)", spec);
next prev parent reply other threads:[~2018-05-15 18:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-15 14:05 Steven Rostedt
2018-05-15 16:55 ` Linus Torvalds
2018-05-15 18:57 ` Steven Rostedt [this message]
2018-05-15 19:03 ` Linus Torvalds
2018-05-15 20:10 ` Steven Rostedt
2018-05-15 22:31 ` Linus Torvalds
2018-05-15 22:41 ` Steven Rostedt
2018-05-15 23:00 ` Steven Rostedt
2018-05-15 23:10 ` Linus Torvalds
2018-05-23 10:40 ` Pavel Machek
2018-05-24 18:44 ` Steven Rostedt
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=20180515145744.3bdcbbe9@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=me@tobin.cc \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--subject='Re: [PATCH] vsprintf: Fix memory barriers of ptr_key to have_filed_random_ptr_key' \
/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
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).