Re: [PATCH] KVM: vmx/nested: avoid blindly setting SECONDARY_EXEC_ENCLS_EXITING when sgx is enabled

[Paolo Bonzini]

On 10/25/22 19:21, Sean Christopherson wrote:
> Shortlog scope is still wrong, should be "KVM: nVMX:"
>
> The shortlog is also somewhat is misleading/confusing, as it's not at all obvious
> that "sgx enabled" means "KVM's sgx_module param is enabled" and not "SGX is enabled
> in the system".
>
> E.g.
>
>    KVM: nVMX: Advertise ENCLS_EXITING to L1 iff SGX is fully supported

Queued with this commit message:

---
KVM: VMX: fully disable SGX if SECONDARY_EXEC_ENCLS_EXITING unavailable

Clear enable_sgx if ENCLS-exiting is not supported, i.e. if SGX cannot be
virtualized.  When KVM is loaded, adjust_vmx_controls checks that the
bit is available before enabling the feature; however, other parts of the
code check enable_sgx and not clearing the variable caused two different
bugs, mostly affecting nested virtualization scenarios.

First, because enable_sgx remained true, SECONDARY_EXEC_ENCLS_EXITING
would be marked available in the capability MSR that are accessed by a
nested hypervisor.  KVM would then propagate the control from vmcs12
to vmcs02 even if it isn't supported by the processor, thus causing an
unexpected VM-Fail (exit code 0x7) in L1.

Second, vmx_set_cpu_caps() would not clear the SGX bits when hardware
support is unavailable.  This is a much less problematic bug as it only
happens if SGX is soft-disabled (available in the processor but hidden
in CPUID) or if SGX is supported for bare metal but not in the VMCS
(will never happen when running on bare metal, but can theoertically
happen when running in a VM).

Last but not least, this ensures that module params in sysfs reflect
KVM's actual configuration.

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2127128
Fixes: 72add915fbd5 ("KVM: VMX: Enable SGX virtualization for SGX1, SGX2 and LC")
Cc: stable@xxxxxxxxxxxxxxx
Suggested-by: Sean Christopherson <seanjc@xxxxxxxxxx>
Suggested-by: Bandan Das <bsd@xxxxxxxxxx>
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@xxxxxxxxxx>
Message-Id: <20221025123749.2201649-1-eesposit@xxxxxxxxxx>
Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
---

The bug is strictly speaking not in nVMX, although that's where most
of the symptoms surface.

Paolo