• S
    vsprintf: Replace memory barrier with static_key for random_ptr_key update · 85f4f12d
    Steven Rostedt (VMware) 提交于
    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: ad67b74d ("printk: hash addresses printed with %p")
    Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
    85f4f12d
vsprintf.c 74.3 KB