[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <201905291134.3D40F13@keescook>
Date: Wed, 29 May 2019 11:35:45 -0700
From: Kees Cook <keescook@...omium.org>
To: "Reshetova, Elena" <elena.reshetova@...el.com>
Cc: Theodore Ts'o <tytso@....edu>, Ingo Molnar <mingo@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
David Laight <David.Laight@...lab.com>,
Eric Biggers <ebiggers3@...il.com>,
"ebiggers@...gle.com" <ebiggers@...gle.com>,
"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
Peter Zijlstra <peterz@...radead.org>,
Daniel Borkmann <daniel@...earbox.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"jpoimboe@...hat.com" <jpoimboe@...hat.com>,
"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>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall
On Wed, May 29, 2019 at 10:13:43AM +0000, Reshetova, Elena wrote:
> Not sure about ideal params for the whole combination here since security
> and performance are basically conflicting with each other (as usual).
> So, that's why I was trying to propose to have two version of this:
> - one with tilt towards performance (rdtsc based)
> - one with tilt towards security (CRNG-based)
> And then let users choose what matters more for their workload.
> For normal things like dektops, etc. CRNG based version won't provide
> any noticeable overhead. It might only matter for syscall sensitive workloads,
> which btw, most likely not enable quite a bunch of other security protections,
I think people that care about this would prefer the CRNG, and will be
much less interested in the performance issues. But giving people the
option to choose it at runtime seems sensible. Though really, for any
"real" workloads, it's totally lost in the noise, even with the CRNG.
> so I would say that for them to have even rdtsc() version is actually an
> improvement in their defenses for stack (and basically no impact on performance).
Yeah, I think a static-key based version of this would be very nice and
would stay out of anyone's way that didn't want it.
--
Kees Cook
Powered by blists - more mailing lists