Re: thoughts on reallocarray, explicit_bzero?

[Andy Lutomirski <luto@amacapital.net>]

On 05/19/2014 09:25 AM, Szabolcs Nagy wrote:
> * Isaac Dunham <ibid.ag@gmail.com> [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;
> }

Before going nuts trying to optimize this, it may pay to write some
good-enough helper and to use native compiler support for this, which is
already available in Clang [1] and should be coming reasonably soon in
gcc [2].

I suspect that, on all reasonably platforms, if doublesize_t is the
unsigned type that's twice as wide as size_t, then this isn't too bad
either:

doublesize_t total = (doublesize_t)a * (doublesize_t)b;
if (total > SIZE_MAX)
  fail;

For quite a while, gcc has had a 128-bit integer type that works on
64-bit platforms, and gcc should always support a 64-bit type on 32-bit
platforms.  On systems with widening multiply (e.g. x86), even if the
optimizer doesn't detect the idiom, this is only a few cycles slower
than the optimal code.

[1]
http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61129

--Andy