[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 19.01.18 at 13:01, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

This is the part that is clear, but my question remains unanswered:
If HT hardware doesn't support STIBP, how can the guest guard
itself _successfully_? Afaict it will only think it is safe in such a case.
As said in my very first reply on this thread, the answer may well
be "We expect STIBP and IBRS to always come together on HT
hardware", but that's not written down anywhere afaics.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.