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

Lachlan Musicman datakid at gmail.com
Tue Jan 30 18:47:14 EST 2018 

On 31 Jan. 2018 10:35 am, "Sam McLeod" <mailinglists at smcleod.net> wrote:

Hi Trevor,

I didn't think that to compile a kernel with IBRS/IBPB your *compiler* had
to be updated as well?
I thought that was a seperate issue but perhaps I'm mistaken.


Yes, it does require a newer compiler...you can see the details of why here:

https://support.google.com/faqs/answer/7625886

Cheers
L.






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

On 31 Jan 2018, at 12:22 am, Trevor Hemsley <themsley at voiceflex.com> wrote:

Sam

I'm not ELRepo but I don't think they can do that until/unless RH fix the
compilers in the distro to be retpoline aware. If they do.

And, in any case, Intel have pretty much said "don't use the new microcode"
so there is no working microcode available that the kernel can use anyway.
All the vendors have pulled their BIOS updates and backed out e.g. the
microcode_ctl updates.

Trevor

On 30/01/18 08:42, Sam McLeod wrote:

Are there any plans to enable IBRS/IBPB in the kernel-ml kernels?

While I understand the desire to keep the builds as ‘stock’ as possible,
given the potential impact of the this I’d consider it a worth enabling
unless I’m misunderstanding the situation?

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


On 30 Jan 2018, at 10:09 am, Sam McLeod <mailinglists at smcleod.net> wrote:

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

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


_______________________________________________
elrepo mailing list
elrepo at lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


_______________________________________________
elrepo mailing listelrepo at lists.elrepo.orghttp://lists.elrepo.org/mailman/listinfo/elrepo




_______________________________________________
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/20180131/ee74b3ff/attachment-0001.html>

More information about the elrepo mailing list