nico at cryptonector.com
Wed Jun 17 19:06:27 EDT 2015
On Wed, Jun 17, 2015 at 02:32:15PM -0400, Nathaniel McCallum wrote:
> On Wed, 2015-06-17 at 00:02 +0000, Danilo Almeida wrote:
> > Nathaniel wrote:
> > > I think VLAs buys a lot.
> > It seems that VLA could introduce new issues or invariants since you
> > can no longer check for allocation failure.
> You can't check for allocation failure on most operating systems' heap
> allocation these days. Now, the failure in the heap vs stack cases is
> somewhat different; and you have to be cautious to avoid some security
> issues. But with careful use, there is a lot of benefit.
Heap allocation failures are rather different than alloca() or VLA
allocation failures. alloca(), for example, has undefined behavior on
failure for obvious reasons: sp + size might land in a mapped page for a
different mapping, going well past the stack's guard page.
In practice, if the stack grows down and the elements of the VLA are
accessed from higher to lower (or the reverse if the stack grows up)
then the guard page should still work, but this isn't defined behavior.
Both are fine when the sizes are naturally limited to small sizes, but
this requires more review effort. Alternatively one could have a macro
to guard against unsafe array sizes. I'd rather VLAs and alloca() were
frowned upon (though not forbidden).
More information about the krbdev