[CentOS-virt] Speculative attack mitigations

Wed Jun 12 08:09:34 UTC 2019
Jonathan Archdale - Blacknight <jonathan.archdale at blacknight.com>

Hi folks,


Firstly; apologies in advance for what is a head wrecker of keeping on top of the speculative mitigations and also if this is a duplicate email; my first copy didn't seem to make it into the archive.  Also a disclaimer that I may have misunderstood elements of the below but please bear with me.


I write this hoping to find out a bit more about the state of the relevant kernel patches for the various speculative attack mitigations in the current 4.9.177-35 kernel used in the centos-virt tree.


For reference; I am running a Dell R620, using an E5-2620 v2 CPU, using 4.9.177-35 from the xen-410 tree in the EL6 branch ; though I am still using xen 4.6 at this time.  I have been told in the irc channel that the kernel is not built against a specific version of xen so this should make no odds.


As per https://www.dell.com/support/home/ie/en/iebsdt1/drivers/driversdetails?driverId=NGYCX - bios version 2.70 (installed) contains mitigations for CVE-2018-3639 (variant 3a route system register read) and CVE-2018-3640 (variant 4, speculative store bypass).  I am also running the latest available intel microcode for the CPU; as imported via 'module /GenuineIntel.bin' and 'ucode=2' in my grub.conf to import (as taken from https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files).


# uname -r
4.9.177-35.el6.x86_64

# cat /proc/cmdline
ro root=UUID=0e51d8dc-6409-4715-83f4-f86fa24083e2 rd_NO_LUKS  KEYBOARDTYPE=pc KEYTABLE=uk LANG=en_US.UTF-8 rd_NO_MD nodmraid SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_NO_LVM rd_NO_DM rhgb quiet intel_idle.max_cstate=0 processor.max_cstate=0 l1ft=full mds=full,nosmt ssbd=force-on

# grep -e flags -e "model name" -e microcode -e bugs /proc/cpuinfo | sort -u
model name      : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
microcode       : 0x42e
flags : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc arch_perfmon rep_good nopl nonstop_tsc pni pclmulqdq monitor est ssse3 cx16 sse4_1 sse4_2 popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm fsgsbase erms xsaveopt dtherm ida arat pln pts
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds

You will note that there is a lack of flags for ssbd, spec_ctrl, intel_stibp, flush_l1d, ibrs, etc.

# for i in /sys/devices/system/cpu/vulnerabilities/* ; do echo -n "$i : "; cat $i ; done
/sys/devices/system/cpu/vulnerabilities/l1tf : Mitigation: PTE Inversion
/sys/devices/system/cpu/vulnerabilities/mds : Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
/sys/devices/system/cpu/vulnerabilities/meltdown : Vulnerable
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass : Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1 : Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2 : Mitigation: Full generic retpoline, STIBP: disabled, RSB filling

Despite having relevant microcode, I am still seeing the box as showing vulnerable to meltdown, speculative store bypass (ssbd), as well as MDS via MD_CLEAR mitigation.

When I mount the debugfs, the flag for ibrs is missing - preventing me enabling it as a mitigation for ssbd (due to lack of relevant cpu flag):

# mount -t debugfs none /sys/kernel/debug/


# ls -lahtr /sys/kernel/debug/x86/ibrs_enabled
ls: cannot access /sys/kernel/debug/x86/ibrs_enabled: No such file or directory


I have other R620's with the same CPUs running stock el6 kernels that are showing as fully patched to these issues.   Could I please get some feedback from whoever builds out the kernels; if the mitigations/patches are in place in the 4.9.177-35 kernel for the various speculative mitigations?

Specifically; CVE-2018-3639, CVE-2018-3640, CVE-2018-3646, CVE-2018-12126, CVE-2018-12130, CVE-2018-12127 and CVE-2019-11091.


Many thanks for your response.


Regards,

Jonathan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20190612/d8c2c1b3/attachment-0003.html>