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:
> >
> > 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.
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
