[lkml]   [2017]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

* Kees Cook <> 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

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?



 \ /
  Last update: 2017-05-10 21:17    [W:0.110 / U:4.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site