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 10:10:52AM -0700, Linus Torvalds wrote:
> On Tue, 31 Mar 2026 at 09:37, Kees Cook <kees@kernel.org> wrote:
> >
> > 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". :)
> [...]
> If somebody starts using explicitly trapping types, they need to say
> so. Not just *say* so, but scream it at the top of their lungs. No
> hidden subtle behavior changes. This needs to look _very_different_.
> 
> No stupid one-character things. If we go down this path it would need
> to be "wrapping_u32" or whatever.

Yeah, that's fine. I'm fine calling these types whatever we want
(regardless of how we ultimately bolt exception handling to them).

The only reason I had this proposal using a short forms was to make
it "easy" to get counters/indexes/iterators with as few characters as
possible. It all comes back to my "favorite" security flaw where a u8
counter wrapped during post-increment in a while loop. Why was it "u8"?
No good reason besides "it was even less to type than 'int'" AFAICT. :P

> I don't actually see any sane interface. The "unsafe_get_user()" thing
> with actual labels and exception tables works very well, but it would
> require wrapping all trapping operations in a macro.

Mark Rutland had strong reservations about function-level annotations,
but I wonder if the combination of new type _and_ function-level
annotation could get us something near what would be palatable:


int __overflow_label(boom)
something(...)
{
	u8 __ob_trap count;
	...
	take_locks();
	...
	while (thing())
		count++;
	destroy_the_world_if_count_wraps(count);
	...
	return 0;

boom:
	unlock_and_clean_up(...);
	return -EINVAL;
}


This way not _all_ math is covered by the label, only the trapping math.

Or we could make the label a global part of the language itself so it
wouldn't need to be a function annotation, but rather a _required_
element of any function that uses a trapping type?

-Kees

-- 
Kees Cook