[elrepo] Announcement: EL7 New kernel-ml Release [4.15.0-1]

[Sam McLeod]

For those wondering about the status of Spectre and Meltdown on kernel-ml 4.15, below is the output of the speed47 test (https://github.com/speed47/spectre-meltdown-checker <https://github.com/speed47/spectre-meltdown-checker>).

I've found this to be consistent between CentOS 7 VMs (PVHVM) on XenServer 7.2 w/ E5-2660 CPUs and physical servers using older X5650 CPUs.

So it looks like at present we're still vulnerable to Spectre Variant 1 and 2 with Kernel 4.15, obviously resolving this in full will require a working microcode update from Intel.


# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.33+

Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-1.el7.elrepo.x86_64 #1 SMP Sun Jan 28 20:45:20 EST 2018 x86_64
CPU is Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  NO
    * CPU indicates IBRS capability:  NO
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  NO
    * CPU indicates IBPB capability:  NO
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  NO
    * CPU indicates STIBP capability:  NO
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  NO
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO
  * CPU microcode is known to cause stability problems:  NO
* CPU vulnerability to the three speculative execution attacks variants
  * Vulnerable to Variant 1:  YES
  * Vulnerable to Variant 2:  YES
  * Vulnerable to Variant 3:  YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
> STATUS:  VULNERABLE  (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
* Mitigation 1
  * Kernel is compiled with IBRS/IBPB support:  NO
  * Currently enabled features
    * IBRS enabled for Kernel space:  NO
    * IBRS enabled for User space:  NO
    * IBPB enabled:  NO
* Mitigation 2
  * Kernel compiled with retpoline option:  YES
  * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports minimal retpoline compilation)
  * Retpoline enabled:  YES
> STATUS:  VULNERABLE  (Vulnerable: Minimal generic ASM retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  YES
* Running as a Xen PV DomU:  NO
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

A false sense of security is worse than no security at all, see --disclaimer

--
Sam McLeod
https://smcleod.net
https://twitter.com/s_mcleod

> On 30 Jan 2018, at 5:20 am, Alan Bartlett <ajb at elrepo.org> wrote:
> 
> Announcing the release of the kernel-ml-4.15.0-1.el7.elrepo package
> set into the EL7 elrepo-kernel repository:
> 
> https://elrepo.org/tiki/kernel-ml
> 
> The following files are currently synchronising to our mirror sites:
> 
> x86_64
> kernel-ml-4.15.0-1.el7.elrepo.x86_64.rpm
> kernel-ml-devel-4.15.0-1.el7.elrepo.x86_64.rpm
> kernel-ml-doc-4.15.0-1.el7.elrepo.noarch.rpm
> kernel-ml-headers-4.15.0-1.el7.elrepo.x86_64.rpm
> kernel-ml-tools-4.15.0-1.el7.elrepo.x86_64.rpm
> kernel-ml-tools-libs-4.15.0-1.el7.elrepo.x86_64.rpm
> kernel-ml-tools-libs-devel-4.15.0-1.el7.elrepo.x86_64.rpm
> perf-4.15.0-1.el7.elrepo.x86_64.rpm
> python-perf-4.15.0-1.el7.elrepo.x86_64.rpm
> 
> nosrc
> kernel-ml-4.15.0-1.el7.elrepo.nosrc.rpm
> 
> We provide these kernels for hardware testing in an effort to identify
> new/updated drivers which can then be targeted for backporting as kmod
> packages. Meanwhile, these kernels may provide interim relief to
> people with non-functional hardware. We stress that we consider such
> kernels as a last resort for those who are unable to get their
> hardware working using the RHEL-7 kernel with supplementary kmod
> packages.
> 
> These packages are provided "As-Is" with no implied warranty or
> support. Using the kernel-ml may expose your system to security,
> performance and/or data corruption issues. Since timely updates may
> not be available from the ELRepo Project, the end user has the
> ultimate responsibility for deciding whether to continue using the
> kernel-ml packages in regular service.
> 
> The packages are intentionally named kernel-ml so as not to conflict
> with the RHEL-7 kernels and, as such, they may be installed and
> updated alongside the regular kernel. The kernel configuration is
> based upon a default RHEL-7 configuration with added functionality
> enabled as appropriate.
> 
> If a bug is found when using these kernels, the end user is encouraged
> to report it upstream to the Linux Kernel Bug Tracker [1] and, for our
> reference, to the ELRepo bug tracker [2]. By taking such action, the
> reporter will be assisting the kernel developers, Red Hat and the Open
> Source Community as a whole.
> 
> Thank you,
> 
> The ELRepo Team.
> 
> [1] https://bugzilla.kernel.org/
> [2] https://elrepo.org/bugs/
> _______________________________________________
> elrepo mailing list
> elrepo at lists.elrepo.org
> http://lists.elrepo.org/mailman/listinfo/elrepo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elrepo.org/pipermail/elrepo/attachments/20180130/fcc7e1af/attachment-0001.html>