* 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