Re: [GIT PULL] gcc-plugins updates for v4.13-rc1

From: Kees Cook
Date: Wed Jul 05 2017 - 17:49:35 EST

On Wed, Jul 5, 2017 at 12:07 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> Hmm. Completely unrelated comment, and this may not be a gcc 'plugin'
> issue as much as a more general gcc question, but I suspect a plugin
> could do it.
> For the kernel, we already really ignore some of the more idiotic C
> standard rules that introduce pointless undefined behavior: things
> like the strict aliasing rules are just insane, and the "overflow is
> udnefined" is bad too. So we use
> -fno-strict-aliasing
> -fno-strict-overflow
> -fno-delete-null-pointer-checks
> to basically say "those optimizations are fundamentally stupid and
> wrong, and only encourage compilers to generate random code that
> doesn't actually match the source code".
> And I suspect one other undefined behavior is the one we _try_ to warn
> about, but where the compiler is not always good enough to give valid
> warnings - uninitialized automatic variables.
> Maybe we could have gcc just always initialize variables to zero. Not
> just static ones, but the automatic variables too. And maybe it
> wouldn't generate much extra code, since gcc will see the real
> initialization, and the extra hardening against random behavior will
> just go away - so this might be one of those cheap things where we
> just avoid undefined behavior and avoid leaking old stack contents.
> Yes, yes, you'd still have the uninitialized variable warning, but
> that doesn't catch the case where you pass a structure pointer to a
> helper that is *supposed* to fill it in, but misses a field or just
> misses padding.
> And maybe I'm wrong, and maybe it would generate a lot of really bad
> extra zeroing and wouldn't be acceptable for most people, but I
> *think* this might be one of those things where we might get some
> extra belt and suspenders kind of hardening basically for free..
> Comments?

It is, unfortunately, not free. :( There has been a lot of academic
research[1] into finding ways to minimize the impact, but given some
of the Linux maintainers refusing even zeroing of APIs that pass
stack-based structures[2]. Another thing that has been worked on is
porting the stackleak gcc plugin from grsecurity to upstream[3]. This
does effective clearing of the stack, but it takes a more holistic
approach (and for added fun, it does alloca probes too). Like some of
the more comprehensive academic attempts, it sees about a 4% hit (but
it's doing more...)

I'd love to get the stackleak plugin into upstream (and the work is
on-going), but having something try a "lighter" form of this in a gcc
plugin would be interesting to experiment with.


[1] e.g.
performs only uninitialized on-stack pointer zeroing, and shows <5%
performance hit with optimization for initializing everything

Kees Cook
Pixel Security