Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1340726

Re: interesting commit about llvm introducing barrier_data()

Show all headers | View raw

----- On Feb 23, 2016, at 9:46 AM, Stephan Mueller smueller@chronox.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@linux.vnet.ibm.com wrote:
>> > On Tue, Feb 23, 2016 at 02:02:26PM +0000, Mathieu Desnoyers wrote:
>> >> commit 7829fb09a2b4268b30dd9bc782fa5ebee278b137
>> >> Author: Daniel Borkmann <daniel@iogearbox.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.

Thanks,

Mathieu


> 
> Ciao
> Stephan

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: interesting commit about llvm introducing barrier_data() Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-23 15:40 +0100
  Re: interesting commit about llvm introducing barrier_data() Stephan Mueller <smueller@chronox.de> - 2016-02-23 15:50 +0100
    Re: interesting commit about llvm introducing barrier_data() Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-23 16:00 +0100
      Re: interesting commit about llvm introducing barrier_data() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-23 17:20 +0100

csiph-web