[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPLrYESpEg_yvyn0odnnr9=0Fg3Ussg7cHH=om1G_yvb8zsQ8Q@mail.gmail.com>
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.
