From: Justin Stitt <justinstitt@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Kees Cook <kees@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
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 12:48:47 -0700 [thread overview]
Message-ID: <CAFhGd8qCCCrccQ2z5bjBD5YcMWHkym9aVz_qYkyyj662XEeHvA@mail.gmail.com> (raw)
In-Reply-To: <20240516140951.GK22557@noisy.programming.kicks-ass.net>
Hi,
On Thu, May 16, 2024 at 7:09 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Thu, May 16, 2024 at 06:30:32AM -0700, Kees Cook wrote:
> >
> > I am a broken record. :) This is _not_ about undefined behavior.
>
> And yet you introduced CONFIG_UBSAN_SIGNED_WRAP... *UB*san, get it?
We should think of UBSAN as an "Unexpected Behavior" Sanitizer. Clang
has evolved to provide instrumentation for things that are not
*technically* undefined behavior.
Go to [1] and grep for some phrases like "not undefined behavior" and
see that we have quite a few sanitizers that aren't *technically*
handling undefined behavior.
>
> > 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.
Why not :>)
Lots and lots of exploits are caused by unintentional arithmetic overflow [2].
>
> 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).
It is incredibly important that the exact opposite approach is taken;
we need to be annotating (or adding type qualifiers to) the _expected_
overflow cases. The omniscience required to go and properly annotate
all the spots that will cause problems would suggest that we should
just fix the bug outright. If only it was that easy.
I don't think we're capable of identifying every single problematic
overflow/wraparound case in the kernel, this is pretty obvious
considering we've had decades to do so. Instead, it seems much more
feasible that we annotate (very, very minimally so as not to disrupt
code readability and style) the spots where we _know_ overflow should
happen.
[1]: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#ubsan-checks
[2]: https://cwe.mitre.org/data/definitions/190.html
Thanks
Justin
next prev parent reply other threads:[~2024-05-16 19:48 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
2024-05-16 19:48 ` Justin Stitt [this message]
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=CAFhGd8qCCCrccQ2z5bjBD5YcMWHkym9aVz_qYkyyj662XEeHvA@mail.gmail.com \
--to=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=peterz@infradead.org \
--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).