Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

[Jim Mattson]

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
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Jan 29, 2018 at 1:02 PM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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