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 for Android: free password hash cracker in your pocket

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

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

On 5 July 2017 at 20:07, 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.
>

At the language level, I would be surprised if the compiler exploits
this as undefined behaviour, i.e., that it would assume a convenient
[for the compiler] fixed value for a variable in cases where it can
prove that it has not been initialised. And at the logical level, zero
may not always be a suitable default, this highly depends on the
particular code sequence.

So while I think it may be useful for robustness, to avoid erratic
behavior or exploitable interactions between different parts of the
code, my estimation is that it wouldn't make a great deal of
difference, given that the logic that allows the compiler to 'see the
real initialization' is the same logic that warns us if it is lacking,
and so in a warning free build, no init sequences should have been
emitted to begin with.