[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2236FBA76BA1254E88B949DDB74E612BA4C48943@IRSMSX102.ger.corp.intel.com>
Date: Wed, 10 Apr 2019 09:00:43 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Ingo Molnar <mingo@...nel.org>,
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
> * Josh Poimboeuf <jpoimboe@...hat.com> wrote:
>
> > 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)?
>
> Could someone please include the full patch, with justification and
> performance impact analysis etc.? Can only find the code part of the
> thread on lkml, which leaves out this context.
>
Sorry, this is very weird, I cannot find it either from lkml, but it was sent there
to begin with (and as visible from reply-to headers).
Do you want me to resent original version or with "do_fast_syscall_32,
do_int80_syscall_32" additions (I am finishing testing them now).
Best Regards,
Elena.
Powered by blists - more mailing lists