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 12:11, Jan Beulich wrote:
>>>> 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_?

I'm completely lost now.  On hardware which doesn't support STIBP, there
is no action required required.

> 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.

It is safe for a guest to use STIBP in on harwdare where STIBP it isn't
actually required for safety.

A guest is not safe if it believes it doesn't need to use STIBP, and
migrates to a host which does require STIBP for safety.

I'm not sure how else to try and explain this.

~Andrew

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