Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 8 May 2024 13:07:38 -0700 | Subject | Re: [RFC] Mitigating unexpected arithmetic overflow |
| |
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
| |