[PATCH V2] Documentation: Add section about CPU vulnerabilities

[PATCH V2] Documentation: Add section about CPU vulnerabilities

[Thomas Gleixner]

Subject: Documentation: Add section about CPU vulnerabilities
From: Thomas Gleixner <tglx@linutronix.de>

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---

V1 -> V2:

 - Address review comments
 - Reword some paragraphs substantially
 - Add EPT disabling as possible mitigation and document that
   non EPT capabale systems are protected
 - Formatting fixes (removes the weird pipes)
 

 Documentation/admin-guide/index.rst |    9 
 Documentation/admin-guide/l1tf.rst  |  401 ++++++++++++++++++++++++++++++++++++
 2 files changed, 410 insertions(+)

--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -17,6 +17,15 @@ etc.
    kernel-parameters
    devices
 
+This section describes CPU vulnerabilities and provides an overview of the
+possible mitigations along with guidance for selecting mitigations if they
+are configurable at compile, boot or run time.
+
+.. toctree::
+   :maxdepth: 1
+
+   l1tf
+
 Here is a set of documents aimed at users who are trying to track down
 problems and bugs in particular.
 
--- /dev/null
+++ b/Documentation/admin-guide/l1tf.rst
@@ -0,0 +1,401 @@
+L1TF - L1 Terminal Fault
+========================
+
+L1 Terminal Fault is a hardware vulnerability which allows unpriviledged
+speculative access to data which is available in the Level 1 Data Cache
+when the page table entry controlling the virtual address, which is used
+for the access, has the Present bit cleared or other reserved bits set.
+
+Affected processors
+-------------------
+
+This vulnerability affects a wide range of Intel processors. The
+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.
+
+Related CVEs
+------------
+
+The following CVE entries are related to the L1TF vulnerability::
+
+   CVE-2018-3615:  L1 Terminal Fault - SGX related aspects
+   CVE-2018-3620:  L1 Terminal Fault - OS, SMM related aspects
+   CVE-2018-3646:  L1 Terminal Fault - Virtualization related aspects
+
+Problem
+-------
+
+If an instruction accesses a virtual address for which the relevant page
+table entry (PTE) has the Present bit cleared or other reserved bits set,
+then speculative execution ignores the invalid PTE and loads the referenced
+data if it is present in the Level 1 Data Cache, as if the page referenced
+by the address bits in the PTE was still present and accessible.
+
+While this is a purely speculative mechanism and the instruction will raise
+a page fault when it is retired eventually, the pure act of loading the
+data and making it available to other speculative instructions opens up the
+opportunity for side channel attacks to unprivileged malicious code,
+similar to the Meltdown attack.
+
+While Meltdown breaks the user space to kernel space protection, L1TF has a
+broader scope. It allows to attack any physical memory address in the
+system and the attack works across all protection domains. It allows an
+attack of SGX and also works from inside virtual machines because the
+speculation bypasses the extended page table (EPT) protection mechanism.
+
+Attack scenarios
+----------------
+
+1. Malicious user space
+^^^^^^^^^^^^^^^^^^^^^^^
+
+   Operating Systems store arbitrary information in the address bits of a
+   PTE which is marked non present. This allows a malicious user space
+   application to attack the physical memory to which these PTEs resolve.
+   In some cases user-space can maliciously influence the information
+   encoded in the address bits of the PTE, thus making attacks more
+   deterministic and more practical.
+
+   The Linux kernel contains a mitigation for this attack vector, PTE
+   inversion, which is permanently enabled and has no performance
+   impact. The kernel ensures that the address bits of PTEs, which are not
+   marked present, never point to cacheable physical memory space.
+
+   A system with an up to date kernel is protected against attacks from
+   malicious user space applications.
+
+2. Malicious guest in a virtual machine
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+   The fact that L1TF breaks all domain protections allows malicious guest
+   OSes, which can control the PTEs directly, and malicious guest user
+   space applications, which run on an unprotected guest kernel lacking the
+   PTE inversion mitigation for L1TF, to attack physical host memory.
+
+   A special aspect of L1TF in the context of virtualization is symmetric
+   multi threading (SMT). The Intel implementation of SMT is called
+   HyperThreading. The fact that Hyperthreads on the affected processors
+   share the L1 Data Cache (L1D) is important for this. As the flaw allows
+   only to attack data which is present in L1D, a malicious guest running
+   on one Hyperthread can attack the data which is brought into the L1D by
+   the context which runs on the sibling Hyperthread of the same physical
+   core. This context can be host OS, host user space or a different guest.
+
+   If the processor does not support Extended Page Tables, the attack is
+   only possible, when the hypervisor does not sanitize the content of the
+   effective (shadow) page tables.
+
+   While solutions exist to mitigate these attack vectors fully, these
+   mitigations are not enabled by default in the Linux kernel because they
+   can affect performance significantly. The kernel provides several
+   mechanisms which can be utilized to address the problem depending on the
+   deployment scenario. The mitigations, their protection scope and impact
+   are described in the next sections.
+
+
+L1TF system information
+-----------------------
+
+The Linux kernel provides a sysfs interface to enumerate the current L1TF
+status of the system: whether the system is vulnerable, and which
+mitigations are active. The relevant sysfs file is:
+
+/sys/devices/system/cpu/vulnerabilities/l1tf
+
+Host mitigation mechanism
+-------------------------
+
+The kernel is unconditionally protected against L1TF attacks from malicious
+user space running on the host.
+
+Guest mitigation mechanisms
+---------------------------
+
+1. L1D flush on VMENTER
+^^^^^^^^^^^^^^^^^^^^^^^
+   To make sure that a guest cannot attack data which is present in the L1D
+   the hypervisor flushes the L1D before entering the guest.
+
+   Flushing the L1D evicts not only the data which should not be accessed
+   by a potentially malicious guest, it also flushes the guest
+   data. Flushing the L1D has a performance impact as the processor has to
+   bring the flushed guest data back into the L1D. Depending on the
+   frequency of VMEXIT/VMENTER and the type of computations in the guest
+   performance degradation in the range of 1% to 50% has been observed. For
+   scenarios where guest VMEXIT/VMENTER are rare the performance impact is
+   minimal. Virtio and mechanisms like posted interrupts are designed to
+   confine the VMEXITs to a bare minimum, but specific configurations and
+   application scenarios might still suffer from a high VMEXIT rate.
+
+   The general recommendation is to enable L1D flush on VMENTER.
+
+   Note, that L1D flush does not prevent the SMT problem because the
+   sibling thread will also bring back its data into the L1D which makes it
+   attackable again.
+
+   L1D flush can be controlled by the administrator.
+
+2. Guest VCPU confinement to dedicated physical cores
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+   To address the SMT problem, it is possible to make a guest or a group of
+   guests affine to one or more physical cores. The proper mechanism for
+   that is to utilize cpusets and to make sure that no other guest or host
+   tasks can run on these cores.
+
+   If only a single guest or related guests run on sibling SMT threads on
+   the same physical core then they can only attack their own memory and
+   restricted parts of the host memory.
+
+   Host memory is attackable, when one of the sibling SMT threads runs in
+   host OS (hypervisor) context and the other in guest context. The amount
+   of valuable information from the host OS context depends on the context
+   which the host OS executes, i.e. interrupts, soft interrupts and kernel
+   threads. The amount of valuable data from these contexts cannot be
+   declared as non-interesting for an attacker without deep inspection of
+   the code.
+
+   Note, that assigning guests to a fixed set of physical cores affects the
+   ability of the scheduler to do load balancing and might have negative
+   effects on CPU utilization depending on the hosting scenario. Disabling
+   SMT might be a viable alternative for particular scenarios.
+
+   For further information about confining guests to a single or to a group
+   of cores consult the cpusets documentation.
+
+3. Interrupt affinity
+^^^^^^^^^^^^^^^^^^^^^
+
+   Interrupts can be made affine to logical CPUs. This is not universally
+   true because there are types of interrupts which are truly per CPU
+   interrupts, e.g. the local timer interrupt. Aside of that multi queue
+   devices affine their interrupts to single CPUs or groups of CPUs per
+   queue without allowing the administrator to control the affinities.
+
+   Moving the interrupts, which can be affinity controlled, away from CPUs
+   which run untrusted guests, reduces the attack vector space.
+
+   Whether the interrupts with are affine to CPUs, which run untrusted
+   guests, provide interesting data for an attacker depends on the system
+   configuration and the scenarios which run on the system. While for some
+   of the interrupts it can be assumed that they wont expose interesting
+   information beyond exposing hints about the host OS memory layout, there
+   is no way to make general assumptions.
+
+   Interrupt affinity can be controlled by the administrator via the
+   /proc/irq/$NR/smp_affinity[_list] files.
+
+4. SMT control
+^^^^^^^^^^^^^^
+
+   To prevent the SMT issues of L1TF it might be necessary to disable SMT
+   completely. Disabling SMT can have a significant performance impact, but
+   the impact depends on the hosting scenario and the type of workloads.
+   The impact of disabling SMT needs also to be weighted against the impact
+   of other mitigation solutions like confining guests to dedicated cores.
+
+   The kernel provides a sysfs interface to retrieve the status of SMT and
+   to control it. It also provides a kernel command line interface to
+   control SMT.
+
+   The kernel command line interface consists of the following options::
+
+     nosmt:	Affects the bring up of the secondary CPUs during boot. The
+		kernel tries to bring all present CPUs online during the
+		boot process. "nosmt" makes sure that from each physical
+		core only one - the so called primary (hyper) thread is
+		activated. Due to a design flaw of Intel processors related
+		to Machine Check Exceptions the non primary siblings have
+		to be brought up at least partially and are then shut down
+		again.  "nosmt" can be undone via the sysfs interface.
+
+     nosmt=force: Has the same effect as "nosmt' but it does not allow to
+		  undo the SMT disable via the sysfs interface.
+
+   The sysfs interface provides two files:
+
+   - /sys/devices/system/cpu/smt/control
+   - /sys/devices/system/cpu/smt/active
+
+   /sys/devices/system/cpu/smt/control:
+
+     This file allows to read out the SMT control state and provides the
+     ability to disable or (re)enable SMT. The possible states are::
+
+	on:		SMT is supported by the CPU and enabled. All
+			logical CPUs can be onlined and offlined without
+			restrictions
+
+	off:		SMT is supported by the CPU and disabled. Only
+			the so called primary SMT threads can be onlined
+			and offlined without restrictions. An attempt to
+			online a non-primary sibling is rejected
+
+	forceoff:	Same as 'off' but the state cannot be controlled.
+			Attempts to write to the control file are rejected.
+
+	notsupported:	The processor does not support SMT. It's therefore
+			not affected by the SMT implications of L1TF.
+			Attempts to write to the control file are rejected.
+
+     The possible states which can be written into this file to control SMT
+     state are:
+
+     - on
+     - off
+     - forceoff
+
+   /sys/devices/system/cpu/smt/active:
+
+     This file reports whether SMT is enabled and active, i.e. if on any
+     physical core two or more sibling threads are online.
+
+5. Disabling EPT
+^^^^^^^^^^^^^^^^
+
+  Disabling EPT for virtual machines provides full mitigation for L1TF even
+  with SMT enabled, because the effective page tables for guests are
+  managed and sanitized by the hypervisor. Though disabling EPT has a
+  significant performance impact especially when the Meltdown mitigation
+  KPTI is enabled.
+
+There is ongoing research and development for new mitigation mechanisms to
+address the performance impact of disabling SMT or EPT.
+
+Mitigation control on the kernel command line
+---------------------------------------------
+
+The kernel command line allows to control the L1TF mitigations at boot
+time with the option "l1tf=". The valid arguments for this option are::
+
+  full:		Provide all available mitigations for the L1TF
+		vulnerability. Disable SMT and enable all mitigations
+		in the hypervisors. SMT control is still possible
+		after boot.
+
+  full,force:	Same as 'full', but disables SMT control. Implies the
+		'nosmt=force' command line option.
+
+  novirt:	Leaves SMT enabled and does not enable the hypervisor
+		mitigation. Hypervisors will issue a warning when the first
+		VM is being started in a potentially insecure
+		configuration, i.e. SMT enabled or L1D flush disabled.
+
+  novirt,nowarn: Same as 'novirt', but hypervisors will not warn when
+		 a VM is started in a potentially insecure configuration.
+
+The default is 'novirt'.
+
+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.
+
+  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.
+
+
+Mitigation selection guide
+--------------------------
+
+1. No virtualization in use
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+   The system is protected by the kernel unconditionally and no further
+   action is required.
+
+2. Virtualization with trusted guests
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+   If the guest comes from a trusted source and the guest OS kernel is
+   guaranteed to have the L1TF mitigations in place the system is fully
+   protected against L1TF and no further action is required.
+
+3. Virtualization with untrusted guests
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+3.2. EPT not supported or disabled
+""""""""""""""""""""""""""""""""""
+
+  If EPT is not supported by the processor or disabled in the hypervisor,
+  the system is fully protected. SMT can stay enabled and L1D flushing on
+  VMENTER is not required.
+
+3.3. SMT and EPT supported and active
+"""""""""""""""""""""""""""""""""""""
+
+  If SMT and EPT are supported and active then various degrees of
+  mitigations can be employed:
+
+  - L1D flushing on VMENTER:
+
+    L1D flushing on VMENTER is the minimal protection requirement, but it
+    is only potent in combination with other mitigation methods.
+
+  - Guest confinement:
+
+    Confinement of guests to a single or a group of physical cores which
+    are not running any other processes, can reduce the attack surface
+    significantly, but interrupts, soft interrupts and kernel threads can
+    still expose valuable data to a potential attacker.
+
+  - Interrupt isolation:
+
+    Isolating the guest CPUs from interrupts can reduce the attack surface
+    further, but still allows a malicious guest to explore a limited amount
+    of host physical memory. This can at least be used to gain knowledge
+    about the host address space layout. The interrupts which have a fixed
+    affinity to the CPUs which run the untrusted guests can depending on
+    the scenario still trigger soft interrupts and schedule kernel threads
+    which might expose valuable information.
+
+The above three mitigation methods combined can provide protection to a
+certain degree, but the risk of the remaining attack surface has to be
+carefully analyzed. For full protection the following methods are
+available:
+
+  - 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.
+
+  - 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.

[MODERATED] Re: [PATCH V2] Documentation: Add section about CPU vulnerabilities

[Josh Poimboeuf]

On Mon, Jul 09, 2018 at 11:29:57PM +0200, speck for Thomas Gleixner wrote:
> @@ -0,0 +1,401 @@
> +L1TF - L1 Terminal Fault
> +========================
> +
> +L1 Terminal Fault is a hardware vulnerability which allows unpriviledged

"unprivileged"

> +5. Disabling EPT
> +^^^^^^^^^^^^^^^^
> +
> +  Disabling EPT for virtual machines provides full mitigation for L1TF even
> +  with SMT enabled, because the effective page tables for guests are
> +  managed and sanitized by the hypervisor. Though disabling EPT has a
> +  significant performance impact especially when the Meltdown mitigation
> +  KPTI is enabled.

How is this done?

-- 
Josh

[MODERATED] Re: [PATCH V2] Documentation: Add section about CPU vulnerabilities

[Peter Zijlstra]

On Mon, Jul 09, 2018 at 05:18:32PM -0500, speck for Josh Poimboeuf wrote:
> On Mon, Jul 09, 2018 at 11:29:57PM +0200, speck for Thomas Gleixner wrote:
> > +5. Disabling EPT
> > +^^^^^^^^^^^^^^^^
> > +
> > +  Disabling EPT for virtual machines provides full mitigation for L1TF even
> > +  with SMT enabled, because the effective page tables for guests are
> > +  managed and sanitized by the hypervisor. Though disabling EPT has a
> > +  significant performance impact especially when the Meltdown mitigation
> > +  KPTI is enabled.
> 
> How is this done?

IIRC: rmmod kvm_intel; modprobe kvm_intel ept=0

[MODERATED] Re: [PATCH V2] Documentation: Add section about CPU vulnerabilities

[Konrad Rzeszutek Wilk]

Thank you for doing the write up.

I've some minor comments, please see below.


> +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 ?

..snip..
> +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' ?

> +
> +  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?)

> +
> +
> +Mitigation selection guide
> +--------------------------
> +
> +1. No virtualization in use
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +   The system is protected by the kernel unconditionally and no further
> +   action is required.
> +
> +2. Virtualization with trusted guests
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +   If the guest comes from a trusted source and the guest OS kernel is
> +   guaranteed to have the L1TF mitigations in place the system is fully
> +   protected against L1TF and no further action is required.
> +
> +3. Virtualization with untrusted guests
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +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?

> +
> +3.2. EPT not supported or disabled
> +""""""""""""""""""""""""""""""""""
> +
> +  If EPT is not supported by the processor or disabled in the hypervisor,
> +  the system is fully protected. SMT can stay enabled and L1D flushing on
> +  VMENTER is not required.
> +
> +3.3. SMT and EPT supported and active
> +"""""""""""""""""""""""""""""""""""""
> +
> +  If SMT and EPT are supported and active then various degrees of
> +  mitigations can be employed:
> +
> +  - L1D flushing on VMENTER:
> +
> +    L1D flushing on VMENTER is the minimal protection requirement, but it
> +    is only potent in combination with other mitigation methods.
> +
> +  - Guest confinement:
> +
> +    Confinement of guests to a single or a group of physical cores which
> +    are not running any other processes, can reduce the attack surface
> +    significantly, but interrupts, soft interrupts and kernel threads can
> +    still expose valuable data to a potential attacker.
> +
> +  - Interrupt isolation:
> +
> +    Isolating the guest CPUs from interrupts can reduce the attack surface
> +    further, but still allows a malicious guest to explore a limited amount
> +    of host physical memory. This can at least be used to gain knowledge
> +    about the host address space layout. The interrupts which have a fixed
> +    affinity to the CPUs which run the untrusted guests can depending on
> +    the scenario still trigger soft interrupts and schedule kernel threads
> +    which might expose valuable information.
> +
> +The above three mitigation methods combined can provide protection to a
> +certain degree, but the risk of the remaining attack surface has to be
> +carefully analyzed. For full protection the following methods are
> +available:
> +
> +  - 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.
> +
> +  - 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.
?

Re: [PATCH V2] Documentation: Add section about CPU vulnerabilities

[Thomas Gleixner]

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