On Wed, Feb 22, 2023 at 12:06:25PM +0200, Ovidiu Panait wrote:
> From: Jim Mattson <jmattson@xxxxxxxxxx>
>
> commit 2e7eab81425ad6c875f2ed47c0ce01e78afc38a5 upstream.
>
> 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@xxxxxxxxxx>
> Signed-off-by: Jim Mattson <jmattson@xxxxxxxxxx>
> Reviewed-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> Link: https://lore.kernel.org/r/20221019213620.1953281-3-jmattson@xxxxxxxxxx
> Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> Signed-off-by: Ovidiu Panait <ovidiu.panait@xxxxxxxxxxxxxxxxx>
> ---
This was already added to the queues, thanks.
greg k-h
