GrapheneOS/linux-hardened

scope out targeted usage of non-heuristic-based integer overflow checking

Opened this issue · 0 comments

Similar to #34 (see explanation there) but for -fsanitize=integer and subsets of it. Unsigned integer overflow is well-defined but still quite suspicious and intended overflows would ideally be marked. Some subsystems might buy into doing this and using it for debugging and fuzzing. Signed integer overflow is usually undefined, but the kernel makes it well-defined via -fno-strict-overflow so it's almost just as hard to push for that. Marking the intended overflows is not that much to ask for though and it can be done in a way that's pretty. The no_sanitize attribute exists for doing it at the function level but ideally they'd be marked on a case-by-case basis with the _builtin*_overflow intrinsics via wrappers making them sane to use for this.

This will provide a lot more coverage than SIZE_OVERFLOW and uncover a lot more issues, so it's a lot more work and should be targeted in scope.