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 13:33, Jan Beulich wrote:
>>>> 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)

The spec explicitly calls out the case of HT-hardware which doesn't
share BTBs across cores, which means there is at least one production or
planned system where this is true.

> 2) Don't advertise STIBP if we find ourselves on HT with IBRS but
>    no STIBP.

No.  The purpose of advertising STIBP even in cases where it isn't
strictly needed is to prevent us falling into the position of needing to
hide STIBP in heterogeneous cases, and increasing the likelyhood of the
guest being unsafe.

(For a guest which cares to use STIBP), unilaterally advertising it is
safe, while hiding the flag because of heterogeneous circumstances is not.

> 3) Issue a bright warning (in the hope that it is noticed).

And what would the conditions of this warning be?  The spec allows for
STIBP not to be advertised on hardware which doesn't actually need it,
which might include HT-capable hardware (but probably wont, for
microcode simplicity reasons).

I'm afraid that despite all of this, I don't see an valid argument
against the logic as implemented in the patch, and I don't see any
viable option to working around the edge case you are concerned about,
which is very definitely a microcode bug.

~Andrew

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