The Latest Kernel Release.

cwizardone · 08-12-2018, 07:35 PM

I have just installed the dusk-4.18.0 kernel and, so far

, it is running perfectly with -current and the Nvidia-390.77 driver.

The dusk-4.18.0 kernel is available at,
https://dusk.idlemoor.tk/

mralk3 · 08-12-2018, 09:12 PM

Quote:

Originally Posted by smaclennan

IIRC you need a microcode update that allows you to disable the speculative store bypass. However, there is a noticeable performance penalty to doing this.

The performance impact depends on how you use your machine.

Benchmarks:

https://www.phoronix.com/scan.php?pa...tre-ssbd&num=1

smaclennan · 08-13-2018, 10:13 AM

Quote:

Originally Posted by mralk3

The performance impact depends on how you use your machine.

Benchmarks:

https://www.phoronix.com/scan.php?pa...tre-ssbd&num=1

Thanks. Those results are much better than initial reports.

nobodino · 08-15-2018, 11:23 AM

What will be the next LTS kernel?
v 4.18.1 is out with the first mitigation for LT1F. One out of thee 3 CVE's : CVE-2018-3620

cwizardone · 08-15-2018, 12:44 PM

Kernel updates 4.18.1, 4.17.15, 4.14.63, 4.9.120 and 4.4.148 are now available at, https://www.kernel.org/

The change logs,

https://cdn.kernel.org/pub/linux/ker...angeLog-4.18.1

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.17.15

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.14.63

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.9.120

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.148

The dusk-4.18.1, 4.17.15 and 4.4.148 kernel updates are available at,
https://dusk.idlemoor.tk/

AlleyTrotter · 08-15-2018, 03:59 PM

Quote:

Originally Posted by nobodino

What will be the next LTS kernel?
v 4.18.1 is out with the first mitigation for LT1F. One out of thee 3 CVE's : CVE-2018-3620

I would guess 4.19 or 5.0

kjhambrick · 08-15-2018, 06:11 PM

All --

Compiled and installed 4.4.148 on Slackware64 14.2 + MultiLib.

I've got the 'Page Table Inversion' mitigation for the l1tf vulnerability with the 4.4.148 kernel.

-- kjh

Code:

# uname -a ; get-spectre-meltdown.sh

Linux kjhlt6 4.4.148.kjh #1 SMP Wed Aug 15 16:18:57 CDT 2018 x86_64 Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz GenuineIntel GNU/Linux

l1tf:                Mitigation: Page Table Inversion
meltdown:            Mitigation: PTI
spec_store_bypass:   Mitigation: Speculative Store Bypass disabled via prctl and seccomp
spectre_v1:          Mitigation: __user pointer sanitization
spectre_v2:          Mitigation: Full generic retpoline, IBPB, IBRS_FW

This is my latest get-spectre-meltdown.sh script:

Code:

#!/bin/sh

gawk '
BEGIN {

   Fmt = "%-20s %s\n"

}
# main
{
   N = split( FILENAME, A, "/" )
   F = $0

 # gsub( /:/, " = ", F )

   printf( Fmt, A[N] ":", F )

}' /sys/devices/system/cpu/vulnerabilities/*

abga · 08-15-2018, 07:20 PM

Quote:

Originally Posted by kjhambrick

All --

Compiled and installed 4.4.148 on Slackware64 14.2 + MultiLib.

I've got the 'Page Table Inversion' mitigation for the l1tf vulnerability with the 4.4.148 kernel.

-- kjh

Can you please check if you have anything related to the l1tf (&co) in the kernel log (dmesg). Maybe you remember our recent discussion about the CVE-2018-3639 (SSB) and the need for a capable microcode for full mitigation. If I understood it correctly, mitigating CVE-2018-3615, CVE-2018-3620, CVE-2018-3646 also require an updated microcode, not sure if the (latest) Q2 2018 microcode updates, that are mentioned on some web pages as required, contain what is actually needed for the mitigation.
I'm also not sure what CPUs are actually affected, Intel apparently doesn't know that either:
(bottom list - The following Intel-based platforms are potentially impacted by these issues. Intel may modify this list at a later time.)
https://www.intel.com/content/www/us...-sa-00161.html
In my original post in the Slackware security thread I mentioned that these bugs came with the introduction of the Intel SGX technology in 2015 and considered that due to the architectural changes only the CPUs manufactured after that were vulnerable. Also understood that CVE-2018-3620, CVE-2018-3646 were discovered by investigating the bugs related to Intel SGX, first reported in March. I edited that post twice, because I wanted to keep it clear and unbiased by my understanding/confusion. But maybe we should have a separated thread about this issue without polluting this kernel related thread - however, a dmesg output can provide some details here.
Thanks!

abga · 08-15-2018, 09:44 PM

@kjhambrick

RedHat published some details about these vulnerabilities (CVE-2018-3615, CVE-2018-3620, CVE-2018-3646) and are stating, without mentioning the exact CVE - sloppy work, that only CVE-2018-3615 - the one related solely for Intel SGX - needs a microcode update:
https://access.redhat.com/security/vulnerabilities/L1TF
"There are three pieces to this vulnerability. The first affects only Intel “SGX” secure enclaves and is mitigated through microcode updates independently of the operating system. "
and:
"CVE-2018-3620 is the CVE identifier assigned to the operating system vulnerability for this issue. CVE-2018-3646 is the CVE identifier assigned to the virtualization aspect of the flaw. This issue is referred to as L1 Terminal Fault (L1TF) by the larger industry and as “Foreshadow” by the security researcher."
Which reads that only CVE-2018-3620 needs to be mitigated by the kernel, CVE-2018-3646 being only the "virtualization aspect of the flaw".
Unless someone else comes with a better understanding about the "pieces" (of sh...?), or Intel publishes some more concrete details and the CPUs actually affected, I take this RedHat view of the facts as satisfactory ATM.
Please disconsider my request for the dmesg related output, carry on with the good work on compiling and testing the kernels.

twy · 08-15-2018, 10:47 PM

I suppose I can update my report, since it was useful to a few users...

I'm running an Intel "Lynnfield" Xeon x3450 CPU released in 2009. I have installed the latest ucode 0xa (microcode-20180807 SBo, from slackbuilds.org). Now, with the latest 4.4.148 kernel on slackware64-14.2, I get the following mitigations:

for FNAME in $( ls /sys/devices/system/cpu/vulnerabilities/* )
do
echo -e $( basename $FNAME ):"\t" $( cat $FNAME )
done

l1tf: Mitigation: Page Table Inversion
meltdown: Mitigation: PTI
spec_store_bypass: Mitigation: Speculative Store Bypass disabled
spectre_v1: Mitigation: __user pointer sanitization
spectre_v2: Mitigation: Full generic retpoline, IBPB, IBRS_FW

Note that, I use the kernel parameter spec_store_bypass_disable=on in lilo:
addappend = " spec_store_bypass_disable=on "
This makes all processes/threads "globally mitigated" when you look at their status with cat /proc/<pid>/status. Otherwise, the default is that they are vulnerable. There may be a performance impact, but I am not noticing it while running my ordinary desktop apps and older games (GeForce GT240). My CPU governor (cpufreq-set/info) is ondemand.

For Intel Lynnfield CPUs, the ucode 0xa adds CPU feature flags listed in /proc/cpuinfo. With kernel 4.4.148, a new CPU flag appears: flush_l1d. According to information that I read elsewhere, if flush_l1d is present, then the l1tf mitigation (Page Table Inversion) will use the flush_l1d feature for optimized performance or minimal performance impact.

The conclusion is that, the old Lynnfield has ucode 0xa and mitigations for the latest CPU bugs. The Xeon x3450 has been running stable, with no problems. The system normally runs 24/7 with ECC RDIMM and never has errors or lockups.

kjhambrick · 08-16-2018, 05:16 AM

Quote:

Originally Posted by abga

Can you please check if you have anything related to the l1tf (&co) in the kernel log (dmesg). Maybe you remember our recent discussion about the CVE-2018-3639 (SSB) and the need for a capable microcode for full mitigation. If I understood it correctly, mitigating CVE-2018-3615, CVE-2018-3620, CVE-2018-3646 also require an updated microcode, not sure if the (latest) Q2 2018 microcode updates, that are mentioned on some web pages as required, contain what is actually needed for the mitigation.
I'm also not sure what CPUs are actually affected, Intel apparently doesn't know that either:
(bottom list - The following Intel-based platforms are potentially impacted by these issues. Intel may modify this list at a later time.)
https://www.intel.com/content/www/us...-sa-00161.html
In my original post in the Slackware security thread I mentioned that these bugs came with the introduction of the Intel SGX technology in 2015 and considered that due to the architectural changes only the CPUs manufactured after that were vulnerable. Also understood that CVE-2018-3620, CVE-2018-3646 were discovered by investigating the bugs related to Intel SGX, first reported in March. I edited that post twice, because I wanted to keep it clear and unbiased by my understanding/confusion. But maybe we should have a separated thread about this issue without polluting this kernel related thread - however, a dmesg output can provide some details here.
Thanks!

BEGIN EDIT:

oops ... should have read your next post:

Quote:

Originally Posted by abga

@kjhambrick

RedHat published some details about these vulnerabilities (CVE-2018-3615, CVE-2018-3620, CVE-2018-3646) and are stating without mentioning the exact CVE - sloppy work, that only CVE-2018-3615 - the one related solely for Intel SGX - needs a microcode update ...

<<snip>>

Unless someone else comes with a better understanding about the "pieces" (of sh...?), or Intel publishes some more concrete details and the CPUs actually affected, I take this RedHat view of the facts as satisfactory ATM.
Please disconsider my request for the dmesg related output, carry on with the good work on compiling and testing the kernels.

Thanks again !

I feel better after reading the RH Page

END EDIT

abga --

Thanks for all the info.

When I follow the link to intel sa-00161 and from there to intel sa00115-microcode-update-guidance.pdf, I see that my i7 6700K ( Skylake S ) CPU is 'all green' with the 2018-08-07 microcode update.

I don't see anything specifically referencing l1tf in my dmesg output.

These are some of the relevant tidbits:

I am running the most recent intel microcode.

Code:

# ver intel-microcode

-rw-r--r-- 1 root root 6006 Aug  8 13:00 /var/log/packages/intel-microcode-20180807-noarch-1_SBo_kjh

This latest release bumped the version for my cpu from 'revision 0xc2, date = 2017-11-16' to 'revision 0xc6, date = 2018-04-17'

These are some dmesg entries:

Code:

[    0.000000] microcode: CPU0 microcode updated early to revision 0xc6, date = 2018-04-17
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.4.148.kjh (root@kjhlt6) (gcc version 5.5.0 (GCC) ) #1 SMP Wed Aug 15 16:18:57 CDT 2018
[    0.000000] Command line: BOOT_IMAGE=Linux44148T.kjh ro root=803 vt.default_utf8=0 elevator=noop ipv6.disable=1

<<snip>>

[    0.017206] Spectre V2 : Mitigation: Full generic retpoline
[    0.017207] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[    0.017210] Spectre V2 : Spectre v2 mitigation: Enabling Indirect Branch Prediction Barrier
[    0.017212] Spectre V2 : Enabling Restricted Speculation for firmware calls
[    0.017214] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp
[    0.017427] Freeing SMP alternatives memory: 28K
[    0.019269] ftrace: allocating 26945 entries in 106 pages
[    0.034624] DMAR: Host address width 39
[    0.034627] DMAR: DRHD base: 0x000000fed90000 flags: 0x1
[    0.034633] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap d2008c40660462 ecap f050da
[    0.034637] DMAR: RMRR base: 0x000000374b5000 end: 0x000000374d4fff
[    0.034639] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed90000 IOMMU 0
[    0.034641] DMAR-IR: HPET id 0 under DRHD base 0xfed90000
[    0.034643] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit.
[    0.034644] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the BIOS setting.
[    0.036049] DMAR-IR: Enabled IRQ remapping in xapic mode
[    0.036051] x2apic: IRQ remapping doesn't support X2APIC mode
[    0.040143] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.050153] TSC deadline timer enabled
[    0.050158] smpboot: CPU0: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (family: 0x6, model: 0x5e, stepping: 0x3)
[    0.050175] Performance Events: PEBS fmt3+, 32-deep LBR, Skylake events, full-width counters, Intel PMU driver.
[    0.050196] ... version:                4
[    0.050198] ... bit width:              48
[    0.050199] ... generic registers:      4
[    0.050201] ... value mask:             0000ffffffffffff
[    0.050203] ... max period:             00007fffffffffff
[    0.050204] ... fixed-purpose events:   3
[    0.050206] ... event mask:             000000070000000f
[    0.050373] x86: Booting SMP configuration:
[    0.050375] .... node  #0, CPUs:      #1
[    0.051602] microcode: CPU1 microcode updated early to revision 0xc6, date = 2018-04-17
[    0.054655]  #2
[    0.055885] microcode: CPU2 microcode updated early to revision 0xc6, date = 2018-04-17
[    0.060268]  #3
[    0.060268] microcode: CPU3 microcode updated early to revision 0xc6, date = 2018-04-17
[    0.063359]  #4 #5 #6 #7
[    0.076955] x86: Booted up 1 node, 8 CPUs
[    0.076960] smpboot: Total of 8 processors activated (64133.71 BogoMIPS)

<<snip>>

[    6.843441] microcode: CPU0 sig=0x506e3, pf=0x2, revision=0xc6
[    6.867210] microcode: CPU1 sig=0x506e3, pf=0x2, revision=0xc6
[    6.890459] microcode: CPU2 sig=0x506e3, pf=0x2, revision=0xc6
[    6.913262] microcode: CPU3 sig=0x506e3, pf=0x2, revision=0xc6
[    6.935833] microcode: CPU4 sig=0x506e3, pf=0x2, revision=0xc6
[    6.958024] microcode: CPU5 sig=0x506e3, pf=0x2, revision=0xc6
[    6.979704] microcode: CPU6 sig=0x506e3, pf=0x2, revision=0xc6
[    7.000812] microcode: CPU7 sig=0x506e3, pf=0x2, revision=0xc6
[    7.021949] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

<<snip>>

That's all I saw that may be related to microcode and to S&M in dmesg ( but of course I may have missed something )

Is that what you were asking for ?

Thanks again for all the info !

-- kjh

kjhambrick · 08-16-2018, 06:08 AM

Thanks twy for the info on the new cpu flag flush_l1d !

I too have that flag for my i7-6700K CPU.

-- kjh

Darth Vader · 08-16-2018, 07:52 AM

Meanwhile, with an AMD processor made in the year when Julius Caesar yelled "Alea iacta iest!" to his legions...

Code:

bash-4.4# uname -a ; ./get-spectre-meltdown.sh
Linux darkstar.example.org 4.18.1 #1 SMP Wed Aug 15 15:37:34 UTC 2018 x86_64 AMD Phenom(tm) 9650 Quad-Core Processor AuthenticAMD GNU/Linux
l1tf:                Not affected
meltdown:            Not affected
spec_store_bypass:   Not affected
spectre_v1:          Mitigation: __user pointer sanitization
spectre_v2:          Mitigation: Full AMD retpoline

magicm · 08-16-2018, 09:25 AM

For those of us staying on 14.2 -
I have updated to the latest 4.4 kernel (4.4.148) provided at Dave’s Unofficial Slackbuilt Kernels ( https://blog.idlemoor.tk/dusk/ ) plus updated to the latest firmware (20180807) applicable to my CPU (x86_64 Intel(R) Core(TM) i5-2540M) via an updated SBo intel-microcode SlackBuild ( https://slackbuilds.org/repository/1...tel-microcode/. )

The results from the latest spectre-meltdown-checker.sh ( https://github.com/speed47/spectre-meltdown-checker )

* CPU vulnerability to the speculative execution attack variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
* Vulnerable to Variant 3a: YES
* Vulnerable to Variant 4: YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
> STATUS: NOT VULNERABLE (Mitigation: PTI)

CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
> STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability)

CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
> STATUS: NOT VULNERABLE (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)

CVE-2018-3615/3620/3646 [L1 terminal fault] aka 'Foreshadow & Foreshadow-NG'
> STATUS: NOT VULNERABLE (Mitigation: Page Table Inversion)

Please note that [L1 terminal fault] was not reported as NOT VULNERABLE until 4.4.148, and that the previous intel-microcode (20180703) did not correct the [rogue system register read] issue for my situation.

I really must thank this forum and all contributors to this thread (especially those who contribute to the urls I mentioned) for helping to keep my setup safer.

abga · 08-16-2018, 11:48 AM

@kjhambrick
Thanks for providing those dmesg snippets, as you've noticed, there's not much info to be found there related to these new vulnerabilities and no connection with the microcode in the kernel patch that made it to the release stage.
I was confused by this latest "coordinated disclosure of security vulnerabilities" together with the "partners". There are even pledges:
https://www.intel.com/content/www/us...-security.html

@All
Thanks for all the details provided in this thread related to these new Intel CPU issues.
I did myself provide some updates on the (more appropriate) Slackware security thread:
https://www.linuxquestions.org/quest...ml#post5892385