summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/syscall-counts.py
diff options
context:
space:
mode:
authorMarc Orr <marcorr@google.com>2019-04-02 09:55:59 +0300
committerPaolo Bonzini <pbonzini@redhat.com>2019-04-05 22:08:22 +0300
commitacff78477b9b4f26ecdf65733a4ed77fe837e9dc (patch)
tree2db0134eb76c0857b4bd58b356814edd100eb581 /tools/perf/scripts/python/syscall-counts.py
parentb86bc2858b389255cd44555ce4b1e427b2b770c0 (diff)
downloadlinux-acff78477b9b4f26ecdf65733a4ed77fe837e9dc.tar.xz
KVM: x86: nVMX: close leak of L0's x2APIC MSRs (CVE-2019-3887)
The nested_vmx_prepare_msr_bitmap() function doesn't directly guard the x2APIC MSR intercepts with the "virtualize x2APIC mode" MSR. As a result, we discovered the potential for a buggy or malicious L1 to get access to L0's x2APIC MSRs, via an L2, as follows. 1. L1 executes WRMSR(IA32_SPEC_CTRL, 1). This causes the spec_ctrl variable, in nested_vmx_prepare_msr_bitmap() to become true. 2. L1 disables "virtualize x2APIC mode" in VMCS12. 3. L1 enables "APIC-register virtualization" in VMCS12. Now, KVM will set VMCS02's x2APIC MSR intercepts from VMCS12, and then set "virtualize x2APIC mode" to 0 in VMCS02. Oops. This patch closes the leak by explicitly guarding VMCS02's x2APIC MSR intercepts with VMCS12's "virtualize x2APIC mode" control. The scenario outlined above and fix prescribed here, were verified with a related patch in kvm-unit-tests titled "Add leak scenario to virt_x2apic_mode_test". Note, it looks like this issue may have been introduced inadvertently during a merge---see 15303ba5d1cd. Signed-off-by: Marc Orr <marcorr@google.com> Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'tools/perf/scripts/python/syscall-counts.py')
0 files changed, 0 insertions, 0 deletions