* Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
