linux-hardening - Re: [RFC] Mitigating unexpected arithmetic overflow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 8 May 2024 13:07:38 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kees Cook <keescook@...omium.org>
Cc: 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 Wed, 8 May 2024 at 12:45, Kees Cook <keescook@...omium.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