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 <data...@gmail.com> wrote: > > On 31 Jan. 2018 10:35 am, "Sam McLeod" <mailingli...@smcleod.net > <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 <thems...@voiceflex.com >> <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 <mailingli...@smcleod.net >>> <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' >>>> * 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 <a...@elrepo.org >>>>> <mailto:a...@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@lists.elrepo.org <mailto:elrepo@lists.elrepo.org> >>>>> http://lists.elrepo.org/mailman/listinfo/elrepo >>>>> <http://lists.elrepo.org/mailman/listinfo/elrepo> >>>> >>>> _______________________________________________ >>>> elrepo mailing list >>>> elrepo@lists.elrepo.org <mailto:elrepo@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@lists.elrepo.org <mailto:elrepo@lists.elrepo.org> >>> http://lists.elrepo.org/mailman/listinfo/elrepo >>> <http://lists.elrepo.org/mailman/listinfo/elrepo> >> > > > _______________________________________________ > elrepo mailing list > elrepo@lists.elrepo.org <mailto:elrepo@lists.elrepo.org> > http://lists.elrepo.org/mailman/listinfo/elrepo > <http://lists.elrepo.org/mailman/listinfo/elrepo> > > > _______________________________________________ > elrepo mailing list > elrepo@lists.elrepo.org <mailto:elrepo@lists.elrepo.org> > http://lists.elrepo.org/mailman/listinfo/elrepo > <http://lists.elrepo.org/mailman/listinfo/elrepo>
_______________________________________________ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
