From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6928 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: thoughts on reallocarray, explicit_bzero? Date: Wed, 28 Jan 2015 23:15:09 -0500 Message-ID: <20150129041509.GN4574@brightrain.aerifal.cx> References: <20140519153130.GA519@muslin> <20140519161654.GO507@brightrain.aerifal.cx> <20150129021919.GM4574@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1422504926 16794 80.91.229.3 (29 Jan 2015 04:15:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Jan 2015 04:15:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6941-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 29 05:15:26 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YGgVp-0007vY-U1 for gllmg-musl@m.gmane.org; Thu, 29 Jan 2015 05:15:26 +0100 Original-Received: (qmail 31817 invoked by uid 550); 29 Jan 2015 04:15:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 31801 invoked from network); 29 Jan 2015 04:15:22 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6928 Archived-At: On Wed, Jan 28, 2015 at 10:03:33PM -0600, Brent Cook wrote: > >> > Linux kernel has similar functions and uses a barrier() here: > >> > > >> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/lib/string.c?id=refs/tags/v3.19-rc6#n600 > >> > > >> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/compiler.h?id=refs/tags/v3.19-rc6#n162 > >> > > >> > Is such a solution is more correct (and still portable)? > >> > >> I'm afraid that the only appropriate solution is to use memset_s() > >> from C11 and the expectation that the compiler will accept it. > >> barrier() does not give any guarantee that this function will be > >> secure. Only compiler decides. I'm afraid that OpenBSD goes bad path > >> with explicit_bzero(). The same applies to the linux kernel and > >> memzero_explicit().. very stupid name... > > > > I see no way memset_s is technically "better". It's unable to find and > > clear other temporary copies that have been made, and the barrier > > method described above already reliably clears the pointed-to copy. > > Whatever method you choose, the method of testing is an interesting > one, since seeing if the compiler optimized out a memset (because the > memory was not read after a write) requires tricking the compiler into > believing you aren't reading it. This test is pretty cool, IMO: > > https://github.com/libressl-portable/openbsd/blob/master/src/regress/lib/libc/explicit_bzero/explicit_bzero.c > > it is described a bit more here: > https://plus.google.com/+MatthewDempsky/posts/KQHFBouxurX The comment that pthread_attr_setstack could be used instead is interesting and would make the test a lot simpler, I think. > Getting around link-time optimizations required building the > explicit_bzero function with independent compiler flags to ensure LTO > was not enabled. As long as there's a barrier, LTO is no problem. The asm is a black box that's required to see the results of memset, since the address of the object reaches the asm, and the only way to ensure that such a black box sees the writes is for them to actually be performed. Rich