Re: GCC Compiler Induced Vulnerability - affects programs compiled with GCC 7 and 8 containing nested functions

[Jeff Law <law () redhat com>]

On 10/23/18 8:20 AM, Florian Weimer wrote:
> * Solar Designer:
>
> > 3. Andrew writes: "Most if not all C++ compilers are able to produce
> > code from lambdas (similar to nested functions) without compromising the
> > call stack."  It'd be helpful to explore this more and see whether
> > there's any fundamental difference preventing reuse of the same approach
> > (whatever it is) for nested functions as well.  I'd appreciate
> > discussion of this on oss-security.  My guess is this probably doesn't
> > fit in the existing ABI for C, but I might be wrong.
>
> std::function in C++ isn't just a code pointer.  It's more like a
> function descriptor on some architectures, so you don't need to generate
> a trampoline because the called code can load ancilarry information
> (such as the static chain pointer or other information to access
> captured variables), without having to encode this in the pointer
> itself.
>
> There are other ways to produce trampolines which do not need an
> executable stack, and even ways that avoid code generation at run time
> (such as pre-cooked array of trampoline code that gets mapped multiple
> times as needed).
True.  GCC in fact even has some capabilities to use alternate sequences
for trampolines (used for Ada on some targets, ultimately looks like
procedure descriptors).  Those alternate approaches do require
generating alternate code sequences at the call site, so it's "mass
rebuild" kind of change to make.

In the end, stack based trampolines (and by extension C/C++ nested
functions in GCC) are generally a bad idea.  But to call it a GCC
Compiler Induced Vulnerability is a bit of a stretch.

Jeff