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

From: James Y Knight <jyknight@google.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: gregkh@linuxfoundation.org,
	Nick Desaulniers <ndesaulniers@google.com>,
	mka@chromium.org, Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	tglx@linutronix.de, Andrew Morton <akpm@linux-foundation.org>,
	Chandler Carruth <chandlerc@google.com>,
	Stephen Hines <srhines@google.com>,
	Kees Cook <keescook@google.com>,
	groeck@chromium.org, Greg Hackmann <ghackmann@google.com>
Subject: Re: [GIT PULL] x86/build changes for v4.17
Date: Wed, 04 Apr 2018 22:21:05 +0000	[thread overview]
Message-ID: <CAA2zVHqMS7HQggLnhQc9qjUhnD5MQXcyXkVnCQ0BoKqC8i3vgw@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFysRcOu7F-kZKNWp_fY1DViQoz7OmXUBeD0xhXROvPYqA@mail.gmail.com>

On Wed, Apr 4, 2018 at 3:42 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> 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"..

The -fno-strict-overflow flag in clang does do that. You can subtract any
two random pointers you have, whether they're in the same object or not,
even if the math overflows. And you can later add things back together, and
end up back where you started, and load the value. No problem, even though
subtracting pointers from unrelated objects is illegal according to C.

That's why container_of as it's written in the kernel does work in clang --
wrapping arithmetic when given a NULL pointer and everything. (as a
sidenote...it would be a readability improvement to make container_of do
its math with a uintptr_t instead of a void*, since it would be more
*obviously* correct...)

But allowing random pointer arithmetic, and pointer arithmetic wraparound,
is still different than asserting that an object _field access_ can
overflow. Clang does not believe that can happen -- it assumes that an
object will still be contiguous. And that's why the llist stuff used to be
broken, before it was corrected to do simply do math on a uintptr_t (which
is a nice and simple and sane fix!).