[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1517312151.18619.109.camel@infradead.org>
Date: Tue, 30 Jan 2018 11:35:51 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Arjan van de Ven <arjan@...ux.intel.com>,
Eduardo Habkost <ehabkost@...hat.com>,
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>,
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>,
"Dr. David Alan Gilbert" <dgilbert@...hat.com>
Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support
infrastructure
On Mon, 2018-01-29 at 16:23 -0800, Linus Torvalds wrote:
>
> Note on the unhappiness with some of the patches involved: what I do
> *not* want to see is the "on every kernel entry" kind of garbage.
>
> So my unhappiness with the intel microcode patches is two-fold:
>
> (a) the interface is nasty and wrong, and I absolutely detest how Intel did it.
>
> (b) the write to random MSR's on every kernel entry/exit is wrong
>
> but that doesn't mean that I will necessarily end up NAK'ing every
> single IBRS/IBPB patch.
>
> My concern with (a) is that unlike meltdown, the intel work-around
> isn't forward-looking, and doesn't have a "we fixed it" bit. Instead,
> it has a "we have a nasty workaround that may or may not be horribly
> expensive" bit, and isn't all that well-defined.
The lack of a "we fixed it" bit is certainly problematic.
But as an interim hack for the upcoming hardware, IBRS_ALL isn't so
badly defined. Sure, the reassurances about performance all got ripped
out before the document saw the light of day — quelle surprise? — but
my understanding is that it *will* be fast. It is expected to be fast
enough that we can ALTERNATIVE away the retpolines, set it once and
leave it set.
The reason it isn't just a "we fixed it" bit is because we'll still
need the IBPB on context/vCPU switches.
I suspect they managed to tag BTB entries with VMX mode and ring, but
*not* the full VMID/PCID tagging (and associated automatic flushing)
that they'd need to truly say "we fixed it".
I seriously hope they're working on a complete fix for the subsequent
generation, and just neglected to mention it in their public
documentation that far in advance.
> My dislike of (b) comes from "we have retpoline and various wondrous
> RSB filling crud already, we're smarter than that". So it's not that I
> refuse any IBRS/IBPB use, I refuse the stupid and _mindless_ kind of
> use.
Well... for Skylake we probably need something like Ingo's cunning plan
to abuse function tracing to count call depth. I won't be utterly
shocked if, by the time we have all that pulled together, it ends up
being fairly much as fugly as the IBRS version — for less complete
protection. But we'll see. :)
It may also be that some of the last remaining holes can be declared
just too unlikely for us to jump through fugly hoops for. In fact that
*has* to be our answer for the SMI issue if we're not using IBRS on
Skylake, so now it's just a question of degree — how many of the
*other* theoretical holes are we happy to do the same thing for?
That's a genuine question, not a rhetorical device arguing for IBRS. I
just haven't seen a clear analysis, other than some hand-waving, of how
feasible some of those attack vectors really are. I'd like to.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)
Powered by blists - more mailing lists