From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0570F37BE6F for ; Mon, 2 Feb 2026 16:01:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770048076; cv=none; b=cWe6GsEM/+qjuHXZyLtMJAXdseAKAYA9XargVDGGdJ6K7iGZoNcffF0rniDpeX9mCsoeHqsfAo4sRkHN2RTXLLPA1EzkPz1urFrHRMeKy2sg6IfNuR3Hsy+XmcZtgJfPcPFEH3Fw5dp4TrP9vFGz8jWrRiSi/qPJbw3pRuMOUCw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770048076; c=relaxed/simple; bh=vTF4ao1zNmp0tY8rMJiAfuQg3tdIxEGeD0M5zWHkoTM=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=mJlIkN3wOG7pU0n57MOHG7RoVd9wvv7iUD3npmu/xYFw62X85qx+ph8EjFfusXQgsn2eKjUxAXm3yUzjQvJRP3hvjsbxPpzsP3pt22PUnk89tH82/SPtD4JA7y9yp9ekz3tgtoQfxU1pzDeEZYog/0sYXsWJkwH4VdxdeCEA2Qw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cEIIpB/r; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cEIIpB/r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2F45C19422; Mon, 2 Feb 2026 16:01:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770048075; bh=vTF4ao1zNmp0tY8rMJiAfuQg3tdIxEGeD0M5zWHkoTM=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=cEIIpB/r74mRODpyj1ICeKntnaVV5eXJXvVdLz6NdBM/NOIHlRZ7VqcfS6zp8YcwD X8wN11XPD2CbqLdDY0if8cSkB3OvIQ/DxPzqlUYlEOjlBtbj/hAw8Io+fvLMeBGLSS xZRSQrg4Xys/U9WIIlb7TlitoJQqNpamXa+PVHiEpYpXQcmSwR9gv3b3gm41WbqSRG 8fU8olGJsIZRsr6zn5i30k4BibsUqoKCt5WUTE0A+VH0OI7CZvlf30jCD5aDWsam5J UyIg6aJR5RIro5g43t+GG9jaKMwvDZEKfKzcePAAPMde2/77NjQURobPWVPezSqNcE XaePXE1Kh7U9w== Date: Mon, 02 Feb 2026 08:01:14 -0800 From: Kees Cook To: Peter Zijlstra CC: Kees Cook , mingo@kernel.org, oleg@redhat.com, linux-kernel@vger.kernel.org, debian-kernel@lists.debian.org Subject: Re: [PATCH] seqlock: Allow UBSAN to fail optimizing User-Agent: K-9 Mail for Android In-Reply-To: <20260202082939.GB1282955@noisy.programming.kicks-ass.net> References: <20260129110733.GA166857@noisy.programming.kicks-ass.net> <20260201114741.GA3016024@noisy.programming.kicks-ass.net> <202602011935.9E968135@keescook> <20260202082939.GB1282955@noisy.programming.kicks-ass.net> Message-ID: <30284EE3-5F5B-4D68-BD40-0F91A482BFAE@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On February 2, 2026 12:29:39 AM PST, Peter Zijlstra 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 wrot= e: >> > > > 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=2Edebian=2Eorg/kernel-team/linux/-/commit/6cfadabfe= 015fa0d659fc8e3efd495cbcae3e44e >> > > >=20 >> > > > I have make a MR for our packaging for the change in >> > > > https://salsa=2Edebian=2Eorg/kernel-team/linux/-/merge_requests/1= 804 >> > >=20 >> > > I am strongly opposed -- this undoes years of security flaw mitigat= ion >> > > work and leaves Debian (and only Debian!) exposed to trivial array = index >> > > overflows=2E The bounds sanitizer is the corner stone of memory saf= ety >> > > for C, and is not some "experimental" feature=2E GCC has a long his= tory >> > > of trouble with inlining, so this is not something unique to enabli= ng >> > > this feature=2E >> > >=20 >> > > I replied similarly to the PR=2E This would be a major mistake to d= isable=2E >> >=20 >> > 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= =2E >>=20 >> Out of bounds accesses are considered "undefined"=2E *sigh* > >*sigh* indeed=2E > >> But yes, now that we have the "transitional" kconfig symbols I can >> trivially rename CONFIG_UBSAN_BOUNDS and remove its CONFIG_UBSAN >> dependency=2E > >That would be great; I can sit on this patch a while, its mostly build >robots and the like occasionally tripping this=2E > >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=2E >>=20 >> Which ones tripped it? KASAN (in software tagging mode) is usually the >> heavy-weight one that considerably bloats code generation=2E I haven't >> seen systemic problems with -fsanitize=3Dbounds, and I thought the weir= d >> cases (which confused the value range tracking) with -fsanitize=3Dshift >> got fixed back in GCC 12 (or maybe 13)=2E > >I'm not sure which one (I didn't care to find out, its debug nonsense >and nobody cares etc=2E=2E :-)=2E > >One has: > >CONFIG_ARCH_HAS_UBSAN=3Dy >CONFIG_UBSAN=3Dy >CONFIG_UBSAN_TRAP=3Dy >CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=3Dy ># CONFIG_UBSAN_BOUNDS is not set ># CONFIG_UBSAN_SHIFT is not set >CONFIG_UBSAN_DIV_ZERO=3Dy >CONFIG_UBSAN_BOOL=3Dy >CONFIG_UBSAN_ENUM=3Dy > >The other has: > >CONFIG_ARCH_HAS_UBSAN=3Dy >CONFIG_UBSAN=3Dy ># CONFIG_UBSAN_TRAP is not set >CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=3Dy ># CONFIG_UBSAN_BOUNDS is not set >CONFIG_UBSAN_SHIFT=3Dy >CONFIG_UBSAN_DIV_ZERO=3Dy ># CONFIG_UBSAN_UNREACHABLE is not set >CONFIG_UBSAN_BOOL=3Dy ># CONFIG_UBSAN_ENUM is not set >CONFIG_UBSAN_ALIGNMENT=3Dy > >The common ones are DIV_ZERO and BOOL=2E DIV_ZERO is a known trouble-maker in Clang (though for its pathological be= havior it needs CONFIG_UBSAN_TRAP)=2E Perhaps we should drop it entirely? -Kees --=20 Kees Cook