RE: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall

[Reshetova, Elena]

>> On Fri, May 3, 2019 at 9:40 AM David Laight <David.Laight@xxxxxxxxxx> wrote:
> >
> > That gives you 10 system calls per rdrand instruction
> > and mostly takes the latency out of line.
> 
> Do we really want to do this? What is the attack scenario?
> 
> With no VLA's, and the stackleak plugin, what's the upside? Are we
> adding random code (literally) "just because"?
> 
>                    Linus

Hi Linus, 

So, if your question is "do we know a thread stack-based
attack that would succeed given that all countermeasures are active
(stackleak, CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y,
assume no VLAs left, etc.) ?" Then the answer is "no", I don't know
and people I have asked also (this of course by itself does not provide any 
guarantees of any kind in security world).

However, the whole nature of the thread stack is its predictable and deterministic
structure that attracted attackers over decades to mount various attacks
(ab)using it. So, while stackleak and others address concrete attack paths,
such as uninitialized variables on the stack, arbitrary stack jump primitives (VLAs),
etc. We don't really have anything in place that addresses the core feature:
"simple and deterministic structure that is persistent across syscalls". 

So, this feature is an attempt to be more proactive (vs. reacting to already published
attack) and add randomization in a place where it would likely make most of thread-based
attacks harder for attackers. If we can make the measure cheap enough not to affect
performance considerably and get a security benefit, why not? 

Best Regards,
Elena.