On 6/25/2019 12:05 PM, Thomas Gleixner wrote:
On Tue, 25 Jun 2019, Paolo Bonzini wrote:
On 10/06/19 19:20, Alejandro Jimenez wrote:
Btw, the proper prefix is: x86/speculation: Allow guests ....
I'll correct it on the next iteration of the patch.
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 03b4cc0..66ca906 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -836,6 +836,16 @@ static enum ssb_mitigation __init __ssb_select_mitigation(void)
}
/*
+ * If SSBD is controlled by the SPEC_CTRL MSR, then set the proper
+ * bit in the mask to allow guests to use the mitigation even in the
+ * case where the host does not enable it.
+ */
+ if (static_cpu_has(X86_FEATURE_SPEC_CTRL_SSBD) ||
+ static_cpu_has(X86_FEATURE_AMD_SSBD)) {
+ x86_spec_ctrl_mask |= SPEC_CTRL_SSBD;
Well, yes. But that also allows the guest to turn off SSBD if the host has
it disabled globally. So this needs to be conditional depending on the host
mode. It affects two places:
1) If the host has it globally disabled then the mask needs to be clear.
2) If the host has it specifically disabled for the VCPU thread, then it
shouldn't be allowed to be cleared by the guest either.
I see the argument that the host must be able to enforce its security
policies on the guests running on it. The guest OS would still be
'lying' by reporting that is running with the mitigation turned off, but
I suppose this is preferable to overriding the host's security policy.
I think that even with that approach there is still an unsolved problem,
as I believe guests are allowed to write directly to SPEC_CTRL MSR
without causing a VMEXIT, which bypasses the host masking entirely.
e.g. a guest using IBRS writes frequently to SPEC_CTRL, and could turn
off SSBD on the VPCU while is running after the first non-zero write to
the MSR. Do you agree?
Thank you for the feedback,
Alejandro
Thanks,
tglx
