The guest OS is responsible for protecting itself from intra-guest attacks. The hypervisor can't do that. We want to give the guest OS the tools it needs to make reasonable decisions about the intra-guest protections it wants to enable, in an environment where the virtual processor and the physical processor may not actually have the same F/M/S (and in fact, where the physical processor may change at any time).
Right now, we are dealing with one workaround, which is tied to Skylake-era model numbers. Yes, we could report a Skylake model number, and Linux guests would use IBRS instead of retpoline. But this approach doesn't scale. What happens when someone introduces a workaround tied to some other model numbers? On Mon, Jan 29, 2018 at 4:23 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Mon, Jan 29, 2018 at 1:02 PM, David Woodhouse <dw...@infradead.org> wrote: >> >> On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote: >>> >>> the objective is to have retpoline be safe everywhere and never use IBRS >>> (Linus was also pretty clear about that) so I'm confused by your question > > 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. > > 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. > >> The question is about all the additional RSB-frobbing and call depth >> counting and other bits that don't really even exist for Skylake yet in >> a coherent form. >> >> If a guest doesn't have those, because it's running some future kernel >> where they *are* implemented but not enabled because at *boot* time it >> discovered it wasn't on Skylake, the question is what happens if that >> guest is subsequently migrated to a Skylake-class machine. > > So I actually have a _different_ question to the virtualization > people. This includes the vmware people, but it also obviously > incldues the Amazon AWS kind of usage. > > When you're a hypervisor (whether vmware or Amazon), why do you even > end up caring about these things so much? You're protected from > meltdown thanks to the virtual environment already having separate > page tables. And the "big hammer" approach to spectre would seem to > be to just make sure the BTB and RSB are flushed at vmexit time - and > even then you might decide that you really want to just move it to > vmenter time, and only do it if the VM has changed since last time > (per CPU). > > Why do you even _care_ about the guest, and how it acts wrt Skylake? > What you should care about is not so much the guests (which do their > own thing) but protect guests from each other, no? > > So I'm a bit mystified by some of this discussion within the context > of virtual machines. I think that is separate from any measures that > the guest machine may then decide to partake in. > > If you are ever going to migrate to Skylake, I think you should just > always tell the guests that you're running on Skylake. That way the > guests will always assume the worst case situation wrt Specte. > > Maybe that mystification comes from me missing something. > > Linus
