[MODERATED] Settings question

[MODERATED] Settings question

[Borislav Petkov]

Hi folks,

so we just had this question:

Imagine you boot the *host* with

  spec_store_bypass_disable=on

which means, you enable the mitigation system-wide. Now someone boots
a guest with

  spec_store_bypass_disable=off

 because someone wants performance in the guest and doesn't care about
leaking sensitive info through the side channel.

Right now the guest can't override the setting because the host has
disabled it system-wide.

And both use cases have their merits - host-enforced mitigation on vs
guests are allowed to disable the mitigation so as not to pay the perf
penalty.

What do we allow?

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[MODERATED] Re: Settings question

[Paolo Bonzini]

On 14/05/2018 19:57, speck for Borislav Petkov wrote:
> Hi folks,
> 
> so we just had this question:
> 
> Imagine you boot the *host* with
> 
>   spec_store_bypass_disable=3Don
> 
> which means, you enable the mitigation system-wide. Now someone boots
> a guest with
> 
>   spec_store_bypass_disable=3Doff
> 
>  because someone wants performance in the guest and doesn't care about
> leaking sensitive info through the side channel.
> 
> Right now the guest can't override the setting because the host has
> disabled it system-wide.
> 
> And both use cases have their merits - host-enforced mitigation on vs
> guests are allowed to disable the mitigation so as not to pay the perf
> penalty.
> 
> What do we allow?

We pretty much have to allow only the case where guests can disable
SSBD.  Having rdmsr/wrmsr vmexits on every context switch would be too
expensive, and therefore KVM special cases SPEC_CTRL and lets the guest
access it without vmexits.

(Some gory and unrelated details, in case you look at the code:
rdmsr/wrmsr is also expensive to have on every vmentry, so this is
actually enabled lazily.  As soon as the VM accesses SPEC_CTRL, it will
have to pay the price forever.  However, if it doesn't access SPEC_CTRL,
there is no penalty.  The idea is that once a VM that accesses SPEC_CTRL
it is unlikely to stop doing so, especially since we don't have to deal
with nasty firmware writers...).

Paolo

Re: Settings question

[Thomas Gleixner]

On Tue, 15 May 2018, speck for Paolo Bonzini wrote:
> On 14/05/2018 19:57, speck for Borislav Petkov wrote:
> > Hi folks,
> > 
> > so we just had this question:
> > 
> > Imagine you boot the *host* with
> > 
> >   spec_store_bypass_disable=3Don
> > 
> > which means, you enable the mitigation system-wide. Now someone boots
> > a guest with
> > 
> >   spec_store_bypass_disable=3Doff
> > 
> >  because someone wants performance in the guest and doesn't care about
> > leaking sensitive info through the side channel.
> > 
> > Right now the guest can't override the setting because the host has
> > disabled it system-wide.
> > 
> > And both use cases have their merits - host-enforced mitigation on vs
> > guests are allowed to disable the mitigation so as not to pay the perf
> > penalty.
> > 
> > What do we allow?
> 
> We pretty much have to allow only the case where guests can disable
> SSBD.  Having rdmsr/wrmsr vmexits on every context switch would be too
> expensive, and therefore KVM special cases SPEC_CTRL and lets the guest
> access it without vmexits.
> 
> (Some gory and unrelated details, in case you look at the code:
> rdmsr/wrmsr is also expensive to have on every vmentry, so this is
> actually enabled lazily.  As soon as the VM accesses SPEC_CTRL, it will
> have to pay the price forever.  However, if it doesn't access SPEC_CTRL,
> there is no penalty.  The idea is that once a VM that accesses SPEC_CTRL
> it is unlikely to stop doing so, especially since we don't have to deal
> with nasty firmware writers...).

So while you did not answer Borislav question and rather described the
status quo of the SPEC_CTRL MSR, I think what you want to have is:

1) Guest is allowed to write ANY (valid) value into MSR_SPEC_CTRL. The
   first access traps and after that the host hands the MSR through. This
   is to avoid vmexits when the guest toggles a SPEC_CTRL bit often,
   i.e. on context switch.

2) Host restores the host state on VMEXIT if the guest toouched the
   MSR_SPEC_CTRL and restores guest state on VMENTER

This happens under the assumption that even clearing a SPEC_CTRL bit,
i.e. disabling a mitigation, does not make the host vulnerable as long as
the VMEXIT restores SPEC_CTRL and has the other necessary protections in
place.

Correct?

Thanks,

	tglx

[MODERATED] Re: Settings question

[Konrad Rzeszutek Wilk]

On Tue, May 15, 2018 at 08:59:13PM +0200, speck for Thomas Gleixner wrote:
> On Tue, 15 May 2018, speck for Paolo Bonzini wrote:
> > On 14/05/2018 19:57, speck for Borislav Petkov wrote:
> > > Hi folks,
> > > 
> > > so we just had this question:
> > > 
> > > Imagine you boot the *host* with
> > > 
> > >   spec_store_bypass_disable=3Don
> > > 
> > > which means, you enable the mitigation system-wide. Now someone boots
> > > a guest with
> > > 
> > >   spec_store_bypass_disable=3Doff
> > > 
> > >  because someone wants performance in the guest and doesn't care about
> > > leaking sensitive info through the side channel.
> > > 
> > > Right now the guest can't override the setting because the host has
> > > disabled it system-wide.
> > > 
> > > And both use cases have their merits - host-enforced mitigation on vs
> > > guests are allowed to disable the mitigation so as not to pay the perf
> > > penalty.
> > > 
> > > What do we allow?
> > 
> > We pretty much have to allow only the case where guests can disable
> > SSBD.  Having rdmsr/wrmsr vmexits on every context switch would be too
> > expensive, and therefore KVM special cases SPEC_CTRL and lets the guest
> > access it without vmexits.
> > 
> > (Some gory and unrelated details, in case you look at the code:
> > rdmsr/wrmsr is also expensive to have on every vmentry, so this is
> > actually enabled lazily.  As soon as the VM accesses SPEC_CTRL, it will
> > have to pay the price forever.  However, if it doesn't access SPEC_CTRL,
> > there is no penalty.  The idea is that once a VM that accesses SPEC_CTRL
> > it is unlikely to stop doing so, especially since we don't have to deal
> > with nasty firmware writers...).
> 
> So while you did not answer Borislav question and rather described the
> status quo of the SPEC_CTRL MSR, I think what you want to have is:
> 
> 1) Guest is allowed to write ANY (valid) value into MSR_SPEC_CTRL. The
>    first access traps and after that the host hands the MSR through. This
>    is to avoid vmexits when the guest toggles a SPEC_CTRL bit often,
>    i.e. on context switch.
> 
> 2) Host restores the host state on VMEXIT if the guest toouched the
>    MSR_SPEC_CTRL and restores guest state on VMENTER

It has a slight optimization in that if the SPEC_CTRL MSR value is the
same as the host on VMENTER/VMEXIT it won't frob it.

> 
> This happens under the assumption that even clearing a SPEC_CTRL bit,
> i.e. disabling a mitigation, does not make the host vulnerable as long as
> the VMEXIT restores SPEC_CTRL and has the other necessary protections in
> place.
> 
> Correct?

Yes.
> 
> Thanks,
> 
> 	tglx
> 

[MODERATED] Re: Settings question

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]

On 15/05/2018 20:59, speck for Thomas Gleixner wrote:
> On Tue, 15 May 2018, speck for Paolo Bonzini wrote:
>> We pretty much have to allow only the case where guests can disable
>> SSBD.  Having rdmsr/wrmsr vmexits on every context switch would be too
>> expensive, and therefore KVM special cases SPEC_CTRL and lets the guest
>> access it without vmexits.
>
> So while you did not answer Borislav question and rather described the
> status quo of the SPEC_CTRL MSR, I think what you want to have is:
> 
> 1) Guest is allowed to write ANY (valid) value into MSR_SPEC_CTRL. The
>    first access traps and after that the host hands the MSR through. This
>    is to avoid vmexits when the guest toggles a SPEC_CTRL bit often,
>    i.e. on context switch.
> 
> 2) Host restores the host state on VMEXIT if the guest toouched the
>    MSR_SPEC_CTRL and restores guest state on VMENTER
> 
> This happens under the assumption that even clearing a SPEC_CTRL bit,
> i.e. disabling a mitigation, does not make the host vulnerable as long as
> the VMEXIT restores SPEC_CTRL and has the other necessary protections in
> place.
> 
> Correct?

Correct, and what you listed is actually how KVM already works (commit
d28b387fb74d, "KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL",
2018-02-03).  Right now the upstream code assumes that the host
spec_ctrl is 0, but "x86/bugs, KVM: Support the combination of guest and
host IBRS" changes it to take host SSBD into account:

	/* on vmentry */
-	if (vmx->spec_ctrl)
-		wrmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl);
+	x86_spec_ctrl_set_guest(vmx->spec_ctrl);
...

	/* on vmexit */
-	if (vmx->spec_ctrl)
-		wrmsrl(MSR_IA32_SPEC_CTRL, 0);
+	x86_spec_ctrl_restore_host(vmx->spec_ctrl);

Paolo