Date: Mon, 19 May 2014 17:44:59 +0200 From: Daniel Cegiełka <daniel.cegielka@...il.com> To: musl@...ts.openwall.com Subject: Re: thoughts on reallocarray, explicit_bzero? 2014-05-19 17:31 GMT+02:00 Isaac Dunham <ibid.ag@...il.com>: > 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()? In my opinion, yes, we should. btw. no bzero()/bcopy() but memset() and memcpy() etc. Daniel > And what's the best way to ensure that memory gets zeroed out? > > Thanks, > Isaac Dunham View attachment "explicit_bzero.diff" of type "text/plain" (796 bytes) View attachment "reallocarray.diff" of type "text/plain" (1131 bytes)
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.