[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjHA8Di-cpT0pKcScwcWNVYRFvmhBwMrug=Mj5WUwa2rw@mail.gmail.com>
Date: Thu, 9 May 2024 12:15:40 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: "Theodore Ts'o" <tytso@....edu>, Kees Cook <keescook@...omium.org>,
Justin Stitt <justinstitt@...gle.com>, Peter Zijlstra <peterz@...radead.org>,
Mark Rutland <mark.rutland@....com>, linux-hardening@...r.kernel.org,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [RFC] Mitigating unexpected arithmetic overflow
On Thu, 9 May 2024 at 11:48, Al Viro <viro@...iv.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
Powered by blists - more mailing lists