Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1681811

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

Show all headers | View raw

On Wed, Jul 5, 2017 at 9:07 PM, Linus Torvalds
<torvalds@linux-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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[GIT PULL] gcc-plugins updates for v4.13-rc1 Kees Cook <keescook@chromium.org> - 2017-07-05 07:10 +0200
  Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-05 21:10 +0200
    Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-07-05 22:50 +0200
      Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-05 23:40 +0200
        Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Arnd Bergmann <arnd@arndb.de> - 2017-07-05 23:50 +0200
          Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Kees Cook <keescook@chromium.org> - 2017-07-06 00:00 +0200
          Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-06 00:00 +0200
            Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-07-06 00:30 +0200
              Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-06 00:40 +0200
            Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Andrey Ryabinin <ryabinin.a.a@gmail.com> - 2017-07-06 00:50 +0200
    Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Arnd Bergmann <arnd@arndb.de> - 2017-07-05 23:20 +0200
    Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 Kees Cook <keescook@chromium.org> - 2017-07-05 23:50 +0200

csiph-web