[pve-devel] [PATCH pve-docs] improve spectre/meltdown cpu flags documentation

Wolfgang Bumiller w.bumiller at proxmox.com
Tue Aug 28 13:09:12 CEST 2018


On Mon, Aug 20, 2018 at 08:02:51PM +0200, Alexandre Derumier wrote:
> -add new cpuflags for spectre v4.
> -split cpuflags between amd && intel processors
> ---
>  qm.adoc | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++--------------
>  1 file changed, 86 insertions(+), 23 deletions(-)
> 
> diff --git a/qm.adoc b/qm.adoc
> index 28d2a38..32e4fa6 100644
> --- a/qm.adoc
> +++ b/qm.adoc
> @@ -307,56 +307,119 @@ theory this will give your guests maximum performance.
>  Meltdown / Spectre related CPU flags
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  
> -There are two CPU flags related to the Meltdown and Spectre vulnerabilities
> +There are CPU flags related to the Meltdown and Spectre vulnerabilities

Maybe add 'several'?

>  footnote:[Meltdown Attack https://meltdownattack.com/] which need to be set
>  manually unless the selected CPU type of your VM already enables them by default.
>  
> -The first, called 'pcid', helps to reduce the performance impact of the Meltdown
> -mitigation called 'Kernel Page-Table Isolation (KPTI)', which effectively hides
> -the Kernel memory from the user space. Without PCID, KPTI is quite an expensive
> -mechanism footnote:[PCID is now a critical performance/security feature on x86
> -https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU].
> -
> -The second CPU flag is called 'spec-ctrl', which allows an operating system to
> -selectively disable or restrict speculative execution in order to limit the
> -ability of attackers to exploit the Spectre vulnerability.
> -
> -There are two requirements that need to be fulfilled in order to use these two
> +There are two requirements that need to be fulfilled in order to use these
>  CPU flags:
>  
>  * The host CPU(s) must support the feature and propagate it to the guest's virtual CPU(s)
>  * The guest operating system must be updated to a version which mitigates the
>    attacks and is able to utilize the CPU feature
>  
> -In order to use 'spec-ctrl', your CPU or system vendor also needs to provide a
> +Otherwise you need to set the desired CPU flag of the virtual CPU, either by
> +editing the CPU options in the WebUI, or by setting the 'flags' property of the
> +'cpu' option in the VM configuration file.
> +
> +For Spectre v1,v2,v4 fixes, your CPU or system vendor also needs to provide a
>  so-called ``microcode update'' footnote:[You can use `intel-microcode' /
>  `amd-microcode' from Debian non-free if your vendor does not provide such an
>  update. Note that not all affected CPUs can be updated to support spec-ctrl.]
>  for your CPU.
>  
> -To check if the {pve} host supports PCID, execute the following command as root:
>  
> +Intel processors
> +^^^^^^^^^^^^^^^^
> +
> +* 'pcid'
> ++
> +helps to reduce the performance impact of the Meltdown (CVE-2017-5754) mitigation 

With the new formatting this should probably be a separate sentence?

   'This reduces the performance impact ...'

> +called 'Kernel Page-Table Isolation (KPTI)', which effectively hides
> +the Kernel memory from the user space. Without PCID, KPTI is quite an expensive
> +mechanism footnote:[PCID is now a critical performance/security feature on x86
> +https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU].
> ++
> +To check if the {pve} host supports PCID, execute the following command as root:
> ++
>  ----
>  # grep ' pcid ' /proc/cpuinfo
>  ----
> -
> ++
>  If this does not return empty your host's CPU has support for 'pcid'.
>  
> +* 'spec-ctrl'
> ++
> +Required to enable the Spectre v1 (CVE-2017-5753) and Spectre v2 (CVE-2017-5715) fix, 
> +in cases where retpolines are not sufficient. 
> +Included by default in Intel CPU models with -IBRS suffix. 
> +Must be explicitly turned on for Intel CPU models without -IBRS suffix. 
> +Requires the host CPU microcode (intel-microcode >= 20180425).
> ++
>  To check if the {pve} host supports spec-ctrl, execute the following command as root:
> ++
> +----
> +# grep ' spectre_v1 ' /proc/cpuinfo
> +# grep ' spectre_v2 ' /proc/cpuinfo

These are in the 'bugs' line, not the 'flags' line. We can have the bug
without the fix AFAIK. Why not grep for spec_ctrl as we did previously?

> +----
> ++
> +If this does not return empty your host's CPU has support for 'spec-ctrl'.
> +
>  
> +* 'ssbd'
> ++
> +Required to enable the Spectre V4 (CVE-2018-3639) fix. Not included by default in any Intel CPU model. 
> +Must be explicitly turned on for all Intel CPU models. 
> +Requires the host CPU microcode(intel-microcode >= 20180703).
> ++
> +To check if the {pve} host supports spec-ctrl, execute the following command as root:

s/spec-ctrl/ssbd/

> ++
>  ----
> -# grep ' spec_ctrl ' /proc/cpuinfo
> +# grep ' spec_store_bypass ' /proc/cpuinfo

Again: why check for the bug when we're looking for the fix?

>  ----
> ++
> +If this does not return empty your host's CPU has support for 'ssbd'.
>  
> -If this does not return empty your host's CPU has support for 'spec-ctrl'.
>  
> -If you use `host' or another CPU type which enables the desired flags by
> -default, and you updated your guest OS to make use of the associated CPU
> -features, you're already set.
> +AMD processors
> +^^^^^^^^^^^^^^
> +

All these could also include the /proc/cpuinfo grep check I suppose.
Maybe we can unify them, though? After all, they should all work the
same way?

> +* 'ibpb'
> ++
> +Required to enable the Spectre v1 (CVE-2017-5753) and Spectre v2 (CVE-2017-5715) fix, 
> +in cases where retpolines are not sufficient. 
> +Included by default in AMD CPU models with -IBPB suffix. 
> +Must be explicitly turned on for AMD CPU models without -IBPB suffix. 
> +Requires the host CPU microcode to support this feature before it can be used for guest CPUs.
> +
> +
> +
> +* 'virt-ssbd'
> ++
> +Required to enable the Spectre v4 (CVE-2018-3639) fix.
> +Not included by default in any AMD CPU model. 
> +Must be explicitly turned on for all AMD CPU models. 
> +This should be provided to guests, even if amd-ssbd is also provided, for maximum guest compatibility. 
> +Note for some QEMU / libvirt versions, this must be force enabled when when using "Host model", 
> +because this is a virtual feature that doesn’t exist in the physical host CPUs.
> +
> +
> +* 'amd-ssbd'
> ++
> +Required to enable the Spectre v4 (CVE-2018-3639) fix. 
> +Not included by default in any AMD CPU model. Must be explicitly turned on for all AMD CPU models. 
> +This provides higher performance than virt-ssbd so should be exposed to guests whenever available in the host. 
> +virt-ssbd should none the less also be exposed for maximum guest compatibility as some kernels only know about virt-ssbd.
> +
> +
> +* 'amd-no-ssb'
> ++
> +Recommended to indicate the host is not vulnerable to Spectre V4 (CVE-2018-3639).
> +Not included by default in any AMD CPU model. 
> +Future hardware generations of CPU will not be vulnerable to CVE-2018-3639, 
> +and thus the guest should be told not to enable its mitigations, by exposing amd-no-ssb. 
> +This is mutually exclusive with virt-ssbd and amd-ssbd.
>  
> -Otherwise you need to set the desired CPU flag of the virtual CPU, either by
> -editing the CPU options in the WebUI, or by setting the 'flags' property of the
> -'cpu' option in the VM configuration file.
>  
>  NUMA
>  ^^^^
> -- 
> 2.11.0




More information about the pve-devel mailing list