[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160223161042.GM3522@linux.vnet.ibm.com>
Date: Tue, 23 Feb 2016 08:10:42 -0800
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Stephan Mueller <smueller@...onox.de>,
Peter Zijlstra <peterz@...radead.org>,
Will Deacon <will.deacon@....com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Theodore Tso <tytso@....edu>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
mancha security <mancha1@...o.com>,
Mark Charlebois <charlebm@...il.com>,
Behan Webster <behanw@...verseincode.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
rostedt <rostedt@...dmis.org>
Subject: Re: interesting commit about llvm introducing barrier_data()
On Tue, Feb 23, 2016 at 02:58:37PM +0000, Mathieu Desnoyers wrote:
> ----- On Feb 23, 2016, at 9:46 AM, Stephan Mueller smueller@...onox.de wrote:
>
> > Am Dienstag, 23. Februar 2016, 14:32:43 schrieb Mathieu Desnoyers:
> >
> > Hi Mathieu,
> >
> >> ----- On Feb 23, 2016, at 9:23 AM, Paul E. McKenney
> > paulmck@...ux.vnet.ibm.com wrote:
> >> > On Tue, Feb 23, 2016 at 02:02:26PM +0000, Mathieu Desnoyers wrote:
> >> >> commit 7829fb09a2b4268b30dd9bc782fa5ebee278b137
> >> >> Author: Daniel Borkmann <daniel@...earbox.net>
> >> >> Date: Thu Apr 30 04:13:52 2015 +0200
> >> >>
> >> >> lib: make memzero_explicit more robust against dead store elimination
> >> >>
> >> >> ^ interesting commit. Any idea on the impact of this on kernel RCU
> >> >> implementation and liburcu cmm_barrier() ?
> >> >
> >> > First I knew of it! But I bet that more like this are needed. ;-)
> >>
> >> I recommend you check my IRC discussion with peterz on the matter of
> >> this new "barrier_data()".
> >>
> > The key idea of the memzero_explicit is about forcing the compiler to do a
> > memset.
> >
> > See the trivial test attached.
>
> My question is mainly about documentation of the new "barrier_data()"
> added to include/linux/compiler-gcc.h. Its comment does not clearly
> state where it should be used, and where it should not be needed.
>
> If it is useful for clearing memory for security purposes, it
> should be stated in the comment above the macro, and in the
> memory-barriers.txt Documentation file.
>
> If it is useful for securely clearing local variables in
> registers and on stack, it should be documented. Or if
> variables sitting on stack are not a target here, it should
> be documented too.
>
> If there is any way this could have impacts on DMA reads/writes
> (typically only global and allocated variables), it should be
> documented.
>
> If beyond the "clearing memory for security" use-case, this
> new barrier is needed rather than barrier() for code correctness,
> it should also be documented.
Looks like this is an issue only for code that doesn't use WRITE_ONCE()
or better for writes to shared variables. Of which there does appear
to be a great deal in the kernel, to be sure...
Thanx, Paul
Powered by blists - more mailing lists