Re: [Xen-devel] [PATCH v9 02/11] x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/01/18 11:46, Jan Beulich wrote:
>>>> On 19.01.18 at 11:53, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 19/01/18 10:40, Jan Beulich wrote:
>>>>>> On 18.01.18 at 16:46, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> For guest safety, we treat STIBP as special, always override the toolstack
>>>> choice, and always advertise STIBP if IBRS is available.  This removes the
>>>> corner case where STIBP is not advertised, but the guest is running on
>>>> HT-capable hardware where it does matter.
>>> I guess the answer to my question may live somewhere later in the
>>> series, but since I haven't got there yet: Is this based on the
>>> assumption that on HT-capable hardware they would always be
>>> available together? Otherwise, how do you emulate STIBP for the
>>> guest if all you've got is IBRS/IBPB?
>> The safety depends on the guest seeing STIBP and using it if it wants
>> to.  (Not that I've seen any sign of STIBP in the Linux code, or from
>> observing what Windows appears to do).
>>
>> For topology reasons (despite the other cans of worms in this area), we
>> unilaterally set HT, so all guests should find themselves on HT-capable
>> systems.
> But this doesn't answer my question: What do you do if the guest
> uses STIBP (because you've told it that it can), but the hardware
> doesn't support it? Aren't you producing a false sense of security
> to the guest this way?

The entire point of SPEC_CTRL_STIBP being ignored on some hardware is to
let this work.

By advertising STIBP, we are telling the guest "There might be (but not
definitely) interference from other threads in the BTB.  If you care
about this, you should set SPEC_CTRL.STIBP".

On hardware where there is definitely no interference, this is a nop.

In any situation where a guest might migrate to a host where there is
interference, it needs to know about STIBP so (if it cares) it can
choose to set SPEC_CTRL.STIBP.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel