From: Thomas Gleixner <tglx@linutronix.de>
To: speck@linutronix.de
Subject: Re: [PATCH V2] Documentation: Add section about CPU vulnerabilities
Date: Tue, 10 Jul 2018 23:01:37 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1807102259170.1588@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20180710180022.GD20718@char.us.oracle.com>
On Tue, 10 Jul 2018, speck for Konrad Rzeszutek Wilk wrote:
> > +Affected processors
> > +-------------------
> > +
> > +This vulnerability affects a wide range of Intel processors. The
>
> Perhaps spell out that AMD CPUs are _not_ affected? Say:
>
> This vulnerability affects a wide range of processors from Intel only (no AMD).
>
> > +vulnerability is not present on:
> > +
> > + - Older models, where the CPU family is < 6
> > +
> > + - A range of ATOM processors (Cedarview, Cloverview, Lincroft, Penwell,
> > + Pineview, Slivermont, Airmont, Merrifield)
> > +
> > + - The Core Duo Yonah variants (2006 - 2008)
> > +
> > + - The XEON PHI family
> > +
> > + - Processors which have the ARCH_CAP_RDCL_NO bit set in the
> > + IA32_ARCH_CAPABILITIES MSR. If the bit is set the CPU is not affected
> > + by the Meltdown vulnerability either. These CPUs should become
> > + available by end of 2018.
>
> And here too in case the reader of the guide skip the beginning of the paragraph
> and are just enumerating? Say:
>
> - AMD CPUs
> - VIA ?
Will do.
> > +Mitigation control for KVM - command line or module parameter
> > +-------------------------------------------------------------
> > +
> > +The KVM hypervisor mitigation mechanism, flushing the L1D cache when
> > +entering a guest, can be controlled from the kernel command line or when
> > +the KVM-Intel hypervisor is built as a module also with a module parameter.
> > +
> > +The option/parameter is "kvm-intel.vmentry_l1d_flush=". It takes the
> > +following arguments::
> > +
> > + always: L1D cache flush on every VMENTER.
> > +
> > + cond: Flush L1D on VMENTER only when the code between VMEXIT and
> > + VMENTER can leak host memory which is considered
> > + interesting for an attacker. This still can leak host data
> > + which allows e.g. to determine the hosts address space layout.
>
> What is 'host data' vs 'host memory' ?
Mental hickup on my side.
> > +
> > + never: Disables the mitigation
> > +
> > +The default is 'cond'. If 'l1tf=full' or 'l1tf=full,force' are given on the
> > +kernel command line, these take precedence.
>
> s/precedence/precedence over "kvm-intel.vmentry_l1d_flush="/
>
> (just to be crystal clear?)
I wait for that discussion to finally settle :)
> > +3.1. SMT not supported or disabled
> > +""""""""""""""""""""""""""""""""""
> > +
> > + If SMT is not supported by the processor or disabled in the BIOS or by
> > + the kernel, it's only required to enforce L1D flushing on VMENTER.
>
> .. Which would require 'l1tf=full'. Should the guide spell it out?
Yes
> > + - Disabling SMT:
> > +
> > + Disabling SMT and enforcing the L1D flushing provides the maximum
> > + amount of protection. This mitigation is not depending on any of the
> > + above mitigation methods.
>
> Perhaps say:
> Using 'l1tf=full' will achieve that.
Ack.
> > +
> > + - Disabling EPT:
> > +
> > + Disabling EPT provides the maximum amount of protection as well. It is
> > + not depending on any of the above mitigation methods. SMT can stay
> > + enabled and L1D flushing is not required, but the performance impact is
> > + significant.
>
> Perhaps say:
> Using 'kvm-intel ept=0' will achieve that.
Sure.
Thanks,
tglx
prev parent reply other threads:[~2018-07-10 21:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-09 21:29 [PATCH V2] Documentation: Add section about CPU vulnerabilities Thomas Gleixner
2018-07-09 22:18 ` [MODERATED] " Josh Poimboeuf
2018-07-10 11:35 ` Peter Zijlstra
2018-07-10 18:00 ` Konrad Rzeszutek Wilk
2018-07-10 21:01 ` Thomas Gleixner [this message]
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=alpine.DEB.2.21.1807102259170.1588@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=speck@linutronix.de \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).