[MODERATED] NX, nested virtualization and arch caps

[MODERATED] NX, nested virtualization and arch caps

[Paolo Bonzini]

Right now, the NX patches are not advertising the
ARCH_CAP_PSCHANGE_MC_NO bit to its guests (especially nested
hypervisors).  This is despite KVM's shadow paging will ensure that the
nested hypervisor's EPT pages are 4K in size.

This is because nx_huge_pages is writable.  Therefore, the value of the
parameter could change from Y to N while a guest runs, and then the
nested hypervisor would become vulnerable to the nested guest's bad
behavior.

On the other hand, if the ITLB_MULTIHIT mitigation is disabled, then any
guest is anyway vulnerable to other guests' shenanigans.  Therefore the
nested hypervisor can just ignore ITLB_MULTIHIT altogether, even if it
would then be vulnerable to L2's bad behavior.  And this means we can
unconditionally advertise to nested hypervisors that the processor is
not vulnerable.

Are there any issues with this reasoning?

Thanks,

Paolo

[MODERATED] Re: ***UNCHECKED*** NX, nested virtualization and arch caps

[Joerg Roedel]

Hi Paolo,

On Tue, Oct 15, 2019 at 11:45:14AM +0200, speck for Paolo Bonzini wrote:
> Right now, the NX patches are not advertising the
> ARCH_CAP_PSCHANGE_MC_NO bit to its guests (especially nested
> hypervisors).  This is despite KVM's shadow paging will ensure that the
> nested hypervisor's EPT pages are 4K in size.
> 
> This is because nx_huge_pages is writable.  Therefore, the value of the
> parameter could change from Y to N while a guest runs, and then the
> nested hypervisor would become vulnerable to the nested guest's bad
> behavior.
> 
> On the other hand, if the ITLB_MULTIHIT mitigation is disabled, then any
> guest is anyway vulnerable to other guests' shenanigans.  Therefore the
> nested hypervisor can just ignore ITLB_MULTIHIT altogether, even if it
> would then be vulnerable to L2's bad behavior.  And this means we can
> unconditionally advertise to nested hypervisors that the processor is
> not vulnerable.
> 
> Are there any issues with this reasoning?

I also think that any nested hypervisor can ignore the ITLB_MULTIHIT
bug, but for a different reason: The host also builds the nested EPT
table as a shadow of the guests EPT table, so it does the mitigation on
behalf of the nested hypervisor.

Regards,

	Joerg

[MODERATED] Re: ***UNCHECKED*** Re: NX, nested virtualization and arch caps

[Joerg Roedel]

On Wed, Oct 16, 2019 at 10:15:07AM +0200, speck for Joerg Roedel wrote:
> I also think that any nested hypervisor can ignore the ITLB_MULTIHIT
> bug, but for a different reason: The host also builds the nested EPT
> table as a shadow of the guests EPT table, so it does the mitigation on
> behalf of the nested hypervisor.

Left out the case where host mitigation is disabled: I agree in this
case too with your reasoning, one should only disable the host
mitigation when the guests are trusted. And the guests are only trusted
when they only run trusted guests themselves.

By passing through the issue to the nested hypervisor we could support
untrusted nested guests on trusted guests with host mitigation disabled.
But this is probably not faster than enabling the mitigation on the host
because then KVM will trap/emulate all the guest EPT updates for
splitting/promoting hugepages.

Regards,

	Joerg