lkml.org 
[lkml]   [2024]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC] Mitigating unexpected arithmetic overflow
From


Am 5/8/2024 um 10:07 PM schrieb Linus Torvalds:
> And no, the answer is ABSOLUTELY NOT to add cognitive load on kernel
> developers by adding yet more random helper types and/or functions.


Just to show an option without "more types and helper functions", one
could also instead add a coverage requirement:

Every arithmetic operation should either:
- have a test case where the wrap around happens, or
- have a static analyser say that overflow can not happen, or
- have a static analyser say that overflow is fine (e.g., your a+b < a case)

Then the answer to safe wrap situations isn't to make the kernel code
less readable, but to have a component-level test that shows that the
behavior on overflow (in at least one case :)) ) is what the developer
expected.

For static analysis to prove that overflow can not happen, one sometimes
would need to add BUG_ON() assertions to let the analyser know the
assumptions on surrounding code, which has its own benefits.


static inline u32 __item_offset(u32 val)
{
BUG_ON(val > INT_MAX / ITEM_SIZE_PER_UNIT);
return val * ITEM_SIZE_PER_UNIT;
}


Obviously, the effort involved is still high. Maybe if someone as a pet
project proves first that something in this direction is actually worth
the effort (by uncovering a heap of bugs), one could offer this kind of
check as an opt-in.


Best wishes,

jonas


\
 
 \ /
  Last update: 2024-05-27 18:30    [W:2.845 / U:0.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site