Re: [RFC] Mitigating unexpected arithmetic overflow

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
	Kees Cook <keescook@chromium.org>,
	 Justin Stitt <justinstitt@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	 Mark Rutland <mark.rutland@arm.com>,
	linux-hardening@vger.kernel.org,  linux-kernel@vger.kernel.org,
	llvm@lists.linux.dev
Subject: Re: [RFC] Mitigating unexpected arithmetic overflow
Date: Thu, 9 May 2024 12:15:40 -0700	[thread overview]
Message-ID: <CAHk-=wjHA8Di-cpT0pKcScwcWNVYRFvmhBwMrug=Mj5WUwa2rw@mail.gmail.com> (raw)
In-Reply-To: <20240509184806.GS2118490@ZenIV>

On Thu, 9 May 2024 at 11:48, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> FWIW, the thing that somewhat worries me about having a helper along
> the lines of combine_to_u64(low, high) is that
>         foo->splat = combine_to_u64(something, something_else);
> would be inviting hard-to-catch brainos -
>         foo->splat = combine_to_u64(something_else, something);

Yeah, we'd have to be very clear about naming and ordering. So it
would probably have to be something like

        result = combine_to_u64_hi_lo(high, low);

to be easy to use.

The good news is that if you *do* get it wrong despite clear naming,
the resulting value will be so obviously wrong that it's generally a
"Duh!" thing if you do any testing what-so-ever.

Of course, I say that as somebody who always points out that I haven't
tested my own patches at all, and they are "something like this,
perhaps?".

But having "hi_lo" kind of naming would hopefully make it really
obvious even when just looking at the source code.

              Linus