From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5128 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: thoughts on reallocarray, explicit_bzero? Date: Mon, 19 May 2014 11:43:02 -0400 Message-ID: <20140519154302.GN507@brightrain.aerifal.cx> References: <20140519153130.GA519@muslin> 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 1400514203 27968 80.91.229.3 (19 May 2014 15:43:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 May 2014 15:43:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5133-gllmg-musl=m.gmane.org@lists.openwall.com Mon May 19 17:43:16 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WmPid-0006JF-SR for gllmg-musl@plane.gmane.org; Mon, 19 May 2014 17:43:15 +0200 Original-Received: (qmail 23680 invoked by uid 550); 19 May 2014 15:43:15 -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 23670 invoked from network); 19 May 2014 15:43:15 -0000 Content-Disposition: inline In-Reply-To: <20140519153130.GA519@muslin> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5128 Archived-At: On Mon, May 19, 2014 at 08:31:31AM -0700, Isaac Dunham wrote: > Having read up on the LibreSSL fork of OpenSSL and also recently > backported a nuber of libXfont CVE fixes for integer overflows, > I've seen the risk posed by malloc(n*sizeof(x)) and realloc(ptr, > n*sizeof(x)). > calloc(n, sizeof(x)) can be used in place of malloc(n * sizeof(x)), > but there's no standard function that does overflow checking for > realloc(). OpenBSD has provided the extension reallocarray(), which > provides for bounds checking like calloc() does. > > Additionally, there are times when a compiler will optimize away calls > to bzero() on areas that are not used before free(); this can result in > passwords getting left in memory. OpenBSD uses a wrapper function called > explicit_bzero() to keep this from happening, thugh it seems to be possible > to use some ugliness with volatile to stop it. > > Should musl provide reallocarray()? I don't think so; there's no precedent for it yet except OpenBSD. LibreSSL should just add a fallback implementation (trivial to write as a wrapper to realloc) for all non-OpenBSD systems that lack it. I'm not fundamentally opposed to reallocarray, but I also don't think it's useful to implement it unless there's a consensus from other implementations on adding it. > And what's the best way to ensure that memory gets zeroed out? read() from /dev/zero? ;-) Seriously, this is a tough one, because no matter what you try, a smart enough compiler will work around it. There's the Annex K memset_s, but Annex K is generally horrible. The OpenBSD approach of "explicit_bzero" is also pretty bad since "bzero" is a deprecated interface. Note that there's not even a way to _implement_ this kind of zero-filling without resorting to compiler extensions or asm. The compiler is free (e.g. with LTO) to look inside the implementation and determine that it does nothing. Solar has one clever "solution" to this problem in the bcrypt code he contributed to musl (see the source for the trick) but it's not an explicit zeroing; rather it's a reuse of the buffer in a way that would be very difficult for the compiler to optimize out. Rich