linux-kernel - Re: [PATCH RFC v9 2/7] x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls

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] [day] [month] [year] [list]

Date:   Thu, 22 Mar 2018 23:56:53 +0300
From:   Alexander Popov <alex.popov@...ux.com>
To:     Dave Hansen <dave.hansen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Laura Abbott <labbott@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Andy Lutomirski <luto@...nel.org>
Cc:     PaX Team <pageexec@...email.hu>,
        Brad Spengler <spender@...ecurity.net>,
        Ingo Molnar <mingo@...nel.org>,
        Tycho Andersen <tycho@...ho.ws>,
        Mark Rutland <mark.rutland@....com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Borislav Petkov <bp@...en8.de>,
        Richard Sandiford <richard.sandiford@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        "Dmitry V . Levin" <ldv@...linux.org>,
        Emese Revfy <re.emese@...il.com>,
        Jonathan Corbet <corbet@....net>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Thomas Garnier <thgarnie@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Josef Bacik <jbacik@...com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Nicholas Piggin <npiggin@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        "David S . Miller" <davem@...emloft.net>,
        Ding Tianhong <dingtianhong@...wei.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Juergen Gross <jgross@...e.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Mathias Krause <minipli@...glemail.com>,
        Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
        Kyle Huey <me@...ehuey.com>,
        Dmitry Safonov <dsafonov@...tuozzo.com>,
        Will Deacon <will.deacon@....com>,
        Arnd Bergmann <arnd@...db.de>, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH RFC v9 2/7] x86/entry: Add STACKLEAK erasing the kernel
 stack at the end of syscalls

On 21.03.2018 18:33, Dave Hansen wrote:
> On 03/21/2018 04:04 AM, Alexander Popov wrote:
>> The main obstacle:
>> erase_kstack() must save and restore any modified registers, because it is
>> called from the trampoline stack (introduced by Andy Lutomirski), when all
>> registers except RDI are live.
> 
> Wow, cool, thanks for doing this!
> 
> PTI might also cause you some problems here because it probably won't
> map your function.  Did you have to put it in one of the sections that
> gets mapped by the user page tables?

No, I didn't have to do that: erase_kstack() works fine, it is called just
before SWITCH_TO_USER_CR3_STACK.

There is also a way not to offend KASAN. erase_kstack() C code can be put in a
separate source file and compiled with "KASAN_SANITIZE_erase.o := n".

So, as I wrote, the only critical drawback of the C implementation is that it
needs no_caller_saved_registers attribute, which is provided by gcc since version 7.

Can you recommend any solution?


By the way, during my work on STACKLEAK, I've found one case when we get to the
userspace directly from the thread stack. Please see sysret32_from_system_call
in entry_64_compat.S. I checked that.

IMO it seems odd, can the adversary use that to bypass PTI?

Best regards,
Alexander