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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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