On February 2, 2026 12:29:39 AM PST, Peter Zijlstra <[email protected]>
wrote:
>On Sun, Feb 01, 2026 at 07:39:46PM -0800, Kees Cook wrote:
>> On Sun, Feb 01, 2026 at 12:47:41PM +0100, Peter Zijlstra wrote:
>> > On Sat, Jan 31, 2026 at 10:42:35AM -0800, Kees Cook wrote:
>> > > On Sat, Jan 31, 2026 at 10:39:42AM +0100, Salvatore Bonaccorso wrote:
>> > > > Kees, Peter approached the Debian kernel list above to drop
>> > > > CONFIG_UBSAN again, which, so I think we need to revert your
>> > > > 6cfadabfe015 ("Enable UBSAN_BOUNDS and UBSAN_SHIFT"):
>> > > > https://salsa.debian.org/kernel-team/linux/-/commit/6cfadabfe015fa0d659fc8e3efd495cbcae3e44e
>> > > >
>> > > > I have make a MR for our packaging for the change in
>> > > > https://salsa.debian.org/kernel-team/linux/-/merge_requests/1804
>> > >
>> > > I am strongly opposed -- this undoes years of security flaw mitigation
>> > > work and leaves Debian (and only Debian!) exposed to trivial array index
>> > > overflows. The bounds sanitizer is the corner stone of memory safety
>> > > for C, and is not some "experimental" feature. GCC has a long history
>> > > of trouble with inlining, so this is not something unique to enabling
>> > > this feature.
>> > >
>> > > I replied similarly to the PR. This would be a major mistake to disable.
>> >
>> > Why the heck is bounds checking part of UBSAN? The simple fix here is to
>> > get it out from CONFIG_UBSAN, so that CONFIG_UBSAN is debug only crap.
>>
>> Out of bounds accesses are considered "undefined". *sigh*
>
>*sigh* indeed.
>
>> But yes, now that we have the "transitional" kconfig symbols I can
>> trivially rename CONFIG_UBSAN_BOUNDS and remove its CONFIG_UBSAN
>> dependency.
>
>That would be great; I can sit on this patch a while, its mostly build
>robots and the like occasionally tripping this.
>
>It would be good to have the compiler folks agree that bounds checking
>is production code though :-)
>
>> > Notably, none of the UBSAN configs that tripped the optimization fail
>> > even had bounds checking enabled.
>>
>> Which ones tripped it? KASAN (in software tagging mode) is usually the
>> heavy-weight one that considerably bloats code generation. I haven't
>> seen systemic problems with -fsanitize=bounds, and I thought the weird
>> cases (which confused the value range tracking) with -fsanitize=shift
>> got fixed back in GCC 12 (or maybe 13).
>
>I'm not sure which one (I didn't care to find out, its debug nonsense
>and nobody cares etc.. :-).
>
>One has:
>
>CONFIG_ARCH_HAS_UBSAN=y
>CONFIG_UBSAN=y
>CONFIG_UBSAN_TRAP=y
>CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y
># CONFIG_UBSAN_BOUNDS is not set
># CONFIG_UBSAN_SHIFT is not set
>CONFIG_UBSAN_DIV_ZERO=y
>CONFIG_UBSAN_BOOL=y
>CONFIG_UBSAN_ENUM=y
>
>The other has:
>
>CONFIG_ARCH_HAS_UBSAN=y
>CONFIG_UBSAN=y
># CONFIG_UBSAN_TRAP is not set
>CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y
># CONFIG_UBSAN_BOUNDS is not set
>CONFIG_UBSAN_SHIFT=y
>CONFIG_UBSAN_DIV_ZERO=y
># CONFIG_UBSAN_UNREACHABLE is not set
>CONFIG_UBSAN_BOOL=y
># CONFIG_UBSAN_ENUM is not set
>CONFIG_UBSAN_ALIGNMENT=y
>
>The common ones are DIV_ZERO and BOOL.
DIV_ZERO is a known trouble-maker in Clang (though for its pathological
behavior it needs CONFIG_UBSAN_TRAP). Perhaps we should drop it entirely?
-Kees
--
Kees Cook
