From: Kees Cook <kees@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Kees Cook" <kees@kernel.org>,
"Justin Stitt" <justinstitt@google.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Mark Rutland" <mark.rutland@arm.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
"Suren Baghdasaryan" <surenb@google.com>,
"Thomas Gleixner" <tglx@kernel.org>,
"Finn Thain" <fthain@linux-m68k.org>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
llvm@lists.linux.dev, "Marco Elver" <elver@google.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Nicolas Schier" <nsc@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kbuild@vger.kernel.org
Subject: [PATCH 5/5] types: Add standard __ob_trap and __ob_wrap scalar types
Date: Tue, 31 Mar 2026 09:37:23 -0700 [thread overview]
Message-ID: <20260331163725.2765789-5-kees@kernel.org> (raw)
In-Reply-To: <20260331163716.work.696-kees@kernel.org>
While Linux's use of -fno-strict-overflow means that all arithmetic
operations have a defined behavior (2's-complement wrapping), there
isn't a way to unambiguously specify if a given variable was designed
or intended to wrap around by the author.
Introduce explicit trapping and wrapping types for all bit widths
including architecture word length (i.e. "long"), signed and unsigned,
for use going forward for unambiguous arithmetic, now available via
Clang 23+'s Overflow Behavior Types[1] (CONFIG_OVERFLOW_BEHAVIOR_TYPES=y).
Bike shedding time! How should these be named? We already have the short
bit width types, named as: {u,s}{8,16,32,64}. We need to construct new
type names that also indicate their overflow behavior: "trapping" or
"wrapping". And we need to capture the "architectural word" length type
too (i.e. what "unsigned long" or "size_t" captures).
Whole word addition:
- Pro: Unambiguous
- Con: Long. E.g. suffixed "u16_trap", or prefixed "wrap_u16"
Single letter addition, "t" for "trap" and "w" for "wrap":
- At the end: but "u8t" looks like the "t" is "type", like "uint8_t".
- At the front: but "wu8" looks like the "w" is "wide", like "wchar_t".
Current straw-man proposal is single letter suffix because it vaguely
felt like the least bad of all choices, and they should be short or
everyone will just continue to type "int". :)
Link: https://clang.llvm.org/docs/OverflowBehaviorTypes.html [1]
Signed-off-by: Kees Cook <kees@kernel.org>
---
Cc: Justin Stitt <justinstitt@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Finn Thain <fthain@linux-m68k.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
Cc: <llvm@lists.linux.dev>
---
include/linux/types.h | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/include/linux/types.h b/include/linux/types.h
index 7e71d260763c..786eb2c9775f 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -94,6 +94,30 @@ typedef unsigned int uint;
typedef unsigned long ulong;
typedef unsigned long long ullong;
+/* Trapping types. */
+typedef u8 __ob_trap u8t;
+typedef u16 __ob_trap u16t;
+typedef u32 __ob_trap u32t;
+typedef u64 __ob_trap u64t;
+typedef unsigned long __ob_trap ulongt;
+typedef s8 __ob_trap s8t;
+typedef s16 __ob_trap s16t;
+typedef s32 __ob_trap s32t;
+typedef s64 __ob_trap s64t;
+typedef signed long __ob_trap slongt;
+
+/* Wrapping types. */
+typedef u8 __ob_wrap u8w;
+typedef u16 __ob_wrap u16w;
+typedef u32 __ob_wrap u32w;
+typedef u64 __ob_wrap u64w;
+typedef unsigned long __ob_wrap ulongw;
+typedef s8 __ob_wrap s8w;
+typedef s16 __ob_wrap s16w;
+typedef s32 __ob_wrap s32w;
+typedef s64 __ob_wrap s64w;
+typedef signed long __ob_wrap slongw;
+
#ifndef __BIT_TYPES_DEFINED__
#define __BIT_TYPES_DEFINED__
--
2.34.1
next prev parent reply other threads:[~2026-03-31 16:37 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 16:37 [PATCH 0/5] Introduce Overflow Behavior Types Kees Cook
2026-03-31 16:37 ` [PATCH 1/5] refcount: Remove unused __signed_wrap function annotations Kees Cook
2026-03-31 16:37 ` [PATCH 2/5] hardening: Introduce Overflow Behavior Types support Kees Cook
2026-03-31 16:37 ` [PATCH 3/5] compiler_attributes: Add overflow_behavior macros __ob_trap and __ob_wrap Kees Cook
2026-03-31 17:01 ` Miguel Ojeda
2026-03-31 17:09 ` Miguel Ojeda
2026-03-31 17:09 ` Justin Stitt
2026-03-31 17:14 ` Miguel Ojeda
2026-03-31 17:17 ` Justin Stitt
2026-03-31 19:52 ` Kees Cook
2026-04-01 9:08 ` Peter Zijlstra
2026-04-01 20:21 ` Kees Cook
2026-04-01 20:30 ` Peter Zijlstra
2026-04-01 20:55 ` Kees Cook
2026-04-01 23:42 ` Justin Stitt
2026-04-02 9:13 ` David Laight
2026-03-31 17:16 ` Linus Torvalds
2026-03-31 17:18 ` Linus Torvalds
2026-04-01 7:19 ` Vincent Mailhol
2026-04-01 9:20 ` Peter Zijlstra
2026-04-01 19:43 ` Kees Cook
2026-04-01 19:42 ` Kees Cook
2026-03-31 16:37 ` [PATCH 4/5] lkdtm/bugs: Add basic Overflow Behavior Types test Kees Cook
2026-03-31 17:16 ` Justin Stitt
2026-03-31 16:37 ` Kees Cook [this message]
2026-03-31 17:10 ` [PATCH 5/5] types: Add standard __ob_trap and __ob_wrap scalar types Linus Torvalds
2026-03-31 17:47 ` Miguel Ojeda
2026-03-31 18:02 ` Linus Torvalds
2026-03-31 18:25 ` Linus Torvalds
2026-03-31 18:59 ` Kees Cook
2026-03-31 20:01 ` Linus Torvalds
2026-03-31 18:32 ` Kees Cook
2026-03-31 18:36 ` Linus Torvalds
2026-03-31 18:16 ` Kees Cook
2026-03-31 20:03 ` Kees Cook
2026-03-31 20:11 ` Linus Torvalds
2026-03-31 20:18 ` Linus Torvalds
2026-03-31 20:31 ` Kees Cook
2026-03-31 20:58 ` Linus Torvalds
2026-03-31 21:50 ` Justin Stitt
2026-03-31 23:49 ` Kees Cook
2026-03-31 23:50 ` Linus Torvalds
2026-04-01 8:31 ` Peter Zijlstra
2026-04-01 20:52 ` Kees Cook
2026-04-02 5:38 ` Peter Zijlstra
2026-04-01 8:57 ` Peter Zijlstra
2026-04-01 20:23 ` Kees Cook
2026-04-01 9:38 ` Peter Zijlstra
2026-04-01 21:41 ` Kees Cook
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=20260331163725.2765789-5-kees@kernel.org \
--to=kees@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=corbet@lwn.net \
--cc=elver@google.com \
--cc=fthain@linux-m68k.org \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=justinstitt@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=nathan@kernel.org \
--cc=nsc@kernel.org \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=surenb@google.com \
--cc=tglx@kernel.org \
--cc=thomas.weissschuh@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.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