linux-kernel - Re: [GIT PULL] x86/build changes for v4.17

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, 4 Apr 2018 12:42:06 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     James Y Knight <jyknight@...gle.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Chandler Carruth <chandlerc@...gle.com>,
        Stephen Hines <srhines@...gle.com>,
        Kees Cook <keescook@...gle.com>, groeck@...omium.org,
        Greg Hackmann <ghackmann@...gle.com>
Subject: Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 12:26 PM, James Y Knight <jyknight@...gle.com> wrote:
>
> (OTOH, I _do_ expect clang to eventually gain support for a flag to treat
> NULL-pointer deref as a legal operation instead of UB. I'm not really sure
> it makes sense for the linux kernel, but it's a useful feature for the
> compiler to provide in any case, so why not...)

I would actually argue that this is more closely related to
"-fno-strict-overflow" than to "-fno-delete-null-pointer-checks'.

It just happens to be about pointer arithmetic, rather than about
signed integers. We *will* do arithmetic with NULL pointers that can
wrap.

Yes, the kernel does odd things with pointers in general. I won't
apologize for it, because we have really good reasons for doing so.

The whole "we take offsets of pointers even *backwards*" is because we
extensively rely on embedding structures inside each other. If clang
actually did proper optimization, it would have noticed that the
"offset backwards" was followed by an "offset forwards" and then a
NULL pointer check, and that there actually was no actual real
wrapping or non-contiguous behavior in reality.

But clang didn't do that, and instead blindly said "you're going
forwards and the result can't be NULL", without ever looking at "oh,
they went backwards first".

So honestly, part of the problem we had with clang was that it was too
*stupid* to see that what we did wasn't actually invalid even by
clang's own standards!

I'm not saying that the kernel use is really standards compliant,
because there definitely are those temporary pointer values (that are
never used!) that point outside an object.

But honestly, the clang "optimization" is really quite debatable, and
we'd want to turn it off - or just have clang be smarter enough that
it sees that "oh, it all stays within the object after all".

We do other things to pointers that the standard may not cover. Deal
with it. Any malloc() library will similarly just depend on pointer
arithmetic really working. We may admittedly take it to some
ridiculous degrees, with the whole "ok, we assign negative values to
pointers as error cases" in addition to the "we use container_of() to
look uip pointers *backwards*" thing.

So we'd definitely want that "-fno-strict-overflow" to affect pointer
arithmetic too (or have a separate flag for the pointer equivalent of
"we play games that may temporarily wrap pointer values around"..

                 Linus