Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: irc.freenode.net ##linux-hardened. Currently maintained at https://github.com/anthraxx/linux-hardened.
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.
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-overflowso 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. Theno_sanitizeattribute 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.