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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

How that? Do you perhaps mean there's nothing we can do? Yes,
and the same applies to the guest. Yet if you've got HT hardware
which supports IBRS but not STIBP, you still tell the guest that
STIBP is available. Hence the guest seeing (and using) both, it'll
assume it is safe (and perhaps report so to its users) when in
fact it's still vulnerable.

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

Yes.

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

Yes. But:

A guest is not safe if it believes it uses STIBP, but that's just fake.

Jan


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