From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
Tony Luck <tony.luck@intel.com>,
"Gomez Iglesias, Antonio" <antonio.gomez.iglesias@intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Fenghua Yu <fenghua.yu@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Anthony Steinhauser <asteinhauser@google.com>,
Mike Rapoport <rppt@linux.ibm.com>,
Mark Gross <mgross@linux.intel.com>,
Waiman Long <longman@redhat.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH] x86/bugs/multihit: Fix mitigation reporting when KVM is not in use
Date: Tue, 14 Jul 2020 17:51:30 -0700 [thread overview]
Message-ID: <20200715005130.GE14404@linux.intel.com> (raw)
In-Reply-To: <e12cd3b8-7df1-94e8-e603-39e00648c026@intel.com>
On Tue, Jul 14, 2020 at 02:20:59PM -0700, Dave Hansen wrote:
> On 7/14/20 2:04 PM, Pawan Gupta wrote:
> >> I see three inputs and four possible states (sorry for the ugly table,
> >> it was this or a spreadsheet :):
> >>
> >> X86_FEATURE_VMX CONFIG_KVM_* hpage split Result Reason
> >> N x x Not Affected No VMX
> >> Y N x Not affected No KVM
This line item is pointless, the relevant itlb_multihit_show_state()
implementation depends on CONFIG_KVM_INTEL. The !KVM_INTEL version simply
prints ""Processor vulnerable".
> >> Y Y Y Mitigated hpage split
> >> Y Y N Vulnerable
> > Thank you.
> >
> > Just a note... for the last 2 cases kernel wont know about "hpage split"
> > mitigation until KVM is loaded. So for these cases reporting at boot
> > will be "Vulnerable" and would change to "Mitigated" once KVM is loaded
> > and deploys the mitigation. This is the current behavior.
>
> That's OK with me, because it's actually pretty closely tied to reality.
> You are literally "vulnerable" until you've committed to a mitigation
> and that doesn't happen until KVM is loaded.
Not that it really matters since itlb_multihit_show_state() reflects current
state, but loading KVM doesn't commit to a mitigation. KVM's nx_huge_pages
module param is writable by root, e.g. the mitigation can be turned off
while KVM is loaded and even while guests are running.
To do the above table, KVM will also need to update itlb_multihit_kvm_mitigation
when it is unloaded, which seems rather silly. That's partly why I suggested
keying off CR4.VMXE as it doesn't require poking directly into KVM. E.g. the
entire fix becomes:
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index ed54b3b21c39..4452df7f332d 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1447,7 +1447,12 @@ static ssize_t l1tf_show_state(char *buf)
static ssize_t itlb_multihit_show_state(char *buf)
{
- if (itlb_multihit_kvm_mitigation)
+ if (!boot_cpu_has(X86_FEATURE_MSR_IA32_FEAT_CTL) ||
+ !boot_cpu_has(X86_FEATURE_VMX))
+ return sprintf(buf, "KVM: Mitigation: VMX unsupported\n");
+ else if (!(cr4_read_shadow() & X86_CR4_VMXE))
+ return sprintf(buf, "KVM: Mitigation: VMX disabled\n");
+ else if (itlb_multihit_kvm_mitigation)
return sprintf(buf, "KVM: Mitigation: Split huge pages\n");
else
return sprintf(buf, "KVM: Vulnerable\n");
next prev parent reply other threads:[~2020-07-15 0:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 1:18 [PATCH] x86/bugs/multihit: Fix mitigation reporting when KVM is not in use Pawan Gupta
2020-07-14 1:45 ` Sean Christopherson
2020-07-14 14:57 ` Dave Hansen
2020-07-14 19:17 ` Pawan Gupta
2020-07-14 19:54 ` Dave Hansen
2020-07-14 21:04 ` Pawan Gupta
2020-07-14 21:20 ` Dave Hansen
2020-07-15 0:51 ` Sean Christopherson [this message]
2020-07-15 14:28 ` Dave Hansen
2020-07-15 17:18 ` Pawan Gupta
2020-07-15 18:04 ` Sean Christopherson
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=20200715005130.GE14404@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=antonio.gomez.iglesias@intel.com \
--cc=asteinhauser@google.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=jpoimboe@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=luto@kernel.org \
--cc=mgross@linux.intel.com \
--cc=mingo@redhat.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rppt@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vincenzo.frascino@arm.com \
--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;
as well as URLs for NNTP newsgroup(s).