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 <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).
> 
> 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 <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
>> 
>> 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@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 mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Reply via email to