vsprintf: Replace memory barrier with static_key for random_ptr_key update
authorSteven Rostedt (VMware) <rostedt@goodmis.org>
Wed, 16 May 2018 02:24:52 +0000 (22:24 -0400)
committerSteven Rostedt (VMware) <rostedt@goodmis.org>
Wed, 16 May 2018 13:01:41 +0000 (09:01 -0400)
commit85f4f12d51397f1648e1f4350f77e24039b82d61
tree7913a89f385849f276a99c2fbfa2a1e345d3ddbd
parent67b8d5c7081221efa252e111cd52532ec6d4266f
vsprintf: Replace memory barrier with static_key for random_ptr_key update

Reviewing Tobin's patches for getting pointers out early before
entropy has been established, I noticed that there's a lone smp_mb() in
the code. As with most lone memory barriers, this one appears to be
incorrectly used.

We currently basically have this:

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);

And later we have:

if (unlikely(!have_filled_random_ptr_key))
return string(buf, end, "(ptrval)", spec);

/* Missing memory barrier here. */

hashval = (unsigned long)siphash_1u64((u64)ptr, &ptr_key);

As the CPU can perform speculative loads, we could have a situation
with the following:

CPU0 CPU1
---- ----
   load ptr_key = 0
   store ptr_key = random
   smp_mb()
   store have_filled_random_ptr_key

   load have_filled_random_ptr_key = true

    BAD BAD BAD! (you're so bad!)

Because nothing prevents CPU1 from loading ptr_key before loading
have_filled_random_ptr_key.

But this race is very unlikely, but we can't keep an incorrect smp_mb() in
place. Instead, replace the have_filled_random_ptr_key with a static_branch
not_filled_random_ptr_key, that is initialized to true and changed to false
when we get enough entropy. If the update happens in early boot, the
static_key is updated immediately, otherwise it will have to wait till
entropy is filled and this happens in an interrupt handler which can't
enable a static_key, as that requires a preemptible context. In that case, a
work_queue is used to enable it, as entropy already took too long to
establish in the first place waiting a little more shouldn't hurt anything.

The benefit of using the static key is that the unlikely branch in
vsprintf() now becomes a nop.

Link: http://lkml.kernel.org/r/20180515100558.21df515e@gandalf.local.home
Cc: stable@vger.kernel.org
Fixes: ad67b74d2469d ("printk: hash addresses printed with %p")
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
lib/vsprintf.c