Date: Mon, 19 May 2014 11:43:02 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: thoughts on reallocarray, explicit_bzero? 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.