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 26AD133C507; Wed, 1 Apr 2026 21:41:01 +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=1775079662; cv=none; b=F0TkNseV/v8G6mmjFfbWkPxCkWBbMcQAII2dALYjuQXIv4x1Av9Jo0OTEqMscApYC/XuiHSUClltxsbcefMXYVYo5h8mqPxzaksQE/P1QAa8UVUnKn42EY2Mjx+2+5qV/yS6md2JJnJugv9/n1v7wzvBPpvN4WTuokKMfIltuwk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775079662; c=relaxed/simple; bh=pDwgJl6Fh9R0ESyyzZwZ3nyL/1KbhhNvMwGXe/yD3k8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kOoPOhbCBewe5mpVrDQi/YbJu8znlTnrq6G7uJzKaw1iCcZFnhxuNNNRZH8D5fSUBhAC+khSYqb3mdQWtvTjqL0ZIsEyj6Hnw6PSij66JjyfFGf9JA/704BYiil3Dc/5wCAHqTYoEGbizJlH7MRC+hRvZwU0aKchdi/nNMdEaKw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rjZ4krda; 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="rjZ4krda" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78247C4CEF7; Wed, 1 Apr 2026 21:41:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775079661; bh=pDwgJl6Fh9R0ESyyzZwZ3nyL/1KbhhNvMwGXe/yD3k8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rjZ4krdarwjCTk3lcfRgblqKEGSYvMlE4Ub7PB8ZhtVDNHJU53EvsLHOqIa783mjS uh1Ye5ifYSc+2lJDlHDbyCO1JC4udIlqGMyo95ZakDYbnYiWtqS5FyW0hIoidj/qen euu68aHI4r+tt1y/ZW63ZJiZ4im12Cq7kvxhAeaFT0Bk5vG9kUopONhOl2i1Kl7x1K SYxvvMSN1EGRjhFwvZ4L++cQMIxATWc83jCSm1elVC3UFuAoMNGQ+Sdm/JZuUkYqkC NLdK0LTq7V2d5cfKjTF3ejhgpUSuPge2iqLHnRnctbC7k57HMb0LIt8rHdrO17qxgq hi+/R+7AcOy4Q== Date: Wed, 1 Apr 2026 14:41:00 -0700 From: Kees Cook To: Peter Zijlstra Cc: Linus Torvalds , 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: <202604011438.E5D2335@keescook> References: <20260331163716.work.696-kees@kernel.org> <20260331163725.2765789-5-kees@kernel.org> <202603311253.95C54588E@keescook> <202603311321.4EE9FEA@keescook> <20260401093820.GX3738786@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-doc@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: <20260401093820.GX3738786@noisy.programming.kicks-ass.net> On Wed, Apr 01, 2026 at 11:38:20AM +0200, Peter Zijlstra wrote: > On Tue, Mar 31, 2026 at 01:31:16PM -0700, Kees Cook wrote: > > > int func() > > { > > ... > > u8 __ob_trap product = 5; > > ... > > product = a * b; // if store is truncated, goto __overflow > > ... > > return product; > > > > __overflow: > > pr_info("%u\n", product); // shows "5" > > return -1; > > } > > > > (Isn't this just an implicit "try"?) > > So I like this implicit try with a default label, and mostly I expect > this will be fine. > > But as Linus already mentioned, sometimes you might want more. Could we > perhaps also have an explicit version, something along the lines of: > > int func() > { > int __ob_trap size; > > size = try(count * flex_size, __mul_overflow); > size = try(size + base_size, __add_overflow); > > obj = kzalloc(size,...); > > } > > where we have something like: > > #define try(stmt, _label) ({ \ > __label __overflow; \ > if (0) { \ > __overflow: \ > goto _label; \ > } \ > stmt; }) > > That is, have the overflow trapped and confined in the > statement-expression by using the overflow label as a local label and > use this little trampoline to re-direct to a custom label. Yeah, that should work, and gives us a nice way to create handler overrides. We've have to make sure the "locally defined" labels (with __label__) and __ob_trap worked together sanely. -- Kees Cook