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 459003803FC; Tue, 31 Mar 2026 18:32:00 +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=1774981921; cv=none; b=A/AwNi9naoAKO1h0ZN2x45la5ddZ42cmKPPrAaQFlX/uSlaX7q6gy6bo90CAsb5KxSykJElu5Qb7DM/8uUjfhA9ItBRvYcftKAEF+X+JDhlTlo8g+niBO0my+vy5vvaAkrD0J1VXHIFHIHX22ZP/sGoadFCd+qaEN2rl3Af6pLA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774981921; c=relaxed/simple; bh=A2t9VhjuxMDE/XMt5PYCBejiat0YUkyfDYUPy8IkQRY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ds5dbn1p4rDS1vBFcq5MB+ich2/XbjauRy5zFgHSWTm8NOm4/6VVjLMBkyhKLOF9T0vx1uzo7cbd2v6u23C0DWIpH6F7ZCd7TssdRMMcHj4qWNtuwC+2Fqy+bPUAk48Hxalti5pINppH+eos+48gK3ya99rAIB+c5Qtf2O76pc0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bJLR11sI; 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="bJLR11sI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC90DC19423; Tue, 31 Mar 2026 18:32:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774981920; bh=A2t9VhjuxMDE/XMt5PYCBejiat0YUkyfDYUPy8IkQRY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bJLR11sIrG+3ZA6DcWQvu5/96VaRX7/phSI67+CYerRFyZa2SDEwcR3llwEvLjI+f wCBcvN0O13jOXpruGlDDUVl6AD1+56DzDiVt32rchEALYDE0mOWsfyNu70xlfEpcnB 3iPR5oX6YPHpKPlfkyR05pjVgxL32J/oW7l0hJsV3rvCMduoN4WIITGpmSZuY5QVAy KS0YzxfGnlpa97ewzMIP1s0aMjMCFGX4gyyjsfTCYmR7fXByYpveEkEzjRNv2Xh+/u RMUz3b0iHnRY4NPIuGFp0mF5qCTE6OiM7RSmezbtDi54n3qlnr4vD+PJ1CnNM/x+BT j1u23wH7OpbJw== Date: Tue, 31 Mar 2026 11:32:00 -0700 From: Kees Cook To: Linus Torvalds Cc: Miguel Ojeda , Peter Zijlstra , Justin Stitt , Miguel Ojeda , Nathan Chancellor , Andrew Morton , Andy Shevchenko , Arnd Bergmann , Mark Rutland , "Matthew Wilcox (Oracle)" , Suren Baghdasaryan , Thomas Gleixner , Finn Thain , Geert Uytterhoeven , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , llvm@lists.linux.dev, Marco Elver , Jonathan Corbet , Nicolas Schier , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org Subject: Re: [PATCH 5/5] types: Add standard __ob_trap and __ob_wrap scalar types Message-ID: <202603311117.454F578@keescook> References: <20260331163716.work.696-kees@kernel.org> <20260331163725.2765789-5-kees@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=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Mar 31, 2026 at 11:02:03AM -0700, Linus Torvalds wrote: > On Tue, 31 Mar 2026 at 10:48, Miguel Ojeda > wrote: > > > > In the Rust side, even if those "explicit" types like the > > `wrapping_u32` you suggest exist, we generally use the methods on the > > normal integers instead, e.g. > > In that case the types in question should always be very much opaque, > and not usable as-is by existing compilers that don't have attributes. > > My feeling is that that will discourage use enormously for when people > want to just say "yes, I know this wraps, and it's ok". > > That said, for the *trapping* types, I do think that we likely need an > opaque type, because I really feel like using > > trapping_u32 x; > ... > x++; > > is a complete and utter mis-design. It makes the "x++' have random behavior that > > (a) cannot be recovered from (maybe we're holding random locks) > > (b) is completely invisible in the context of the code, because the > type may be somewhere very different > > and I think both of those are fundamental design mistakes. This design is specifically what Peter was requesting, and what actually integrates with C. I agree with you that the core problem is "cannot be recovered from", but that misses the point of these types. The point is that all of their uses are _supposed_ to have been written in a way that no overflow is possible (just like all the other types). But this is the problem: bugs keep happening, no matter what people try to do. And in fact, to support these kinds of in-code overflow checking, there are even idiom exclusions for these types (based on what you pointed out in the original RFC) to allow for things like: if (var + offset < var) { ... } If the code was written perfectly, then there's no problem. If there was a bug that allows for overflow then you get a crash instead of totally insane behavior that is almost always exploitable in a way that the system gets compromised. That is a net benefit, even if crashes are still bad. The point is to make a type that still works with C and all the associated APIs (e.g. format strings, native arithmetic, etc) without creating the mess that Jakub, Peter, and others (correctly) balked at around accessors for doing function based math. > So I think wrapping and trapping are fundamentally very different. The > words may look the same. The semantics may often be discussed > together. But one is explicitly marking something as "overflow is safe > and expected", and that's the actual real SAFE case. Right. Mixing the term "safe" between these is certainly a mistake in the documentation. We can fix all of that. > The other is saying "overflow needs special handling". And the key > here is that we need to have some way to *state* what said special > handling is, and we need to do it at the point where that special > handling is needed. Not some generic exception handler that has to > figure things out from some unknown context. The generic exception handler, right now, is the distant back-stop to catch exceptional cases that nothing else was written to catch. Like uncorrectable RAM errors. Using a trapping type isn't there for people to _intend_ to crash the system. :) But, yes, I agree that having a way to require in-place overflow management would be the perfect solution, but no one seems to be able to agree on it. The trouble with C arithmetic is that the overflow state is "hidden". It's like the remainder from division: math statements need an overflow case built in, almost like a ?:, but from a syntax perspective, there's not been anything that stuck. The state of the art in C is "make sure you test for overflow manually first", and these types allow for that. -Kees -- Kees Cook