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

Kees Cook
2026-03-31T23:49:13Z

On Tue, Mar 31, 2026 at 02:50:39PM -0700, Justin Stitt wrote:
> On Tue, Mar 31, 2026 at 2:05 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Tue, 31 Mar 2026 at 13:31, Kees Cook <kees@kernel.org> wrote:
> > >
> > > (Isn't this just an implicit "try"?)
> >
> > Yes. And I think that's ok.
> >
> > I think try/catch is broken for a few reasons, but the fact that catch
> > and try are tied together so closely is the main one. You can't "try"
> > inside a scope without having the "catch" inside the same scope.
> >
> > So then the solution is to just move the try to the outermost layer,
> > and I think that's pretty much what everybody does.
> >
> > But at that point, why not just move it *all* the way out, and make it
> > implicit and invisible?
>
> How do we feel about type-defined labels? We can specify sane default
> handlers where we define the types:
>
> typedef int __attribute__((overflow_behavior(trap, __handle_me))) trapping_int;
>
> ... and define specialized handlers later on
>
> int func()
> {
> ...
> u8 __attribute__((overflow_behavior(trap, __BOOOOM))) product = 5;
> ...
> product = a * b; // if store is truncated, goto __overflow
> ...
> return product;
>
> __BOOOOM:
> pr_info("%u\n", product); // shows "5"
> return -1;
> }

Yeah, I think this could work. As long as there's nothing special about
the label mapping (i.e. many types can share the same label).

> We would then probably want a kernel shorthand to avoid long type definitions.
>
> #define __TRAP(handler) __attribute__((overflow_behavior(trap,
> handler)))
>
>
> At least this way the label is always defined somewhere in-source
> rather than by a magic -fhandle-my-overflow-at=__overflow

Yeah, this sticks to Peter's "define in source" mandate from Plumbers.

Linus, does that still sound reasonable?

Also, is the preference still for "loud" names ("trap_u32") for the
trapping scalar typedefs, or does the advent of the "required label on
usage" make it more reasonable to have shorter names ("u32t")? I'm fine
either way. I think there are pros and cons all over the place for the
naming.

-Kees

--
Kees Cook