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

2018-02-04 Thread Phil Perry 

On 04/02/18 21:15, David Ranch wrote:


Hello Everyone,

I have a question about this statement:


Kernel-ml has the retpoline patches but at present RHEL does not have 
a retpoline-aware compiler. The upstream kernel code (kernel.org) does 
not currently contain the IBRS patches that Red Hat have incorporated 
into the distro kernel.


Once a retpoline enabled compiler is available, will ONLY the kernel 
need to be rebuilt with it or will *ALL* packages need to be recompiled 
as well (from the Centos community, 3rd party packages, etc)?




You would need to address that question to the providers of those 
packages, but I have not seen any mention of anything other than 
recompiling the kernel.


I note SUSE have recently announced they have backported retpoline 
patches to gcc-4.8 which is of the same vintage as that used in RHEL7, 
so it appears feasible if that is a path Red Hat wish to take:


https://news.opensuse.org/2018/01/26/opensuse-meltdown-spectre-update-26-jan-2018/

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

2018-02-04 Thread David Ranch 


Hello Everyone,

I have a question about this statement:


Kernel-ml has the retpoline patches but at present RHEL does not have 
a retpoline-aware compiler. The upstream kernel code (kernel.org) does 
not currently contain the IBRS patches that Red Hat have incorporated 
into the distro kernel.


Once a retpoline enabled compiler is available, will ONLY the kernel 
need to be rebuilt with it or will *ALL* packages need to be recompiled 
as well (from the Centos community, 3rd party packages, etc)?


--David
___
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]

2018-01-31 Thread Phil Perry 

On 30/01/18 23:47, 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.



No, not to my understanding. IBRS and retpoline are 2 separate ways of 
mitigating Spectre Variant 2. They are not linked or related.


The IBRS method is dependant upon kernel patches AND updated hardware 
microcode.


The retpoline method is dependant upon kernel patches AND an 
updated/patched compiler.


At present, the distro kernel has the IBRS patches backported to it by 
Red Hat so is dependant upon the availability of updated hardware 
microcode to be effective (which Intel recently pulled)


Kernel-ml has the retpoline patches but at present RHEL does not have a 
retpoline-aware compiler. The upstream kernel code (kernel.org) does not 
currently contain the IBRS patches that Red Hat have incorporated into 
the distro kernel.


Hence at present there is no viable mitigation available for Spectre 
Variant 2 for most users, regardless of whether you are running the 
distro kernel or kernel-ml.


Hope that helps.

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

2018-01-30 Thread 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]

2018-01-30 Thread 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

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

2018-01-30 Thread 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]

2018-01-30 Thread 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]

2018-01-29 Thread Sam McLeod 
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 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