linux-kernel - Re: [PATCH] vsprintf: Fix memory barriers of ptr_key to have_filed_random_ptr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180523104037.GD15312@amd>
Date:   Wed, 23 May 2018 12:40:37 +0200
From:   Pavel Machek <pavel@....cz>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Kees Cook <keescook@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        tcharding <me@...in.cc>
Subject: Re: [PATCH] vsprintf: Fix memory barriers of ptr_key to
 have_filed_random_ptr_key

On Tue 2018-05-15 14:57:44, Steven Rostedt wrote:
> On Tue, 15 May 2018 09:55:13 -0700
> Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> > On Tue, May 15, 2018 at 7:06 AM Steven Rostedt <rostedt@...dmis.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.

OTOH... fixing theoretical races is nice, but probably should not go
to stable?
								Pavel
								
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)