Date: Wed, 20 Feb 2019 14:03:13 -0800 From: Kees Cook <keescook@...omium.org> To: Andy Lutomirski <luto@...capital.net> Cc: Elena Reshetova <elena.reshetova@...el.com>, Josh Poimboeuf <jpoimboe@...hat.com>, Kernel Hardening <kernel-hardening@...ts.openwall.com>, Andy Lutomirski <luto@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Peter Zijlstra <peterz@...radead.org> Subject: Re: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon system call On Fri, Feb 8, 2019 at 8:34 AM Andy Lutomirski <luto@...capital.net> wrote: > > On Feb 8, 2019, at 4:15 AM, Elena Reshetova <elena.reshetova@...el.com> wrote: > > This feature should make considerably harder various > > stack-based attacks that are based upon overflowing > > a kernel stack into adjusted kernel stack with a > > possibility to jump over a guard page. > > Since the stack offset is randomized upon each > > system call, it is very hard for attacker to reliably > > land in any particular place on the adjusted stack. > > > > I think we need a better justification. With VLAs gone, it should be statically impossible to overflow past a guard page. I do agree, that the stack is a much more well-defended area right now, and that the urgency for this feature is lower, but if it's easy to implement, I think we should do it. With VLAs universally gone, we can't get unbounded allocations that lead to both linear overflows and indexed overflows. But this doesn't mean a counter or index can't still go crazy -- it just means the expected stack layout will no longer be attached to it. With VMAP_STACK we stop linear overflows of the stack since we'll hit a guard page. However, this does not stop indexed overflows where we can jump the guard page. It is harder to control an indexed overflow vs a linear overflow, but it's still possible. Adding more variability to this, I think, has value in making attacks less reliable. Also, I'd note that while this is currently an x86-only implementation, it's not hard to extend to other architectures that don't already have VMAP_STACK. (And while it is the default, not all x86 builds have CONFIG_VMAP_STACK=y, though why you'd turn that off and turn this on, I'm not sure.) -- Kees Cook
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.