Re: [Xen-devel] [PATCH v9 06/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/01/18 02:19, Boris Ostrovsky wrote:
>
>
> On 01/22/2018 07:17 PM, Andrew Cooper wrote:
>> On 22/01/2018 22:27, Boris Ostrovsky wrote:
>>> On 01/19/2018 08:36 AM, Andrew Cooper wrote:
>>>> On 19/01/18 11:43, Jan Beulich wrote:
>>>>
>>>>>> @@ -99,6 +106,10 @@ UNLIKELY_END(realmode)
>>>>>>   .Lvmx_vmentry_fail:
>>>>>>           sti
>>>>>>           SAVE_ALL
>>>>>> +
>>>>>> +        SPEC_CTRL_ENTRY_FROM_PV /* Req: %rsp=regs/cpuinfo Clob:
>>>>>> acd */
>>>>> I think the use of the PV variant here requires a comment.
>>>> Oh.  It used to have one...  I'll try to find it.
>>> I, in fact, meant to ask about this for a long time and always forgot.
>>> Perhaps your comment will say more than just why a PV variant is used
>>> here but in case it won't --- why do we have *any* mitigation here? We
>>> are never returning to the guest, do we?
>>
>> We never return to *this* guest, but we are still open to abuse from a
>> separate hyperthread, so still need to set SPEC_CTRL.IBRS if we are
>> using IBRS for safety.  (If we are using lfence+jmp or repoline then we
>> don't need this change, but its not a hotpath so doesn't warrant yet
>> another variant of SPEC_CTRL_ENTRY_FROM_*.)
>
>
> We wrote IBRS during VMEXIT. I thought this serves as barrier for all
> preceding predictions (both threads) from lower protection mode.

There is no guarantee that a sequence which sets IBRS, then clears it,
serves to flush older predictions.

In practice, some implementations of IBRS are a flush internally, and
some are a disable internally.  This is why the semantics require you to
rewrite it the value 1 on entry to a higher mode (even if it was
previously set), and keep it set for the duration of protection you want.

> Is the concern here that SPEC_CTRL_EXIT_TO_GUEST (before VMENTER) may
> set IBRS to 0 and *that* will open hypervisor to other thread's mischief?

Correct.

~Andrew

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