From: Peter Zijlstra <peterz@infradead.org>
To: Kees Cook <kees@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
Justin Stitt <justinstitt@google.com>,
Mark Rutland <mark.rutland@arm.com>,
linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev
Subject: Re: [RFC] Mitigating unexpected arithmetic overflow
Date: Thu, 16 May 2024 16:09:51 +0200 [thread overview]
Message-ID: <20240516140951.GK22557@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <25882715-FE44-44C0-BB9B-57F2E7D1F0F9@kernel.org>
On Thu, May 16, 2024 at 06:30:32AM -0700, Kees Cook wrote:
>
>
> On May 15, 2024 12:36:36 AM PDT, Peter Zijlstra <peterz@infradead.org> wrote:
> >On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:
> >> For example, the most common case of overflow we've ever had has very
> >> much been array indexing. Now, sometimes that has actually been actual
> >> undefined behavior, because it's been overflow in signed variables,
> >> and those are "easy" to find in the sense that you just say "no, can't
> >> do that". UBSAN finds them, and that's good.
> >
> >We build with -fno-strict-overflow, which implies -fwrapv, which removes
> >the UB from signed overflow by mandating 2s complement.
>
> I am a broken record. :) This is _not_ about undefined behavior.
And yet you introduced CONFIG_UBSAN_SIGNED_WRAP... *UB*san, get it?
> This is about finding a way to make the intent of C authors
> unambiguous. That overflow wraps is well defined. It is not always
> _desired_. C has no way to distinguish between the two cases.
The current semantics are (and have been for years, decades at this
point) that everything wraps nicely and code has been assuming this. You
cannot just change this.
So what you do is do a proper language extension and add a type
qualifier that makes overflows trap and annotate all them cases where
people do not expect overflows (so that we can put the
__builtin_*_overflow() things where the sun don't shine).
And pretty please, also do a qualifier modification extension, because
that's totally painful already.
next prev parent reply other threads:[~2024-05-16 14:09 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 23:27 [RFC] Mitigating unexpected arithmetic overflow Kees Cook
2024-05-08 12:22 ` David Laight
2024-05-08 23:43 ` Kees Cook
2024-05-08 17:52 ` Linus Torvalds
2024-05-08 19:44 ` Kees Cook
2024-05-08 20:07 ` Linus Torvalds
2024-05-08 22:54 ` Kees Cook
2024-05-08 23:47 ` Linus Torvalds
2024-05-09 0:06 ` Linus Torvalds
2024-05-09 0:23 ` Linus Torvalds
2024-05-09 6:11 ` Kees Cook
2024-05-09 14:08 ` Theodore Ts'o
2024-05-09 15:38 ` Linus Torvalds
2024-05-09 17:54 ` Al Viro
2024-05-09 18:08 ` Linus Torvalds
2024-05-09 18:39 ` Linus Torvalds
2024-05-09 18:48 ` Al Viro
2024-05-09 19:15 ` Linus Torvalds
2024-05-09 19:28 ` Al Viro
2024-05-09 21:06 ` David Laight
2024-05-18 5:11 ` Matthew Wilcox
2024-05-09 21:23 ` David Laight
2024-05-12 8:03 ` Martin Uecker
2024-05-12 16:09 ` Linus Torvalds
2024-05-12 19:29 ` Martin Uecker
2024-05-13 18:34 ` Kees Cook
2024-05-15 7:36 ` Peter Zijlstra
2024-05-15 17:12 ` Justin Stitt
2024-05-16 7:45 ` Peter Zijlstra
2024-05-16 13:30 ` Kees Cook
2024-05-16 14:09 ` Peter Zijlstra [this message]
2024-05-16 19:48 ` Justin Stitt
2024-05-16 20:07 ` Kees Cook
2024-05-16 20:51 ` Theodore Ts'o
2024-05-17 21:15 ` Kees Cook
2024-05-18 2:51 ` Theodore Ts'o
2024-05-17 22:04 ` Fangrui Song
2024-05-18 13:08 ` David Laight
2024-05-15 7:57 ` Peter Zijlstra
2024-05-17 7:45 ` Jonas Oberhauser
2024-05-11 16:19 ` Dan Carpenter
2024-05-13 19:43 ` Kees Cook
2024-05-14 8:45 ` Dan Carpenter
2024-05-18 15:39 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240516140951.GK22557@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=justinstitt@google.com \
--cc=kees@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).