[PATCH v2 0/2] KVM: nVMX: Add IBPB between L2 and L1 to

[PATCH v2 0/2] KVM: nVMX: Add IBPB between L2 and L1 to

[Jim Mattson]

Since L1 and L2 share branch prediction modes (guest {kernel,user}), the
hardware will not protect indirect branches in L1 from steering by a
malicious agent in L2. However, IBRS guarantees this protection. (For
basic IBRS, a value of 1 must be written to IA32_SPEC_CTRL.IBRS after
the transition  from L2 to L1.)

Fix the regression introduced in commit 5c911beff20a ("KVM: nVMX: Skip
IBPB when switching between vmcs01 and vmcs02") by issuing an IBPB when
emulating a VM-exit from L2 to L1.

This is CVE-2022-2196.

v2: Reworded some comments [Sean].

Jim Mattson (2):
  KVM: VMX: Guest usage of IA32_SPEC_CTRL is likely
  KVM: VMX: Execute IBPB on emulated VM-exit when guest has IBRS

 arch/x86/kvm/vmx/nested.c | 11 +++++++++++
 arch/x86/kvm/vmx/vmx.c    | 10 ++++++----
 2 files changed, 17 insertions(+), 4 deletions(-)

-- 
2.38.0.413.g74048e4d9e-goog

[PATCH v2 1/2] KVM: VMX: Guest usage of IA32_SPEC_CTRL is likely

[Jim Mattson]

At this point in time, most guests (in the default, out-of-the-box
configuration) are likely to use IA32_SPEC_CTRL.  Therefore, drop the
compiler hint that it is unlikely for KVM to be intercepting WRMSR of
IA32_SPEC_CTRL.

Signed-off-by: Jim Mattson <jmattson@google.com>
---
 arch/x86/kvm/vmx/vmx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 9dba04b6b019..b092f61b8258 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -858,7 +858,7 @@ unsigned int __vmx_vcpu_run_flags(struct vcpu_vmx *vmx)
 	 * to change it directly without causing a vmexit.  In that case read
 	 * it after vmexit and store it in vmx->spec_ctrl.
 	 */
-	if (unlikely(!msr_write_intercepted(vmx, MSR_IA32_SPEC_CTRL)))
+	if (!msr_write_intercepted(vmx, MSR_IA32_SPEC_CTRL))
 		flags |= VMX_RUN_SAVE_SPEC_CTRL;
 
 	return flags;
-- 
2.38.0.413.g74048e4d9e-goog

[PATCH v2 2/2] KVM: VMX: Execute IBPB on emulated VM-exit when guest has IBRS

[Jim Mattson]

According to Intel's document on Indirect Branch Restricted
Speculation, "Enabling IBRS does not prevent software from controlling
the predicted targets of indirect branches of unrelated software
executed later at the same predictor mode (for example, between two
different user applications, or two different virtual machines). Such
isolation can be ensured through use of the Indirect Branch Predictor
Barrier (IBPB) command." This applies to both basic and enhanced IBRS.

Since L1 and L2 VMs share hardware predictor modes (guest-user and
guest-kernel), hardware IBRS is not sufficient to virtualize
IBRS. (The way that basic IBRS is implemented on pre-eIBRS parts,
hardware IBRS is actually sufficient in practice, even though it isn't
sufficient architecturally.)

For virtual CPUs that support IBRS, add an indirect branch prediction
barrier on emulated VM-exit, to ensure that the predicted targets of
indirect branches executed in L1 cannot be controlled by software that
was executed in L2.

Since we typically don't intercept guest writes to IA32_SPEC_CTRL,
perform the IBPB at emulated VM-exit regardless of the current
IA32_SPEC_CTRL.IBRS value, even though the IBPB could technically be
deferred until L1 sets IA32_SPEC_CTRL.IBRS, if IA32_SPEC_CTRL.IBRS is
clear at emulated VM-exit.

This is CVE-2022-2196.

Fixes: 5c911beff20a ("KVM: nVMX: Skip IBPB when switching between vmcs01 and vmcs02")
Cc: Sean Christopherson <seanjc@google.com>
Signed-off-by: Jim Mattson <jmattson@google.com>
---
 arch/x86/kvm/vmx/nested.c | 11 +++++++++++
 arch/x86/kvm/vmx/vmx.c    |  6 ++++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 0c62352dda6a..cd70ab63e919 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -4767,6 +4767,17 @@ void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 vm_exit_reason,
 
 	vmx_switch_vmcs(vcpu, &vmx->vmcs01);
 
+	/*
+	 * If IBRS is advertised to the vCPU, KVM must flush the indirect
+	 * branch predictors when transitioning from L2 to L1, as L1 expects
+	 * hardware (KVM in this case) to provide separate predictor modes.
+	 * Bare metal isolates VMX root (host) from VMX non-root (guest), but
+	 * doesn't isolate different VMCSs, i.e. in this case, doesn't provide
+	 * separate modes for L2 vs L1.
+	 */
+	if (guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL))
+		indirect_branch_prediction_barrier();
+
 	/* Update any VMCS fields that might have changed while L2 ran */
 	vmcs_write32(VM_EXIT_MSR_LOAD_COUNT, vmx->msr_autoload.host.nr);
 	vmcs_write32(VM_ENTRY_MSR_LOAD_COUNT, vmx->msr_autoload.guest.nr);
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index b092f61b8258..c12fd0ca3ad6 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1348,8 +1348,10 @@ void vmx_vcpu_load_vmcs(struct kvm_vcpu *vcpu, int cpu,
 
 		/*
 		 * No indirect branch prediction barrier needed when switching
-		 * the active VMCS within a guest, e.g. on nested VM-Enter.
-		 * The L1 VMM can protect itself with retpolines, IBPB or IBRS.
+		 * the active VMCS within a vCPU, unless IBRS is advertised to
+		 * the vCPU.  To minimize the number of IBPBs executed, KVM
+		 * performs IBPB on nested VM-Exit (a single nested transition
+		 * may switch the active VMCS multiple times).
 		 */
 		if (!buddy || WARN_ON_ONCE(buddy->vmcs != prev))
 			indirect_branch_prediction_barrier();
-- 
2.38.0.413.g74048e4d9e-goog

Re: [PATCH v2 0/2] KVM: nVMX: Add IBPB between L2 and L1 to

[Jim Mattson]

On Wed, Oct 19, 2022 at 2:36 PM Jim Mattson <jmattson@google.com> wrote:
>
> Since L1 and L2 share branch prediction modes (guest {kernel,user}), the
> hardware will not protect indirect branches in L1 from steering by a
> malicious agent in L2. However, IBRS guarantees this protection. (For
> basic IBRS, a value of 1 must be written to IA32_SPEC_CTRL.IBRS after
> the transition  from L2 to L1.)
>
> Fix the regression introduced in commit 5c911beff20a ("KVM: nVMX: Skip
> IBPB when switching between vmcs01 and vmcs02") by issuing an IBPB when
> emulating a VM-exit from L2 to L1.
>
> This is CVE-2022-2196.
>
> v2: Reworded some comments [Sean].
>
> Jim Mattson (2):
>   KVM: VMX: Guest usage of IA32_SPEC_CTRL is likely
>   KVM: VMX: Execute IBPB on emulated VM-exit when guest has IBRS
>
>  arch/x86/kvm/vmx/nested.c | 11 +++++++++++
>  arch/x86/kvm/vmx/vmx.c    | 10 ++++++----
>  2 files changed, 17 insertions(+), 4 deletions(-)
>
> --
> 2.38.0.413.g74048e4d9e-goog
>

Ping?

Re: [PATCH v2 1/2] KVM: VMX: Guest usage of IA32_SPEC_CTRL is likely

[Sean Christopherson]

On Wed, Oct 19, 2022, Jim Mattson wrote:
> At this point in time, most guests (in the default, out-of-the-box
> configuration) are likely to use IA32_SPEC_CTRL.  Therefore, drop the
> compiler hint that it is unlikely for KVM to be intercepting WRMSR of
> IA32_SPEC_CTRL.
> 
> Signed-off-by: Jim Mattson <jmattson@google.com>
> ---

Reviewed-by: Sean Christopherson <seanjc@google.com>

Re: [PATCH v2 2/2] KVM: VMX: Execute IBPB on emulated VM-exit when guest has IBRS

[Sean Christopherson]

On Wed, Oct 19, 2022, Jim Mattson wrote:
> According to Intel's document on Indirect Branch Restricted
> Speculation, "Enabling IBRS does not prevent software from controlling
> the predicted targets of indirect branches of unrelated software
> executed later at the same predictor mode (for example, between two
> different user applications, or two different virtual machines). Such
> isolation can be ensured through use of the Indirect Branch Predictor
> Barrier (IBPB) command." This applies to both basic and enhanced IBRS.
> 
> Since L1 and L2 VMs share hardware predictor modes (guest-user and
> guest-kernel), hardware IBRS is not sufficient to virtualize
> IBRS. (The way that basic IBRS is implemented on pre-eIBRS parts,
> hardware IBRS is actually sufficient in practice, even though it isn't
> sufficient architecturally.)
> 
> For virtual CPUs that support IBRS, add an indirect branch prediction
> barrier on emulated VM-exit, to ensure that the predicted targets of
> indirect branches executed in L1 cannot be controlled by software that
> was executed in L2.
> 
> Since we typically don't intercept guest writes to IA32_SPEC_CTRL,
> perform the IBPB at emulated VM-exit regardless of the current
> IA32_SPEC_CTRL.IBRS value, even though the IBPB could technically be
> deferred until L1 sets IA32_SPEC_CTRL.IBRS, if IA32_SPEC_CTRL.IBRS is
> clear at emulated VM-exit.
> 
> This is CVE-2022-2196.
> 
> Fixes: 5c911beff20a ("KVM: nVMX: Skip IBPB when switching between vmcs01 and vmcs02")
> Cc: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Jim Mattson <jmattson@google.com>
> ---

Reviewed-by: Sean Christopherson <seanjc@google.com>

Re: [PATCH v2 0/2] KVM: nVMX: Add IBPB between L2 and L1 to

[Sean Christopherson]

On Wed, Oct 19, 2022, Jim Mattson wrote:
> Since L1 and L2 share branch prediction modes (guest {kernel,user}), the
> hardware will not protect indirect branches in L1 from steering by a
> malicious agent in L2. However, IBRS guarantees this protection. (For
> basic IBRS, a value of 1 must be written to IA32_SPEC_CTRL.IBRS after
> the transition  from L2 to L1.)
> 
> Fix the regression introduced in commit 5c911beff20a ("KVM: nVMX: Skip
> IBPB when switching between vmcs01 and vmcs02") by issuing an IBPB when
> emulating a VM-exit from L2 to L1.
> 
> This is CVE-2022-2196.
> 
> v2: Reworded some comments [Sean].
> 
> Jim Mattson (2):
>   KVM: VMX: Guest usage of IA32_SPEC_CTRL is likely
>   KVM: VMX: Execute IBPB on emulated VM-exit when guest has IBRS
> 
>  arch/x86/kvm/vmx/nested.c | 11 +++++++++++
>  arch/x86/kvm/vmx/vmx.c    | 10 ++++++----
>  2 files changed, 17 insertions(+), 4 deletions(-)
> 
> -- 

Merged to kvm/queue, thanks!

https://lore.kernel.org/all/Y4lHxds8pvBhxXFX@google.com