From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754249AbcBWQK5 (ORCPT ); Tue, 23 Feb 2016 11:10:57 -0500 Received: from e19.ny.us.ibm.com ([129.33.205.209]:38330 "EHLO e19.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754212AbcBWQKz (ORCPT ); Tue, 23 Feb 2016 11:10:55 -0500 X-IBM-Helo: d01dlp02.pok.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Tue, 23 Feb 2016 08:10:42 -0800 From: "Paul E. McKenney" To: Mathieu Desnoyers Cc: Stephan Mueller , Peter Zijlstra , Will Deacon , Linus Torvalds , LKML , Daniel Borkmann , Theodore Tso , Hannes Frederic Sowa , mancha security , Mark Charlebois , Behan Webster , Herbert Xu , rostedt Subject: Re: interesting commit about llvm introducing barrier_data() Message-ID: <20160223161042.GM3522@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1168693945.5302.1456236146207.JavaMail.zimbra@efficios.com> <20160223142336.GK3522@linux.vnet.ibm.com> <675593567.5328.1456237963352.JavaMail.zimbra@efficios.com> <1605703.GSn7kbzMda@tauon.atsec.com> <1316436701.5482.1456239517072.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316436701.5482.1456239517072.JavaMail.zimbra@efficios.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16022316-0057-0000-0000-000003819AFC Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 23, 2016 at 02:58:37PM +0000, Mathieu Desnoyers wrote: > ----- 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 > >> >> 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