On 11/7/22 4:42 PM, Jim Mattson wrote:
On Mon, Nov 7, 2022 at 2:29 PM Kim Phillips <kim.phillips@xxxxxxx> wrote:
On 11/4/22 5:00 PM, Jim Mattson wrote:
On Fri, Nov 4, 2022 at 2:38 PM Kim Phillips <kim.phillips@xxxxxxx> wrote:
VM Guests may want to use Auto IBRS, so propagate the CPUID to them.
Co-developed-by: Babu Moger <Babu.Moger@xxxxxxx>
Signed-off-by: Kim Phillips <kim.phillips@xxxxxxx>
The APM says that, under AutoIBRS, CPL0 processes "have IBRS
protection." I'm taking this to mean only that indirect branches in
CPL0 are not subject to steering from a less privileged predictor
mode. This would imply that indirect branches executed at CPL0 in L1
could potentially be subject to steering by code running at CPL0 in
L2, since L1 and L2 share hardware predictor modes.
That's true for AMD processors that don't support Same Mode IBRS, also
documented in the APM.
Processors that support AutoIBRS also support Same Mode IBRS (see
CPUID Fn8000_0008_EBX[IbrsSameMode] (bit 19)).
Fortunately, there is an IBPB when switching VMCBs in svm_vcpu_load().
But it might be worth noting that this is necessary for AutoIBRS to
work (unless it actually isn't).
It is needed, but not for kernel/CPL0 code, rather to protect one
guest's user-space code from another's.
The question is whether it's necessary when switching between L1 and
L2 on the same vCPU of the same VM.
On the Intel side, this was (erroneously) optimized away in commit
5c911beff20a ("KVM: nVMX: Skip IBPB when switching between vmcs01 and
vmcs02").
Then why hasn't it been reverted?
Does its rationale not make sense?:
The IBPB is intended to prevent one guest from attacking another, which
is unnecessary in the nested case as it's the same guest from KVM's
perspective.
Thanks,
Kim
