public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marios Pomonis <pomonis@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	rkrcmar@redhat.com,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, Nick Finco <nifi@google.com>,
	Andrew Honig <ahonig@google.com>,
	Marios Pomonis <pomonis@google.com>
Subject: [PATCH v2 00/13] KVM: x86: Extend Spectre-v1 mitigation
Date: Wed, 11 Dec 2019 12:47:40 -0800	[thread overview]
Message-ID: <20191211204753.242298-1-pomonis@google.com> (raw)

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(-)

-- 
2.24.0.393.g34dc348eaf-goog


             reply	other threads:[~2019-12-11 20:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11 20:47 Marios Pomonis [this message]
2019-12-11 20:47 ` [PATCH v2 01/13] KVM: x86: Protect x86_decode_insn from Spectre-v1/L1TF attacks Marios Pomonis
2020-01-06 20:16   ` Jim Mattson
2019-12-11 20:47 ` [PATCH v2 02/13] KVM: x86: Protect kvm_hv_msr_[get|set]_crash_data() " Marios Pomonis
2019-12-12  9:43   ` Vitaly Kuznetsov
2019-12-12 17:11     ` Marios Pomonis
2019-12-12 17:31   ` Christian Borntraeger
2019-12-12 17:44     ` Jim Mattson
2019-12-12 17:47       ` Christian Borntraeger
2020-01-06 20:16         ` Jim Mattson
2019-12-11 20:47 ` [PATCH v2 03/13] KVM: x86: Refactor picdev_write() to prevent " Marios Pomonis
2020-01-06 20:17   ` Jim Mattson
2019-12-11 20:47 ` [PATCH v2 04/13] KVM: x86: Protect ioapic_read_indirect() from " Marios Pomonis
2020-01-06 20:17   ` Jim Mattson
2019-12-11 20:47 ` [PATCH v2 05/13] KVM: x86: Protect ioapic_write_indirect() " Marios Pomonis
2020-01-06 20:17   ` Jim Mattson
2019-12-11 20:47 ` [PATCH v2 06/13] KVM: x86: Protect kvm_lapic_reg_write() " Marios Pomonis
2020-01-06 20:17   ` Jim Mattson
2019-12-11 20:47 ` [PATCH v2 07/13] KVM: x86: Protect MSR-based index computations in fixed_msr_to_seg_unit() " Marios Pomonis
2020-01-06 20:18   ` Jim Mattson
2019-12-11 20:47 ` [PATCH v2 08/13] KVM: x86: Protect MSR-based index computations in pmu.h " Marios Pomonis
2020-01-06 20:18   ` Jim Mattson
2019-12-11 20:47 ` [PATCH v2 09/13] KVM: x86: Protect MSR-based index computations from Spectre-v1/L1TF attacks in x86.c Marios Pomonis
2020-01-06 20:18   ` Jim Mattson
2019-12-11 20:47 ` [PATCH v2 10/13] KVM: x86: Protect memory accesses " Marios Pomonis
2020-01-06 20:19   ` Jim Mattson
2020-01-18 20:13   ` Paolo Bonzini
2019-12-11 20:47 ` [PATCH v2 11/13] KVM: x86: Protect exit_reason from being used in Spectre-v1/L1TF attacks Marios Pomonis
2019-12-11 20:47 ` [PATCH v2 12/13] KVM: x86: Protect DR-based index computations from " Marios Pomonis
2020-01-06 20:19   ` Jim Mattson
2019-12-11 20:47 ` [PATCH v2 13/13] KVM: x86: Protect pmu_intel.c " Marios Pomonis
2020-01-06 20:19   ` Jim Mattson
2020-01-18 20:18 ` [PATCH v2 00/13] KVM: x86: Extend Spectre-v1 mitigation Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191211204753.242298-1-pomonis@google.com \
    --to=pomonis@google.com \
    --cc=ahonig@google.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nifi@google.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox