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

[Trevor Hemsley]

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

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

[Sam McLeod]

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"  > 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 > > 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 >> > 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
 * 

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

[Sam McLeod]

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://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 

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

[Lachlan Musicman]

On 31 Jan. 2018 10:35 am, "Sam McLeod"  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  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  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