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]

Date:   Wed, 5 Jul 2017 23:12:23 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Jean Delvare <jdelvare@...e.de>
Subject: Re: [GIT PULL] gcc-plugins updates for v4.13-rc1

On Wed, Jul 5, 2017 at 9:07 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> 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 sounds useful to me, at least as a compile-time option. My first thought was
to move it under CONFIG_UBSAN, which has related undefined-behavior
checks. I see that we are disabling the -Wmaybe-uninitialized warning
with UBSAN at the moment to shut up lots of warnings introduced by
UBSAN, and that could mean one of two things: either gcc gets a lot
worse at tracing the state of variables with UBSAN, or UBSAN causes
it to warn about anything that it can't prove to be initialized rather than
making some reasonable assumptions about calls to external functions.

If the latter is true, it might be enough to just initialize the ones we would
warn about with UBSAN.

>From what I can tell, there are four main cases of local variables:

a) the most common one should be those that gcc can prove to be
    initialized at the first use. Adding a zero-initialization would be
    pointless here.
b) Those that gcc can prove to be used uninitialized, and it warns
    about with -Wuninitialized. This sounds like something that
    -fsanitize=undefined should handle, but I could not find any
    information about it actually doing that.
c) The ones that require knowledge of multiple translation units
    or functions it decided not to inline, so gcc intentionally
    doesn't warn about them (unlike smatch).
d) The ones that gcc cannot prove to be in any of the above
    categories (see: halting problem) and warns about with
    -Wmaybe-uninitialized

The last two seem like candidates for implicit zero-initialization,
while for b) one could argue that this should be treated like
some other undefined behavior and just trap (e.g. gcc now turns
code paths it knows to cause divide-by-zero into a single
trapping instruction and skips the math leading up to it). Or you
could argue that gcc shouldn't do that for other undefined
behavior either.

        Arnd