From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5132 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: thoughts on reallocarray, explicit_bzero? Date: Mon, 19 May 2014 18:25:57 +0200 Message-ID: <20140519162556.GY12324@port70.net> 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 1400516779 14830 80.91.229.3 (19 May 2014 16:26:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 May 2014 16:26:19 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5137-gllmg-musl=m.gmane.org@lists.openwall.com Mon May 19 18:26:10 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 1WmQO9-000435-VX for gllmg-musl@plane.gmane.org; Mon, 19 May 2014 18:26:10 +0200 Original-Received: (qmail 24573 invoked by uid 550); 19 May 2014 16:26:09 -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 24565 invoked from network); 19 May 2014 16:26:09 -0000 Content-Disposition: inline In-Reply-To: <20140519153130.GA519@muslin> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:5132 Archived-At: * Isaac Dunham [2014-05-19 08:31:31 -0700]: > 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. i'd use a saturated multiplication, because malloc/realloc are not the only places where overflowing size calculations may cause problems and in such cases (size_t)-1 is just as good as a failure and it can be added to your code without portability issues static size_t sizemul(size_t a, size_t b) { return b>1 && a>1 && a>-1/b ? -1 : a*b; } > 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. i don't see how the openbsd explicit_bzero stops the compiler to do optimizations.. (i guess they rely on that their gcc does not do lto or that libc is dynamic linked and the compiler has no 'explicit_bzero' builtin, neither of which is a great solution..) the usual approach to this is volatile function pointer: static void *(*volatile force_memset)(void,int,size_t) = memset; in general in c one cannot be sure that the secret bits are not leaked somewhere since the languge spec cannot give such guarantees that said either the volatile funcptr or actually reusing the memory such that it cannot be optimized away works in practice > Should musl provide reallocarray()? > And what's the best way to ensure that memory gets zeroed out? > > Thanks, > Isaac Dunham