[elrepo] Announcement: EL7 New kernel-ml Release [4.15.0-1]
Sam McLeod
mailinglists at smcleod.net
Tue Jan 30 18:56:48 EST 2018
Thanks Lachlan,
So the key to having IBRS/IBPB is a retpolite aware compiler...
>> * Kernel compiled with a retpoline-aware compiler: NO (kernel reports minimal retpoline compilation)
What a mess this whole thing is (preaching to the choir I'm sure) - it's turned my head inside out more than once.
Thanks again for the clarification.
--
Sam McLeod (protoporpoise on IRC)
https://smcleod.net
https://twitter.com/s_mcleod
Words are my own opinions and do not necessarily represent those of my employer or partners.
> On 31 Jan 2018, at 10:47 am, Lachlan Musicman <datakid at gmail.com> wrote:
>
> On 31 Jan. 2018 10:35 am, "Sam McLeod" <mailinglists at smcleod.net <mailto: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 <https://support.google.com/faqs/answer/7625886>
>
> Cheers
> L.
>
>
>
>
>
>
> --
> Sam McLeod
> https://smcleod.net <https://smcleod.net/>
> https://twitter.com/s_mcleod <https://twitter.com/s_mcleod>
>
>> On 31 Jan 2018, at 12:22 am, Trevor Hemsley <themsley at voiceflex.com <mailto: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://smcleod.net/>
>>> https://twitter.com/s_mcleod <https://twitter.com/s_mcleod>
>>>
>>>
>>> On 30 Jan 2018, at 10:09 am, Sam McLeod <mailinglists at smcleod.net <mailto: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 <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://smcleod.net/>
>>>> https://twitter.com/s_mcleod <https://twitter.com/s_mcleod>
>>>>
>>>>> On 30 Jan 2018, at 5:20 am, Alan Bartlett <ajb at elrepo.org <mailto: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 <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/ <https://bugzilla.kernel.org/>
>>>>> [2] https://elrepo.org/bugs/ <https://elrepo.org/bugs/>
>>>>> _______________________________________________
>>>>> elrepo mailing list
>>>>> elrepo at lists.elrepo.org <mailto:elrepo at lists.elrepo.org>
>>>>> http://lists.elrepo.org/mailman/listinfo/elrepo <http://lists.elrepo.org/mailman/listinfo/elrepo>
>>>>
>>>> _______________________________________________
>>>> elrepo mailing list
>>>> elrepo at lists.elrepo.org <mailto:elrepo at lists.elrepo.org>
>>>> http://lists.elrepo.org/mailman/listinfo/elrepo <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 <http://www.symanteccloud.com/>
>>> ______________________________________________________________________
>>>
>>>
>>> _______________________________________________
>>> elrepo mailing list
>>> elrepo at lists.elrepo.org <mailto:elrepo at lists.elrepo.org>
>>> http://lists.elrepo.org/mailman/listinfo/elrepo <http://lists.elrepo.org/mailman/listinfo/elrepo>
>>
>
>
> _______________________________________________
> elrepo mailing list
> elrepo at lists.elrepo.org <mailto:elrepo at lists.elrepo.org>
> http://lists.elrepo.org/mailman/listinfo/elrepo <http://lists.elrepo.org/mailman/listinfo/elrepo>
>
>
> _______________________________________________
> elrepo mailing list
> elrepo at lists.elrepo.org <mailto:elrepo at lists.elrepo.org>
> http://lists.elrepo.org/mailman/listinfo/elrepo <http://lists.elrepo.org/mailman/listinfo/elrepo>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elrepo.org/pipermail/elrepo/attachments/20180131/dc1d61aa/attachment-0001.html>
More information about the elrepo
mailing list