linux-kernel - Re: [PATCH 2/2] KVM: x86: Emit IBPB on pCPU migration if IBPB is advertised to guest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aon55swe4yedwkzqavs23jyarksm2ddedgjjcm2yq742kblzwy@ritf2ohy3umu>
Date: Fri, 30 Jan 2026 18:22:58 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Jim Mattson <jmattson@...gle.com>, 
	David Kaplan <david.kaplan@....com>
Subject: Re: [PATCH 2/2] KVM: x86: Emit IBPB on pCPU migration if IBPB is
 advertised to guest

On Tue, Jan 27, 2026 at 05:34:32PM -0800, Sean Christopherson wrote:
> Emit an Indirect Branch Prediction Barrier if a vCPU is migrated to a
> different pCPU and IBPB support is advertised to the guest, to ensure any
> IBPBs performed by the guest are effective across pCPUs.  Ideally, KVM
> would only emit IBPB if the guest performed an IBPB since the vCPU last
> ran on the "new" pCPU, but pCPU migration is a relatively rare/slow path,
> and so the cost of tracking which pCPUs a vCPUs has run on, let alone
> intercepting PRED_CMD writes, outweighs the potential benefits of
> avoiding IBPBs on pCPU migration.
> 
> E.g. if a single vCPU is bouncing between pCPUs A and B, and the guest is
> doing IBPBs on context switches to mitigate cross-task attacks, then the
> following scenario can occur and needs to be mitigated by KVM:
> 
>  1. vCPU starts on pCPU A.  It runs a userspace task (task #1) which
>     installs various branch predictions into pCPU A's BTB.
>  2. The vCPU is migrated to pCPU B.
>  3. The guest switches to userspace task #2 and emits an IBPB, on pCPU B.
>  4. The vCPU is migrated back to pCPU A.  Userspace task (task #2) in the
>     guest now consumes the potentially dangerous branch predictions
>     installed in step 1 from task #1.
> 
> Reported-by: David Kaplan <david.kaplan@....com>
> Cc: stable@...r.kernel.org
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> ---
>  arch/x86/kvm/x86.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index e5ae655702b4..9d1641c2d83c 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5201,6 +5201,19 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
>  		kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
>  	}
>  
> +	/*
> +	 * If the vCPU is migrated to a different pCPU than the one on which
> +	 * the vCPU last ran, and IBPB is advertised to the vCPU, then flush
> +	 * indirect branch predictors before the next VM-Enter to ensure the
> +	 * vCPU doesn't consume prediction information from a previous run on
> +	 * the "new" pCPU.
> +	 */
> +	if (unlikely(vcpu->arch.last_vmentry_cpu != cpu &&
> +		     vcpu->arch.last_vmentry_cpu >= 0) &&
> +	    (guest_cpu_cap_has(vcpu, X86_FEATURE_SPEC_CTRL) ||
> +	     guest_cpu_cap_has(vcpu, X86_FEATURE_AMD_IBPB)))
> +		vcpu->arch.need_ibpb = true;

Disregarding deferring the IBPB, the logic looks sound. Should this be
moved right after the other IBPB condition above though?

> +
>  	if (unlikely(vcpu->cpu != cpu) || kvm_check_tsc_unstable()) {
>  		s64 tsc_delta = !vcpu->arch.last_host_tsc ? 0 :
>  				rdtsc() - vcpu->arch.last_host_tsc;
> -- 
> 2.52.0.457.g6b5491de43-goog
>