C99 Features

[Greg Hudson]

On 06/17/2015 02:32 PM, Nathaniel McCallum wrote:
> You can't check for allocation failure on most operating systems' heap
> allocation these days.

MIT krb5 does not assume that it is operating in such an environment, or
we could simplify an awful lot of code.  I've gently brought this up
once or twice and the consensus has been that we should continue trying
to rigorously handle malloc failures, even if not all environments make
such checks useful.

A more nuanced argument is that you can't check for the success of stack
allocation even when allocating fixed-sized automatic variables.  When
an attacker can control stack use without reasonable bounds, that
creates a DOS vector, whether the stack overrun is due to recursion or
VLAs.  The same is true for heap use without reasonable bound, although
in a threaded environment the reasonable bound for stack use has to be
significantly lower than for heap use.

In a threaded environment, VLAs of attacker-controlled size, which are
accessed in non-sequential order, could cause more significant security
issues than a DOS; you might skip over the guard page and overwrite a
different thread's stack.  The same is theoretically possible with
fixed-sized automatic variables, but there would have to be a lot of
them (or a few very large ones).

> But with careful use, there is a lot of benefit.

I agree with the conclusion.