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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 19/01/18 12:52, Jan Beulich wrote:
>>>> On 19.01.18 at 13:36, <andrew.cooper3@citrix.com> wrote:
>> On 19/01/18 12:11, Jan Beulich wrote:
>>>>>> On 19.01.18 at 13:01, <andrew.cooper3@citrix.com> wrote:
>>>> On 19/01/18 11:46, Jan Beulich wrote:
>>>>>>>> On 19.01.18 at 11:53, <andrew.cooper3@citrix.com> wrote:
>>>>>> On 19/01/18 10:40, Jan Beulich wrote:
>>>>>>>>>> On 18.01.18 at 16:46, <andrew.cooper3@citrix.com> 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.

Even if Xen faithfully reported the (lack of) STIBP to the guest, and
fixed up behind the scenes just in case (as per v8 of my series), the
guest would still be vulnerable.

There are some thing we are simply going to have to trust the microcode
to do right.

~Andrew

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