Re: [PATCH 5/5] types: Add standard __ob_trap and __ob_wrap scalar types

[Kees Cook <kees@kernel.org>]

On Tue, Mar 31, 2026 at 11:02:03AM -0700, Linus Torvalds wrote:
> On Tue, 31 Mar 2026 at 10:48, Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > In the Rust side, even if those "explicit" types like the
> > `wrapping_u32` you suggest exist, we generally use the methods on the
> > normal integers instead, e.g.
> 
> In that case the types in question should always be very much opaque,
> and not usable as-is by existing compilers that don't have attributes.
> 
> My feeling is that that will discourage use enormously for when people
> want to just say "yes, I know this wraps, and it's ok".
> 
> That said, for the *trapping* types, I do think that we likely need an
> opaque type, because I really feel like using
> 
>    trapping_u32 x;
>    ...
>    x++;
> 
> is a complete and utter mis-design. It makes the "x++' have random behavior that
> 
>  (a) cannot be recovered from (maybe we're holding random locks)
> 
>  (b) is completely invisible in the context of the code, because the
> type may be somewhere very different
> 
> and I think both of those are fundamental design mistakes.

This design is specifically what Peter was requesting, and what actually
integrates with C. I agree with you that the core problem is "cannot be
recovered from", but that misses the point of these types. The point is
that all of their uses are _supposed_ to have been written in a way that
no overflow is possible (just like all the other types). But this is
the problem: bugs keep happening, no matter what people try to do. And
in fact, to support these kinds of in-code overflow checking, there are
even idiom exclusions for these types (based on what you pointed out in
the original RFC) to allow for things like:

	if (var + offset < var) { ... }

If the code was written perfectly, then there's no problem. If there was
a bug that allows for overflow then you get a crash instead of totally
insane behavior that is almost always exploitable in a way that the
system gets compromised. That is a net benefit, even if crashes are
still bad.

The point is to make a type that still works with C and all the associated
APIs (e.g. format strings, native arithmetic, etc) without creating the
mess that Jakub, Peter, and others (correctly) balked at around accessors
for doing function based math.

> So I think wrapping and trapping are fundamentally very different. The
> words may look the same. The semantics may often be discussed
> together. But one is explicitly marking something as "overflow is safe
> and expected", and that's the actual real SAFE case.

Right. Mixing the term "safe" between these is certainly a mistake in
the documentation. We can fix all of that.

> The other is saying "overflow needs special handling". And the key
> here is that we need to have some way to *state* what said special
> handling is, and we need to do it at the point where that special
> handling is needed. Not some generic exception handler that has to
> figure things out from some unknown context.

The generic exception handler, right now, is the distant back-stop to
catch exceptional cases that nothing else was written to catch. Like
uncorrectable RAM errors. Using a trapping type isn't there for people
to _intend_ to crash the system. :)

But, yes, I agree that having a way to require in-place overflow
management would be the perfect solution, but no one seems to be able to
agree on it. The trouble with C arithmetic is that the overflow state is
"hidden". It's like the remainder from division: math statements need an
overflow case built in, almost like a ?:, but from a syntax perspective,
there's not been anything that stuck. The state of the art in C is
"make sure you test for overflow manually first", and these types allow
for that.

-Kees

-- 
Kees Cook