On Tue, 25 Jun 2019, Alejandro Jimenez wrote:
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:
/*
* 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:
If the host has it globally disabled then the mask needs to be clear.
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.
True.
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?
Indeed. Of course that was a decision we made _before_ all the other fancy things came around. Looks like we have to reopen that discussion.
Thanks,
tglx