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.
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?
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel