The Latest Kernel Release.

cwizardone · 11-18-2018, 04:24 PM

4.20-rc3

The newest "mainline" kernel, version 4.20-rc3, has been been made available for testing.

The tarball, https://git.kernel.org/torvalds/t/linux-4.20-rc3.tar.gz

Mr. Torvalds' announcement,

Quote:

Linux 4.20-rc3
From: Linus Torvalds
Date: Sun Nov 18 2018 - 17:07:32 EST

The only unusual thing last week was my travel - not any code issues.
That caused a few pulls to be delayed by a day or two, but nothing
else.

And now I'm back home, and 4.20-rc3 is out there.

The changes in rc3 are pretty tiny, which means that the statistics
look slightly different from the uysual ones - drivers only account
for less than a third of the patch, for example. But that really isn't
because of anything odd going on anywhere else, it all looks like just
random noise in the distribution of patches. So we have about one
third driver updates, one third arch updates, and one third "core"
(kernel, mm, fs, networking).

Shortlog appended for some flavor of the details,

Linus

---

http://lkml.iu.edu/hypermail/linux/k...1.2/01363.html

And, Mr. Torvalds' thoughts on STIBP,

http://lkml.iu.edu/hypermail/linux/k...1.2/01328.html

and

http://lkml.iu.edu/hypermail/linux/k...1.2/01359.html

and

http://lkml.iu.edu/hypermail/linux/k...1.2/01368.html

garpu · 11-19-2018, 08:56 AM

Does Slackware have STIBP enabled by default? ETA: reading, looks like it was back-ported to 3.19.2, so I'm assuming, yes?

GazL · 11-19-2018, 12:22 PM

looks like it is:

Code:

$ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW, STIBP
$

(that's from current)

..but a far more interesting question is: do we really want it to?

http://lkml.iu.edu/hypermail/linux/k...1.2/01328.html

edit: apologies 'cwiz. Hadn't noticed you'd already posted that link ( I only saw the post I was replying to.)

P.S. At the moment I'm seriously contemplating turning off all but Meltdown.

garpu · 11-19-2018, 10:55 PM

Quote:

Originally Posted by GazL

looks like it is:
(that's from current)

..but a far more interesting question is: do we really want it to?

Reading further in the kernel threads (after I'd had coffee), it seems like the behavior will change to not be on by default going forward? It does seem like a sensible decision.

cwizardone · 11-21-2018, 02:38 AM

Kernel updates 4.19.3, 4.18.20 [EOL], 4.14.82, 4.9.138, 4.4.164 and 3.16.61 are now available at,

https://www.kernel.org/

The change logs,

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

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

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

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

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

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

Dave's Unofficial Slackbuilt Kernel updates for the 4.4.xxx and 4.18.xx series
can be found at, https://dusk.idlemoor.tk

And, the 4.18.xx kernel has now reached its End Of Life,

Quote:

Linux 4.18.20
From: Greg KH
Date: Wed Nov 21 2018 - 05:31:18 EST

.......Note, this is the LAST 4.18.y kernel release. 4.18 is now end-of-life,
please move to 4.19.y at this point in time......

thanks,

greg k-h

Edit in: It appears the release of the 3.18.126 update has been delayed.

Lysander666 · 11-21-2018, 03:51 AM

Quote:

Originally Posted by GazL

/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
.

Now this is a good development. Can this mitigation make it into 4.4.xxx? I'm currently on 4.4.153 and there's no mitigation for spec store bypass.

Loathe as I would be to move from 4.4.153. It works really well for me.

cwizardone · 11-21-2018, 03:07 PM

When this patch will be applied, I don't know.

More on STIBP,

Quote:

[PATCH] x86/speculation: Revert turning on STIBP all the time
From: Tim Chen
Date: Wed Nov 21 2018 - 15:33:52 EST

Commit 53c613fe "x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation"
turns on STIBP all the time.

This causes large performance regression in many workloads.

One case is perlbench in the SpecInt Rate 2006 test suite which shows a
21% reduction in throughput.
There're also other reports of drop in performance on Python and PHP benchmarks:
https://www.phoronix.com/scan.php?pa...0-bisect&num=2

STIBP on all the time should not be the default option.

Turn off STIBP all the time for now till STIBP can be applied on
a per task basis.

Signed-off-by: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
---

http://lkml.iu.edu/hypermail/linux/k...1.2/05669.html

Daedra · 11-21-2018, 03:52 PM

Quote:

Originally Posted by cwizardone

When this patch will be applied, I don't know.

More on STIBP,

http://lkml.iu.edu/hypermail/linux/k...1.2/05669.html

Quote:

Originally Posted by GazL

looks like it is:

Code:

$ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW, STIBP
$

(that's from current)

..but a far more interesting question is: do we really want it to?

http://lkml.iu.edu/hypermail/linux/k...1.2/01328.html

edit: apologies 'cwiz. Hadn't noticed you'd already posted that link ( I only saw the post I was replying to.)

P.S. At the moment I'm seriously contemplating turning off all but Meltdown.

I did all those microcode updates and what not when the spectre/meltdown patches stared rolling out. I ran it for a week then rolled back my bios. The performance hit was very noticeable and to me was not worth it on my desktop machine. If someone wanted to hack me that bad I am sure they would find another way. On a server or business machine I understand the importance, but I don't like the idea of a huge performance hit being forced upon me. I hope they stick to the per task basis idea.

cwizardone · 11-21-2018, 09:22 PM

OK, here we go. STIBP will be reverted in the 4.19.4 update.

Quote:

[PATCH 4.19 00/42] 4.19.4-stable review
From: Greg Kroah-Hartman
Date: Wed Nov 21 2018 - 14:06:52 EST

This is the start of the stable review cycle for the 4.19.4 release.
There are 42 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know..........
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Linux 4.19.4-rc1

Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Revert "x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation"
...............

http://lkml.iu.edu/hypermail/linux/k...1.2/05446.html

cwizardone · 11-22-2018, 08:37 AM

The latest kernel update for the 3.18.xxx series, version 3.18.126 is now available at,

https://www.kernel.org/

The change log, https://cdn.kernel.org/pub/linux/ker...geLog-3.18.126

cwizardone · 11-23-2018, 02:21 AM

Kernel updates 4.19.4, 4.14.83 and 4.9.139 are now available at,

https://www.kernel.org/

The change logs,

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

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

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

mats_b_tegner · 11-23-2018, 01:58 PM

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.9.140
Also includes

Quote:

Revert "x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation"

larrybpsu · 11-23-2018, 10:55 PM

Quote:

Originally Posted by Skaendo

4.19 kernels are playing hell with my Intel GM965 chipset. This is a well known bug and no one upstream seems to care about it because apparently it's too old (circa 1997/8 here).

Found a solution for this last week, but was hoping the 4.19.3 or 4.19.4 would take care of it.

Add this to your boot command line:

Code:

video=SVIDEO-1:d

Have the same chipset on a Compaq 6910p, boots and starts X fast! I keep trying new kernels without it, but it still slows it down.

cwizardone · 11-25-2018, 05:11 PM

4.20-rc4

The newest "mainline" kernel, version 4.20-rc4, has been been made available for testing.

The tarball, https://git.kernel.org/torvalds/t/linux-4.20-rc4.tar.gz

Mr. Torvalds' announcement, http://lkml.iu.edu/hypermail/linux/k...1.3/00504.html

cwizardone · 11-27-2018, 10:06 AM

Kernel updates 4.19.5, 4.14.84, 4.9.141, 4.4.165 and 3.18.127 are now available at,

https://www.kernel.org/

The change logs,

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

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

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

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

https://cdn.kernel.org/pub/linux/ker...geLog-3.18.127

Dave's Unofficial Slackbuilt Kernel update for the 4.4.x series
can be found at, https://dusk.idlemoor.tk

This fix was found in all but the 3.18.x change log,

Quote:

commit 3e31936ba001b3d7450898ece1bfeb7c1a6bbc5d
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date: Tue Oct 16 12:59:44 2018 +0200

drivers/misc/sgi-gru: fix Spectre v1 vulnerability

commit fee05f455ceb5c670cbe48e2f9454ebc4a388554 upstream.

req.gid can be indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

vers/misc/sgi-gru/grukdump.c:200 gru_dump_chiplet_request() warn:
potential spectre issue 'gru_base' [w]

Fix this by sanitizing req.gid before calling macro GID_TO_GRU, which
uses it to index gru_base.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>