| Message ID | 20191211204753.242298-1-pomonis@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | KVM: x86: Extend Spectre-v1 mitigation | expand |
On 11/12/19 21:47, Marios Pomonis wrote: > From: Nick Finco <nifi@google.com> > > This extends the Spectre-v1 mitigation introduced in > commit 75f139aaf896 ("KVM: x86: Add memory barrier on vmcs field lookup") > and commit 085331dfc6bb ("x86/kvm: Update spectre-v1 mitigation") in light > of the Spectre-v1/L1TF combination described here: > https://xenbits.xen.org/xsa/advisory-289.html > > As reported in the link, an attacker can use the cache-load part of a > Spectre-v1 gadget to bring memory into the L1 cache, then use L1TF to > leak the loaded memory. Note that this attack is not fully mitigated by > core scheduling; firstly when "kvm-intel.vmentry_l1d_flush" is not set > to "always", an attacker could use L1TF on the same thread that loaded the > memory values in the cache on paths that do not flush the L1 cache on > VMEntry. Otherwise, an attacker could perform this attack using a > collusion of two sibling hyperthreads: one that loads memory values in > the cache during VMExit handling and another that performs L1TF to leak > them. > > This patch uses array_index_nospec() to prevent index computations from > causing speculative loads into the L1 cache. These cases involve a > bounds check followed by a memory read using the index; this is more > common than the full Spectre-v1 pattern. In some cases, the index > computation can be eliminated entirely by small amounts of refactoring. > > Marios Pomonis (13): > KVM: x86: Protect x86_decode_insn from Spectre-v1/L1TF attacks > KVM: x86: Protect kvm_hv_msr_[get|set]_crash_data() from > Spectre-v1/L1TF attacks > KVM: x86: Refactor picdev_write() to prevent Spectre-v1/L1TF attacks > KVM: x86: Protect ioapic_read_indirect() from Spectre-v1/L1TF attacks > KVM: x86: Protect ioapic_write_indirect() from Spectre-v1/L1TF attacks > KVM: x86: Protect kvm_lapic_reg_write() from Spectre-v1/L1TF attacks > KVM: x86: Protect MSR-based index computations in > fixed_msr_to_seg_unit() > KVM: x86: Protect MSR-based index computations in pmu.h > KVM: x86: Protect MSR-based index computations from Spectre-v1/L1TF > attacks in x86.c > KVM: x86: Protect memory accesses from Spectre-v1/L1TF attacks in > x86.c > KVM: x86: Protect exit_reason from being used in Spectre-v1/L1TF > attacks > KVM: x86: Protect DR-based index computations from Spectre-v1/L1TF > attacks > KVM: x86: Protect pmu_intel.c from Spectre-v1/L1TF attacks > > arch/x86/kvm/emulate.c | 11 ++++-- > arch/x86/kvm/hyperv.c | 10 +++-- > arch/x86/kvm/i8259.c | 6 ++- > arch/x86/kvm/ioapic.c | 15 +++++--- > arch/x86/kvm/lapic.c | 13 +++++-- > arch/x86/kvm/mtrr.c | 8 +++- > arch/x86/kvm/pmu.h | 18 +++++++-- > arch/x86/kvm/vmx/pmu_intel.c | 24 ++++++++---- > arch/x86/kvm/vmx/vmx.c | 71 +++++++++++++++++++++--------------- > arch/x86/kvm/x86.c | 18 +++++++-- > 10 files changed, 129 insertions(+), 65 deletions(-) > Queued all except patch 10, thanks. Paolo
From: Nick Finco <nifi@google.com> This extends the Spectre-v1 mitigation introduced in commit 75f139aaf896 ("KVM: x86: Add memory barrier on vmcs field lookup") and commit 085331dfc6bb ("x86/kvm: Update spectre-v1 mitigation") in light of the Spectre-v1/L1TF combination described here: https://xenbits.xen.org/xsa/advisory-289.html As reported in the link, an attacker can use the cache-load part of a Spectre-v1 gadget to bring memory into the L1 cache, then use L1TF to leak the loaded memory. Note that this attack is not fully mitigated by core scheduling; firstly when "kvm-intel.vmentry_l1d_flush" is not set to "always", an attacker could use L1TF on the same thread that loaded the memory values in the cache on paths that do not flush the L1 cache on VMEntry. Otherwise, an attacker could perform this attack using a collusion of two sibling hyperthreads: one that loads memory values in the cache during VMExit handling and another that performs L1TF to leak them. This patch uses array_index_nospec() to prevent index computations from causing speculative loads into the L1 cache. These cases involve a bounds check followed by a memory read using the index; this is more common than the full Spectre-v1 pattern. In some cases, the index computation can be eliminated entirely by small amounts of refactoring. Marios Pomonis (13): KVM: x86: Protect x86_decode_insn from Spectre-v1/L1TF attacks KVM: x86: Protect kvm_hv_msr_[get|set]_crash_data() from Spectre-v1/L1TF attacks KVM: x86: Refactor picdev_write() to prevent Spectre-v1/L1TF attacks KVM: x86: Protect ioapic_read_indirect() from Spectre-v1/L1TF attacks KVM: x86: Protect ioapic_write_indirect() from Spectre-v1/L1TF attacks KVM: x86: Protect kvm_lapic_reg_write() from Spectre-v1/L1TF attacks KVM: x86: Protect MSR-based index computations in fixed_msr_to_seg_unit() KVM: x86: Protect MSR-based index computations in pmu.h KVM: x86: Protect MSR-based index computations from Spectre-v1/L1TF attacks in x86.c KVM: x86: Protect memory accesses from Spectre-v1/L1TF attacks in x86.c KVM: x86: Protect exit_reason from being used in Spectre-v1/L1TF attacks KVM: x86: Protect DR-based index computations from Spectre-v1/L1TF attacks KVM: x86: Protect pmu_intel.c from Spectre-v1/L1TF attacks arch/x86/kvm/emulate.c | 11 ++++-- arch/x86/kvm/hyperv.c | 10 +++-- arch/x86/kvm/i8259.c | 6 ++- arch/x86/kvm/ioapic.c | 15 +++++--- arch/x86/kvm/lapic.c | 13 +++++-- arch/x86/kvm/mtrr.c | 8 +++- arch/x86/kvm/pmu.h | 18 +++++++-- arch/x86/kvm/vmx/pmu_intel.c | 24 ++++++++---- arch/x86/kvm/vmx/vmx.c | 71 +++++++++++++++++++++--------------- arch/x86/kvm/x86.c | 18 +++++++-- 10 files changed, 129 insertions(+), 65 deletions(-)