On Tue, Feb 23, 2016 at 02:58:37PM +0000, Mathieu Desnoyers wrote:
> ----- On Feb 23, 2016, at 9:46 AM, Stephan Mueller [email protected] 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
> > [email protected] wrote:
> >> > On Tue, Feb 23, 2016 at 02:02:26PM +0000, Mathieu Desnoyers wrote:
> >> >> commit 7829fb09a2b4268b30dd9bc782fa5ebee278b137
> >> >> Author: Daniel Borkmann <[email protected]>
> >> >> 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
