[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <202505281040.C8E022E@keescook>
Date: Wed, 28 May 2025 10:41:32 -0700
From: Kees Cook <kees@...nel.org>
To: Jann Horn <jannh@...gle.com>
Cc: Eric Biggers <ebiggers@...nel.org>,
Justin Stitt <justinstitt@...gle.com>,
linux-hardening@...r.kernel.org, oe-lkp@...ts.linux.dev,
lkp@...el.com, linux-kernel@...r.kernel.org,
Herbert Xu <herbert@...dor.apana.org.au>,
linux-arm-kernel@...ts.infradead.org, loongarch@...ts.linux.dev,
linux-s390@...r.kernel.org, linux-crypto@...r.kernel.org,
kernel test robot <oliver.sang@...el.com>,
Arnd Bergmann <arnd@...db.de>, llvm@...ts.linux.dev,
Masahiro Yamada <masahiroy@...nel.org>,
Nathan Chancellor <nathan@...nel.org>,
Nicolas Schier <nicolas@...sle.eu>, linux-kbuild@...r.kernel.org
Subject: Re: [linus:master] [crypto] 40b9969796:
UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c
On Wed, May 28, 2025 at 07:15:18PM +0200, Jann Horn wrote:
> On Wed, May 28, 2025 at 6:46 PM Kees Cook <kees@...nel.org> wrote:
> > On Tue, May 27, 2025 at 11:14:27PM -0700, Eric Biggers wrote:
> > > If this new sanitizer is going to move forward, is there any sort of plan or
> > > guide for how to update code to be compatible with it? Specifically considering
> > > common situations where unsigned wraparound (which is defined behavior in C) can
> > > be intentionally relied on, like calculating the distance from the next N-byte
> > > boundary. What are the best practices now?
> >
> > Hi, yes, this is still under development. I tried to make it hard to
> > enable accidentally (not via COMPILE_TEST, not UBSAN-default, etc), but
> > we (still) don't have a way to disable configs for randconfigs. :(
> >
> > We're hoping to see Clang 21 with the more versatile Overflow Behavior Types:
> > https://discourse.llvm.org/t/rfc-v2-clang-introduce-overflowbehaviortypes-for-wrapping-and-non-wrapping-arithmetic/86507
> >
> > and our current testing is showing many fewer false positives. (Having
> > run syzkaller for weeks now.)
> >
> > > Documentation/dev-tools/ubsan.rst says nothing about this and only mentions
> > > "undefined behavior", which this is not.
> >
> > Right -- this will get extensive documentation before we move it out of
> > its development phase.
> >
> > I'm not sure how to enforce "don't enable this unless you're developing
> > the Overflow Behavior Types" with current Kconfig, given the randconfig
> > gap... I have some memory of Arnd doing something special with his
> > randconfigs to avoid these kinds of things, but I can't find it now.
>
> You could depend on CONFIG_BROKEN, the canonical "if you enable this
> and stuff breaks, it's your fault" flag?
Yeah. Talking with Justin out of band, he suggested the same. It's
easier to carry a 1 line patch downstream while we're testing to enable
this feature, so I'll send a patch to add CONFIG_BROKEN for now.
-Kees
--
Kees Cook
Powered by blists - more mailing lists