* Kees Cook [off-list ref] wrote:
quoted
There's the option of using GCC plugins now that the infrastructure was
upstreamed from grsecurity. It can be used as part of the regular build
process and as long as the analysis is pretty simple it shouldn't hurt compile
time much.
Well, and that the situation may arise due to memory corruption, not from
poorly-matched set_fs() calls, which static analysis won't help solve. We need
to catch this bad kernel state because it is a very bad state to run in.
If memory corruption corrupted the task state into having addr_limit set to
KERNEL_DS then there's already a fair chance that it's game over: it could also
have set *uid to 0, or changed a sensitive PF_ flag, or a number of other
things...
Furthermore, think about it: there's literally an infinite amount of corrupted
task states that could be a security problem and that could be checked after every
system call. Do we want to check every one of them?
Thanks,
Ingo