Received-SPF: pass (google.com: domain of linux-kernel+bounces-173788-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <202404291502.612E0A10@keescook> <CAHk-=wi5YPwWA8f5RAf_Hi8iL0NhGJeL6MN6UFWwRMY8L6UDvQ@mail.gmail.com>
 <202405081144.D5FCC44A@keescook>
In-Reply-To: <202405081144.D5FCC44A@keescook>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 8 May 2024 13:07:38 -0700
Message-ID: <CAHk-=wjeiGb1UxCy6Q8aif50C=wWDX9Pgp+WbZYrO72+B1f_QA@mail.gmail.com>
Subject: Re: [RFC] Mitigating unexpected arithmetic overflow
To: Kees Cook <keescook@chromium.org>
Cc: 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
Content-Type: text/plain; charset="UTF-8"

On Wed, 8 May 2024 at 12:45, Kees Cook <keescook@chromium.org> wrote:
>
> On Wed, May 08, 2024 at 10:52:44AM -0700, Linus Torvalds wrote:
> > Example:
> >
> >    static inline u32 __hash_32_generic(u32 val)
> >    {
> >         return val * GOLDEN_RATIO_32;
> >    }
>
> But what about:
>
> static inline u32 __item_offset(u32 val)
> {
>         return val * ITEM_SIZE_PER_UNIT;
> }

What about it? I'm saying that your tool NEEDS TO BE SMART ENOUGH to
see the "what about".

> All I did was change the names of things and now we have to wonder if
> the result is going to be used for indexing or sizing

Exactly. Your tool needs to take that into account.

Any kind of mindless "this can wrap around" is inexcusable.

It needs to be smarter than that. And yes, that means exactly taking
into account how the result of the possible wrap-around is actually
used.

If it's used as a size or as an array index, it might be a problem.
But if it's used for masking and then a *masked* version is used for
an index, it clearly is NOT a problem.

IOW, exactly the same as "a+b < a". Yes, "a+b" might wrap around, but
if the use is to then compare it with one of the addends, then clearly
such a wrap-around is fine.

A tool that doesn't look at how the result is used, and just blindly
says "wrap-around error" is a tool that I think is actively
detrimental.

And no, the answer is ABSOLUTELY NOT to add cognitive load on kernel
developers by adding yet more random helper types and/or functions.

We already expect a lot of kernel developers. We should not add on to
that burden because of your pet project.

Put another way: I'm putting the onus on YOU to make sure your pet
project is the "Yogi Bear" of pet projects - smarter than the average
bear.

As long as you are approaching this from a "this puts the onus on
others", *YOU* are the problem.

Be the solution, not the problem.

              Linus