[elrepo] kernel-ml microcode outdated (re: spectre and meltdown)
kernel-ml 3.14.11-1 and now 3.14.12-1 is still running the old CPU microcode 0x22 version from 2017-01-27 which is insecure and was recently updated to help prevent the spectre security vulnerability in Intel / x86 architecture. I forced initramfs to be regenerated but it made no difference. # uname -a Linux nas *4.14.12-1.el7.elrepo.x86_64* #1 SMP Fri Jan 5 13:28:56 EST 2018 x86_64 x86_64 x86_64 GNU/Linux ~ [0] # dmesg|grep -i micro [0.00] microcode: microcode updated early to revision *0x22, date = 2017-01-27*[0.489107] microcode: sig=0x306c3, pf=0x2, revision=0x22 [0.489551] microcode: Microcode Update Driver: v2.2. ~ [0] # rpm -qa | egrep -i 'microcode|firmware|kernel-ml'| egrep -vi 'devel|crystalhd|alsa|aic94|3.10.0|ivtv'kernel-ml-4.14.11-1.el7.elrepo.x86_64 kernel-ml-tools-libs-4.14.12-1.el7.elrepo.x86_64 kernel-ml-headers-4.14.12-1.el7.elrepo.x86_64 linux-firmware-20170606-57.gitc990aae.el7.noarch kernel-ml-tools-4.14.12-1.el7.elrepo.x86_64 kernel-ml-4.14.12-1.el7.elrepo.x86_64 microcode_ctl-2.1-22.2.el7.x86_64 -- Sam McLeod https://twitter.com/s_mcleod https://smcleod.net Words are my own opinions and do not necessarily represent those of my employer or partners. ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel-ml microcode outdated (re: spectre and meltdown)
> My hint is that you execute the following command and see from whence
> you have obtained the microcode_ctl package --
>
> rpm -q --qf "%{V}-%{R}-%{ARCH}\t%{VENDOR}\n" microcode_ctl
>
> Alan.
Thanks Alan,
Indeed microcode_ctl comes from CentOS, not elrepo, but I thought that was
simply the tool to deploy the microcode?
from yum info microcode_ctl:
Name: microcode_ctl
Arch: x86_64
Epoch : 2
Version : 2.1
Release : 22.2.el7
Size: 1.3 M
Repo: installed
>From repo : updates
Summary : Tool to transform and deploy CPU microcode update for x86.
By the way, thank you for replying with an answer in a way that helped me come
to my own conclusion that the package was from another repo, I like that kind
of reply as it helps people learn rather than just giving them an answer.
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel-ml microcode outdated (re: spectre and meltdown)
> On 8 Jan 2018, at 10:48 am, Sam McLeod wrote:
>
>> My hint is that you execute the following command and see from whence
>> you have obtained the microcode_ctl package --
>>
>> rpm -q --qf "%{V}-%{R}-%{ARCH}\t%{VENDOR}\n" microcode_ctl
>>
>> Alan.
>
> Thanks Alan,
> Indeed microcode_ctl comes from CentOS, not elrepo, but I thought that was
> simply the tool to deploy the microcode?
>
> from yum info microcode_ctl:
>
...
Answered my own question:
rpm -q --changelog microcode_ctl|head
* Fri Dec 15 2017 Petr Oros - 2.1-22.2
- Update Intel CPU microde for 06-3f-02, 06-4f-01, and 06-55-04
- Resolves: #1527358
So indeed the microcode_ctl package does contain the patches themselves...
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel-lt and kernel-ml updates for Meltdown and Spectre
On #Elrepo IRC at the moment, interesting to see my CPU + latest intel microcode download + latest elrepo kernel-ml is significantly more at-risk still: ~ [0] # uname -a Linux nas 4.14.12-1.el7.elrepo.x86_64 #1 SMP Fri Jan 5 13:28:56 EST 2018 x86_64 x86_64 x86_64 GNU/Linux ~ [0] # dmesg | grep -i micro [0.00] microcode: microcode updated early to revision 0x23, date = 2017-11-20 [0.494508] microcode: sig=0x306c3, pf=0x2, revision=0x23 [0.494918] microcode: Microcode Update Driver: v2.2. ~ [0] # ./spectre-meltdown-checker.sh Spectre and Meltdown mitigation detection tool v0.24 Checking for vulnerabilities against live running kernel Linux 4.14.12-1.el7.elrepo.x86_64 #1 SMP Fri Jan 5 13:28:56 EST 2018 x86_64 CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Checking count of LFENCE opcodes in kernel: NO (only 37 opcodes found, should be >= 70) > STATUS: VULNERABLE (heuristic to be improved when official patches become > available) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigation 1 * Hardware (CPU microcode) support for mitigation: YES * Kernel support for IBRS: NO * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * Mitigation 2 * Kernel compiled with retpoline option: NO * Kernel compiled with a retpoline-aware compiler: NO > STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline > are needed to mitigate the vulnerability) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES > STATUS: NOT VULNERABLE (PTI mitigates the vulnerability) 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 11 Jan 2018, at 7:36 am, Phil Perry wrote: > > On 10/01/18 20:06, Phil Perry wrote: >> A vulnerability checker script: >> https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh >> > > On a fully updated RHEL7 system (kernel-3.10.0-693.11.6.el7.x86_64), and > after applying the latest microcode update for my CPU from Intel: > > # ./spectre-meltdown-checker.sh > Spectre and Meltdown mitigation detection tool v0.24 > > Checking for vulnerabilities against live running kernel Linux > 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Dec 28 14:23:39 EST 2017 x86_64 > > CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' > * Checking count of LFENCE opcodes in kernel: YES (112 opcodes found, which > is >= 70) > > STATUS: NOT VULNERABLE (heuristic to be improved when official patches > > become available) > > CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' > * Mitigation 1 > * Hardware (CPU microcode) support for mitigation: YES > * Kernel support for IBRS: YES > * IBRS enabled for Kernel space: YES > * IBRS enabled for User space: NO > * Mitigation 2 > * Kernel compiled with retpoline option: NO > * Kernel compiled with a retpoline-aware compiler: NO > > STATUS: NOT VULNERABLE (IBRS mitigates the vulnerability) > > CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' > * Kernel supports Page Table Isolation (PTI): YES > * PTI enabled and active: YES > > STATUS: NOT VULNERABLE (PTI mitigates the vulnerability) > > A false sense of security is worse than no security at all, see --disclaimer > > > Before the microcode update, it was showing as vulnerable to CVE-2017-5715 > [branch target injection] aka 'Spectre Variant 2' > > > ___ > elrepo mailing list > elrepo@lists.elrepo.org > http://lists.elrepo.org/mailman/listinfo/elrepo ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] Kernel 4.12.13 RPM ETA
> On 11 Jan 2018, at 9:26 am, Akemi Yagi wrote: > > Should be released any minute now. Alan has been working so hard. Just be > patient. > > Akemi > ___ As mentioned on IRC, after installing 4.14.13-1 from elrepo my server no longer booted. Unfortunately this test server is remote and where I am today I don't have access to a console to perform debugging as to why it's failed, so it most certainly could be related to my configuration / hardware set etc... but I thought I'd make mention of it in the case others experience problems. -- Sam McLeod https://smcleod.net https://twitter.com/s_mcleod ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] Kernel 4.12.13 RPM ETA
Quick follow up to confirm as I suspected that this is a problem with grub or dracut ignoring the default kernel parameter and not related to 4.14.13-1 in any way. Unrelated but important, as mentioned in Phil’s excellent reply earlier - kernel-ml is built from the kernel.org sources and does not (currently) contain patches such as those that Redhat builds into their kernels as workarounds, partial or full fixes for meltdown or spectre. -- Sam McLeod > On 11 Jan 2018, at 10:24, Sam McLeod wrote: > > >> On 11 Jan 2018, at 9:26 am, Akemi Yagi wrote: >> >> Should be released any minute now. Alan has been working so hard. Just be >> patient. >> >> Akemi >> ___ > > As mentioned on IRC, after installing 4.14.13-1 from elrepo my server no > longer booted. > > Unfortunately this test server is remote and where I am today I don't have > access to a console to perform debugging as to why it's failed, so it most > certainly could be related to my configuration / hardware set etc... but I > thought I'd make mention of it in the case others experience problems. > > -- > Sam McLeod > https://smcleod.net > https://twitter.com/s_mcleod > ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel-lt and kernel-ml updates for Meltdown and Spectre
Thanks Phil, Oh the irony, Intel's dismissive stance of "Contact your OS vendor" which has been more than a little frustrating given it was their massive mess-up, then seeing this pushed back to "Contact your hardware vendor". Can't help but laugh (and cry) a little on the inside. -- Sam McLeod https://smcleod.net https://twitter.com/s_mcleod > On 17 Jan 2018, at 10:01 am, Phil Perry wrote: > > On 10/01/18 20:21, Phil Perry wrote: >> On 10/01/18 19:55, Phil Perry wrote: >>> I'm starting this thread as somewhere to collect latest information on >>> Meltdown and Spectre as relating to the elrepo kernel-lt and kernel-ml >>> kernels. >>> >>> Please feel free to post to this thread, ask questions and share >>> information. This is the place to do it. >>> >>> Please do not open bugs on https://elrepo.org/bugs unless you have >>> identified a bug in the elrepo packaging process. They will be closed and >>> you will be pointed here. Understand elrepo simply packages the upstream >>> kernel source code as-is for your use on RHEL. They are not our bugs! >>> >>> Thank you, >>> >>> The ELRepo Team. >>> >> Microcode updates from Intel: >> https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File >> You can download the latest mircocode update directly from Intel (above, >> check you are downloading the latest version) and apply it directly to your >> machine. >> Download and extract the above microcode tarball and extract. >> Copy the files in the intel-ucode directory to >> /usr/lib/firmware/intel-ucode/ to update the firmware files. >> The following command may be used to reload the updated firmware without >> rebooting: >> echo 1 > /sys/devices/system/cpu/microcode/reload >> Check in /var/log/messages to see if the microcode has been updated. For >> example: >> # cat /var/log/messages | grep 'microcode' >> Jan 10 20:17:00 quad kernel: microcode: CPU0 sig=0x506e3, pf=0x2, >> revision=0xba >> Jan 10 20:17:00 quad kernel: microcode: CPU0 updated to revision 0xc2, date >> = 2017-11-16 >> Jan 10 20:17:00 quad kernel: microcode: CPU1 sig=0x506e3, pf=0x2, >> revision=0xba >> Jan 10 20:17:00 quad kernel: microcode: CPU1 updated to revision 0xc2, date >> = 2017-11-16 >> Jan 10 20:17:00 quad kernel: microcode: CPU2 sig=0x506e3, pf=0x2, >> revision=0xba >> Jan 10 20:17:00 quad kernel: microcode: CPU2 updated to revision 0xc2, date >> = 2017-11-16 >> Jan 10 20:17:00 quad kernel: microcode: CPU3 sig=0x506e3, pf=0x2, >> revision=0xba >> Jan 10 20:17:00 quad kernel: microcode: CPU3 updated to revision 0xc2, date >> = 2017-11-16 >> Note that updating of the microcode_ctl package may overwrite the microcode >> firmware files so check a package update doesn't revert to older firmware. > > Red Hat have just released an updated microcode_ctl package that reverts to > older versions of the microcode due to instabilities in the latest versions > that was preventing some systems from booting. > > https://access.redhat.com/errata/RHSA-2018:0093 > > https://access.redhat.com/solutions/3315431 > > Red Hat are not providing providing microcode to address Spectre, variant 2, > due to instabilities introduced that are causing customer systems to not > boot, and are recommending customers contact their hardware vendors directly > for microcode/BIOS updates for their CPU. > > ___ > elrepo mailing list > elrepo@lists.elrepo.org > http://lists.elrepo.org/mailman/listinfo/elrepo ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
[elrepo] Kernel 4.15 Released
http://lkml.iu.edu/hypermail/linux/kernel/1801.3/02794.html <http://lkml.iu.edu/hypermail/linux/kernel/1801.3/02794.html> Will certainly be interesting to see the state of meltdown after kernel-ml packages are built and installed. Also as Linus states: "You can do cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 and if you don't have a compiler that supports the retpoline mitigations, you'll get: Vulnerable: Minimal generic ASM retpoline because only the assembly code (not the C code) will have the retpoline mitigation. So keep that in mind." -- 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. ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] Announcement: EL7 New kernel-ml Release [4.15.0-1]
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 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 alongsi
Re: [elrepo] Announcement: EL7 New kernel-ml Release [4.15.0-1]
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 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 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
Re: [elrepo] Announcement: EL7 New kernel-ml Release [4.15.0-1]
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. -- Sam McLeod https://smcleod.net https://twitter.com/s_mcleod > On 31 Jan 2018, at 12:22 am, Trevor Hemsley 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 > <mailto:mailingli...@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' >>>
Re: [elrepo] Announcement: EL7 New kernel-ml Release [4.15.0-1]
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 wrote: > > On 31 Jan. 2018 10:35 am, "Sam McLeod" <mailto:mailingli...@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 > <mailto:thems...@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 >> <mailto:mailingli...@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 >>>> * CP
Re: [elrepo] Kernel packages update cadence
Pedro, As Phil says, the kernels are provided 'as-is', but I'd like to give you a quick sample of how we've found it in production. We run anywhere between 250-2000 CentOS 7 VMs each year. We have been using elrepo kernel-ml on both our VMs and our physical SANs / storage servers and our physical backup servers for the past 3~ years. We install the latest kernel-ml package as soon as it's available (we automate everything, the kernel package is ensured that it is the latest available every 20 minutes~). In those 3~ years we have had (from memory) two problems: 1. Only affected our storage servers, it was some odd kernel bug that caused some DRBD issues, when we noticed a pattern we just booted into the previous kernel and the bug was fixed (upstream, in the kernel itself) about 5 releases later (it wasn't very well reported to the kernel devel team or it would have been quicker, at any rate - nothing to do with elrepo or kernel-ml). 2. A problem that may have affected intel 7xx series NICs that was again an upstream kernel bug, saw the problem straight after rebooting into the new kernel, rebooted into the last kernel - it was fine, left it for a couple of days until the next build was out - tried it and it was fine. Other than that - kernel-ml has do nothing but provide us with much better performance and new features (we use a lot of 'newish' things like NVMe, containers before they were cool, new hardware, self design software defined storage / SANs etc). For me and my engineering team it's an absolute no-brainer to use kernel-ml and there's no way we'd be seen dead running the stock centos 3.x kernels to be honest. note: we don't use any weird 'black box' oracle / ibm or the likes hardware that require special kernel drivers to be installed etc... but I haven't seen people do that much on x86 these days anyway. -- Sam McLeod https://smcleod.net https://twitter.com/s_mcleod > On 11 Jul 2018, at 08:39, Phil Perry wrote: > > On 10/07/18 18:57, Pedro Flores wrote: >> We recently started using ELRepo’s kernel repositories in a subset of our >> production infrastructure to deal with some issues we were experiencing with >> CentOS 7.5 latest kernels. Our security team has some concerns about how >> quickly ElRepo releases new kernel packages that address either major bug >> fixes or CVE exploits after the kernels containing these updates have been >> released by the Linux Kernel Main archives.Is there a certain amount of >> time that we should expect new kernels to make it to ELREpo yum repositories >> after they have been released by the Linux Kernel Archives folks? >> Thanks in advance. >> *--* >> ** >> *Pedro Flores* > > Hi Pedro, > > Did you read the release announcement(s)? The relevant part to your question > is here: > > > These packages are provided "As-Is" with no implied warranty or > support. Using the kernel-lt/-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. > > > Your security team are free to review our previous performance to get an > indication for how quickly kernel packages are typically released, but past > performance should not be taken as a guarantee for future release time scales. > > If you have issues with the EL7.5 kernel in a production environment and do > not have the expertise to fix it in house, I would highly recommend you > purchase RHEL subscriptions and raise a support case directly with Red Hat to > have your issues resolved. As stated in our release announcement(s), our > kernel packages are not intended for production use. Elrepo is a voluntary > project and Alan handles all kernel builds single-handedly on donated limited > build hardware. As such, we are unable to offer you any guaranteed level of > service, hence my recommendation to purchase RHEL subscriptions if that is > what you require. > > Hope that helps, > > Phil > > ___ > elrepo mailing list > elrepo@lists.elrepo.org > http://lists.elrepo.org/mailman/listinfo/elrepo ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
