[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2236FBA76BA1254E88B949DDB74E612BA4C43BBA@IRSMSX102.ger.corp.intel.com>
Date: Mon, 8 Apr 2019 13:30:56 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Josh Poimboeuf <jpoimboe@...hat.com>
CC: "luto@...nel.org" <luto@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"luto@...capital.net" <luto@...capital.net>,
"keescook@...omium.org" <keescook@...omium.org>,
"jannh@...gle.com" <jannh@...gle.com>,
"Perla, Enrico" <enrico.perla@...el.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"bp@...en8.de" <bp@...en8.de>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"peterz@...radead.org" <peterz@...radead.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Subject: RE: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall
> On Mon, Apr 08, 2019 at 09:13:58AM +0300, Elena Reshetova wrote:
> > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > index 7bc105f47d21..38ddc213a5e9 100644
> > --- a/arch/x86/entry/common.c
> > +++ b/arch/x86/entry/common.c
> > @@ -35,6 +35,12 @@
> > #define CREATE_TRACE_POINTS
> > #include <trace/events/syscalls.h>
> >
> > +#ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
> > +#include <linux/random.h>
> > +
> > +void *alloca(size_t size);
> > +#endif
> > +
> > #ifdef CONFIG_CONTEXT_TRACKING
> > /* Called on entry from user mode with IRQs off. */
> > __visible inline void enter_from_user_mode(void)
> > @@ -273,6 +279,13 @@ __visible void do_syscall_64(unsigned long nr, struct
> pt_regs *regs)
> > {
> > struct thread_info *ti;
> >
> > +#ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
> > + size_t offset = ((size_t)prandom_u32()) % 256;
> > + char *ptr = alloca(offset);
> > +
> > + asm volatile("":"=m"(*ptr));
> > +#endif
> > +
> > enter_from_user_mode();
> > local_irq_enable();
> > ti = current_thread_info();
>
> Would it make sense to also do this for the compat syscalls
> (do_fast_syscall_32, do_int80_syscall_32)?
Good question.
Originally I was thinking that in-stack randomization makes sense
only for x86_64, since this is what VMAP stack on x86 depends on.
Without VMAP stack and guard pages, there are easier ways to attack,
so hardening there does not really makes that much sense IMO.
However the 32 emulation case is interesting, I didn't think of it before.
I guess if it uses VMAP-based stack, then we should support these calls also
with in-stack randomization.
Best Regards,
Elena.
Powered by blists - more mailing lists