Message-ID: <CAGXu5jLwSFp6yDbcjHmnYTTY0iM=9CQVdHnz0tYtZ++zOEvzdQ@mail.gmail.com>
Date:   Wed, 5 Jul 2017 14:49:28 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Arnd Bergmann <arnd@...db.de>, Jean Delvare <jdelvare@...e.de>
Subject: Re: [GIT PULL] gcc-plugins updates for v4.13-rc1

On Wed, Jul 5, 2017 at 12:07 PM, Linus Torvalds
<torvalds@...ux-foundation.org> 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.

-Kees

[1] e.g. https://www.internetsociety.org/sites/default/files/ndss2017_09-2_Lu_paper.pdf
performs only uninitialized on-stack pointer zeroing, and
http://www.cs.vu.nl/~giuffrida/papers/safeinit-ndss-2017.pdf shows <5%
performance hit with optimization for initializing everything
[2] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=getsockname&id=a4467f966f0c70fd232388c05798a84276eef1ef
[3] http://openwall.com/lists/kernel-hardening/2017/06/09/14

-- 
Kees Cook
Pixel Security

Powered by blists - more mailing lists