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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFwku_yentgkzJ4To4oeK0HvTH6yyGVrhks6NBFK6+gS9Q@mail.gmail.com>
Date:   Wed, 5 Jul 2017 12:07:42 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Kees Cook <keescook@...omium.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

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?

                       Linus