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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 6 May 2019 06:47:54 +0000
From:   "Reshetova, Elena" <elena.reshetova@...el.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        David Laight <David.Laight@...lab.com>
CC:     Ingo Molnar <mingo@...nel.org>, Andy Lutomirski <luto@...nel.org>,
        Theodore Ts'o <tytso@....edu>,
        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>,
        "keescook@...omium.org" <keescook@...omium.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>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: RE: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall

>> On Fri, May 3, 2019 at 9:40 AM David Laight <David.Laight@...lab.com> 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.