lkml.org 
[lkml]   [2017]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [GIT PULL] gcc-plugins updates for v4.13-rc1
    On Wed, Jul 5, 2017 at 12:07 PM, Linus Torvalds
    <torvalds@linux-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

    \
     
     \ /
      Last update: 2017-07-05 23:49    [W:3.094 / U:0.504 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site