Messages in this thread | | | Date | Fri, 17 May 2024 09:45:20 +0200 | Subject | Re: [RFC] Mitigating unexpected arithmetic overflow | From | Jonas Oberhauser <> |
| |
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
| |