From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6927 Path: news.gmane.org!not-for-mail From: Brent Cook Newsgroups: gmane.linux.lib.musl.general Subject: Re: thoughts on reallocarray, explicit_bzero? Date: Wed, 28 Jan 2015 22:03:33 -0600 Message-ID: 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1422504228 6996 80.91.229.3 (29 Jan 2015 04:03:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Jan 2015 04:03:48 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6940-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 29 05:03:48 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 1YGgKY-0005zB-Of for gllmg-musl@m.gmane.org; Thu, 29 Jan 2015 05:03:46 +0100 Original-Received: (qmail 23892 invoked by uid 550); 29 Jan 2015 04:03:45 -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 23884 invoked from network); 29 Jan 2015 04:03:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=Pl+RQn4MHLLJapBo4FOzrFlaiduZvZLCs+wCSWo8pKA=; b=pgu5MMIV076Y0zWwmqN6mp5+5FCbTCk8AOvUShfRJgn+8yv+ECaYaW2YG3sC1lh0/+ 9USkXhg58I6HsquZptHC9Zc/5llVnXZCAk/xPdTb8YDg20ymXmd/3Yy35qclw2aPTwHE Vm7GVRPnBcTHtb0LgnNVnvLNWB0qA/mx4uQQfedndrJUQ0yzNKmzx/NWSIiH75xs99yL vzPAnoEgARqfWT5ldOz8dcME/2Nwl4cTpqmUz5DaB5kV6aq19bX1IWvlsIRIRKrvtDkz IsTHyp+z5U4hKmiaTqPJbT3juYkJBYjslOhHXB0L6hz27OwdgWGknOsnGIxxnZTULkuh RrfQ== X-Received: by 10.152.44.228 with SMTP id h4mr12029788lam.31.1422504213148; Wed, 28 Jan 2015 20:03:33 -0800 (PST) In-Reply-To: <20150129021919.GM4574@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:6927 Archived-At: On Wed, Jan 28, 2015 at 8:19 PM, Rich Felker wrote: > On Wed, Jan 28, 2015 at 11:34:20PM +0100, Daniel Cegie=C5=82ka wrote: >> 2015-01-28 23:01 GMT+01:00 Daniel Cegie=C5=82ka : >> > 2014-05-19 18:16 GMT+02:00 Rich Felker : >> >> On Mon, May 19, 2014 at 05:44:59PM +0200, Daniel Cegie=C5=82ka wrote: >> > >> >>> diff -urN musl.orig/src/string/explicit_bzero.c musl/src/string/expl= icit_bzero.c >> >>> --- musl.orig/src/string/explicit_bzero.c Thu Jan 1 00:00:00 19= 70 >> >>> +++ musl/src/string/explicit_bzero.c Fri May 9 09:57:45 2014 >> >>> @@ -0,0 +1,8 @@ >> >>> +#include >> >>> + >> >>> +static void *(*volatile explicit_memset)(void *, int, size_t) =3D m= emset; >> >>> + >> >>> +void explicit_bzero(void *b, size_t len) >> >>> +{ >> >>> + (*explicit_memset)(b, 0, len); >> >>> +} >> >> >> >> This is a nice trick, but IIRC I actually observed GCC optimizing out >> >> similar code before (instead of your static volatile, I used a >> >> volatile compound literal). At least the concept is right though: you >> >> want to prevent the compiler from being able to do any flow analysis >> >> at compile time, and making the function pointer volatile achieves >> >> this rather well. On the other hand, GCC will put the volatile pointe= r >> >> (if it even emits it) in non-constant memory, meaning it's an >> >> additional attack vector for function-pointer-overwrite attacks. >> > >> > Linux kernel has similar functions and uses a barrier() here: >> > >> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/l= ib/string.c?id=3Drefs/tags/v3.19-rc6#n600 >> > >> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/i= nclude/linux/compiler.h?id=3Drefs/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. > > Rich 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/li= bc/explicit_bzero/explicit_bzero.c it is described a bit more here: https://plus.google.com/+MatthewDempsky/posts/KQHFBouxurX Getting around link-time optimizations required building the explicit_bzero function with independent compiler flags to ensure LTO was not enabled.