linux-kernel - Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

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]

Message-ID: <1516700241.9521.129.camel@infradead.org>
Date:   Tue, 23 Jan 2018 09:37:21 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        KarimAllah Ahmed <karahmed@...zon.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Borislav Petkov <bp@...e.de>,
        Dan Williams <dan.j.williams@...el.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "H . Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Janakarajan Natarajan <Janakarajan.Natarajan@....com>,
        Joerg Roedel <joro@...tes.org>,
        Jun Nakajima <jun.nakajima@...el.com>,
        Laura Abbott <labbott@...hat.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        KVM list <kvm@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>
Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict
 Indirect Branch Speculation

On Tue, 2018-01-23 at 10:27 +0100, Ingo Molnar wrote:
> * Ingo Molnar <mingo@...nel.org> wrote:
> 
> > 
> > Is there a testcase for the SkyLake 16-deep-call-stack problem that I could run? 
> > Is there a description of the exact speculative execution vulnerability that has 
> > to be addressed to begin with?
>
> Ok, so for now I'm assuming that this is the 16 entries return-stack-buffer 
> underflow condition where SkyLake falls back to the branch predictor (while other 
> CPUs wrap the buffer).

Yep.

> > 
> > If this approach is workable I'd much prefer it to any MSR writes in the syscall 
> > entry path not just because it's fast enough in practice to not be turned off by 
> > everyone, but also because everyone would agree that per function call overhead 
> > needs to go away on new CPUs. Both deployment and backporting is also _much_ more 
> > flexible, simpler, faster and more complete than microcode/firmware or compiler 
> > based solutions.
> > 
> > Assuming the vulnerability can be addressed via this route that is, which is a big 
> > assumption!
>
> So I talked this over with PeterZ, and I think it's all doable:
> 
>  - the CALL __fentry__ callbacks maintain the depth tracking (on the kernel 
>    stack, fast to access), and issue an "RSB-stuffing sequence" when depth reaches
>    16 entries.
> 
>  - "the RSB-stuffing sequence" is a return trampoline that pushes a CALL on the 
>    stack which is executed on the RET.

That's neat. We'll want to make sure the unwinder can cope but hey,
Peter *loves* hacking objtool, right? :)

>  - All asynchronous contexts (IRQs, NMIs, etc.) stuff the RSB before IRET. (The 
>    tracking could probably made IRQ and maybe even NMI safe, but the worst-case 
>    nesting scenarios make my head ache.)
> 
> I.e. IBRS can be mostly replaced with a kernel based solution that is better than 
> IBRS and which does not negatively impact any other non-SkyLake CPUs or general 
> code quality.
> 
> I.e. a full upstream Spectre solution.

Sounds good. I look forward to seeing it.

In the meantime I'll resend the basic bits of the feature detection and
especially turning off KPTI when RDCL_NO is set.

We do also want to do IBPB even with retpoline, so I'll send those
patches for KVM and context switch. There is some bikeshedding to be
done there about the precise conditions under which we do it.

Finally, KVM should be *exposing* IBRS to guests even if we don't use
it ourselves. We'll do that too.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)