diff options
author | Radim Krčmář <[email protected]> | 2016-08-08 20:16:22 +0200 |
---|---|---|
committer | Paolo Bonzini <[email protected]> | 2016-08-18 12:19:07 +0200 |
commit | d048c098218e91ed0e10dfa1f0f80e2567fe4ef7 (patch) | |
tree | 6a15a3f3637fe6cea4c4dd6004541141aed5361d /lib/cpu-notifier-error-inject.c | |
parent | 184ca823481c99dadd7d946e5afd4bb921eab30d (diff) |
KVM: nVMX: fix msr bitmaps to prevent L2 from accessing L0 x2APIC
msr bitmap can be used to avoid a VM exit (interception) on guest MSR
accesses. In some configurations of VMX controls, the guest can even
directly access host's x2APIC MSRs. See SDM 29.5 VIRTUALIZING MSR-BASED
APIC ACCESSES.
L2 could read all L0's x2APIC MSRs and write TPR, EOI, and SELF_IPI.
To do so, L1 would first trick KVM to disable all possible interceptions
by enabling APICv features and then would turn those features off;
nested_vmx_merge_msr_bitmap() only disabled interceptions, so VMX would
not intercept previously enabled MSRs even though they were not safe
with the new configuration.
Correctly re-enabling interceptions is not enough as a second bug would
still allow L1+L2 to access host's MSRs: msr bitmap was shared for all
VMCSs, so L1 could trigger a race to get the desired combination of msr
bitmap and VMX controls.
This fix allocates a msr bitmap for every L1 VCPU, allows only safe
x2APIC MSRs from L1's msr bitmap, and disables msr bitmaps if they would
have to intercept everything anyway.
Fixes: 3af18d9c5fe9 ("KVM: nVMX: Prepare for using hardware MSR bitmap")
Reported-by: Jim Mattson <[email protected]>
Suggested-by: Wincy Van <[email protected]>
Reviewed-by: Wanpeng Li <[email protected]>
Signed-off-by: Radim Krčmář <[email protected]>
Diffstat (limited to 'lib/cpu-notifier-error-inject.c')
0 files changed, 0 insertions, 0 deletions