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 14:06, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 19/01/18 12:52, Jan Beulich wrote:
>>>>> 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
> 
> If Intel's microcode fails to advertise STIBP on HT-hardware where it is
> required for safety, then its broken microcode.
> 
>> 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.
> 
> Ok - I see your point now, but there is nothing we can do about that.

There are options:

1) Disable HT (read: use only on thread on each core)
2) Don't advertise STIBP if we find ourselves on HT with IBRS but
   no STIBP.
3) Issue a bright warning (in the hope that it is noticed).

Jan


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