You are not logged in.

#1 2018-11-18 16:10:48

twoion
ほやほや
Registered: 2015-08-10
Posts: 2,326

Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

…because of new spectre/meltdown-class vulnerability mitigations.

Via: https://www.phoronix.com/scan.php?page= … -420-stibp, https://www.reddit.com/r/programming/co … _on_linux/, https://news.ycombinator.com/item?id=18476562.

I'm running my laptop with all mitigations disabled (that can be disabled without recompiling the kernel). The performance reductions on Intel CPUs are getting ridiculous.


Im grünen Wald, dort wo die Drossel singt…

Offline

#2 2018-11-18 18:48:41

beaker
Member
Registered: 2016-03-06
Posts: 90

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

twoion wrote:

ridiculous.

^that

Offline

#3 2018-11-18 18:51:28

cloverskull
Member
Registered: 2015-10-01
Posts: 304

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

Oh boy. I can’t wait to see how AWS handles this one...

Offline

#4 2018-11-18 20:47:25

stevep
MX Linux Developer
Registered: 2016-08-08
Posts: 332

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

The same mitigations have also been backported to 4.19.2.

If they also get backported to 4.9, odds are that they'll appear in an update of the stock Debian Stretch/BL kernel...

Cue:  Human sacrifice, dogs and cats living together... mass hysteria!

Last edited by stevep (2018-11-18 20:49:19)

Offline

#5 2018-11-18 23:31:34

glittersloth
...always giving it to you straight
Registered: 2015-09-30
Posts: 703

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

At the rate this is going, pre Spectre/Meltdown generation (I'm guessing 2005 and earlier) Intels will be popping up at Sotheby's or Philips autions, commanding higher bids than old Porsches and Pateks.  lol

Offline

#6 2018-11-19 13:44:55

earlybird
ほやほや
Registered: 2015-12-16
Posts: 648
Website

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

glittersloth wrote:

At the rate this is going, pre Spectre/Meltdown generation (I'm guessing 2005 and earlier) Intels will be popping up at Sotheby's or Philips autions, commanding higher bids than old Porsches and Pateks.  lol

This way or another way, if you care about CPU security on  current Intel you are slowly but surely getting set back to the CPU technology of the early 2000s.

May the day come when our oldest modern family PC (after a Pentium I @ 100Mhz from 1995 with 24M RAM on Windows 98 First Edition and a C64 from the 1980s), which is a Pentium 4 HT @ 2.66Ghz will be equivalent to a crippled gen9 Core processor built in 2018....

cloverskull wrote:

Oh boy. I can’t wait to see how AWS handles this one...

If I understood correctly, spectre/meltdown-type vulnerabilities apply to tasks/CPU threads executing on the same CPU core. So they should be able to solve at least some of their issues by pinning each VM to a dedicated core or even a CPU. I'm sure that messes up their revenue calculation from sharing CPU cores between low-spec VMs quite a bit but seeing as their product still adds a lot of value by way of cloud platform APIs, they are largely going to be fine. Just build a few more DCs  and done. Then they can phase out their hardware for AMD x86 or ARM, whatever they prefer, as part of the normal machine life cycle.

Online

#7 2018-11-19 14:21:07

glittersloth
...always giving it to you straight
Registered: 2015-09-30
Posts: 703

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

earlybird wrote:

If I understood correctly, spectre/meltdown-type vulnerabilities apply to tasks/CPU threads executing on the same CPU core. So they should be able to solve at least some of their issues by pinning each VM to a dedicated core or even a CPU.

So would I be right to assume it would be the smaller players (eg: those found on lowendbox.com, or more specifically; any OpenVZ based VPS provider) who will be hit hardest by this?

Offline

#8 2018-11-19 14:33:11

bigbenaugust
Member
From: unc.edu / the 919 / KIGX
Registered: 2017-05-20
Posts: 109

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

I'm actually curious to try the patch-affected kernels on actual hardware. When is 4.19 hitting backports?


--Ben
BL / MX / Raspbian... and a whole bunch of RHEL boxes. :)

Online

#9 2018-11-19 15:29:14

S7.L
Member
Registered: 2018-09-16
Posts: 338

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

I just updated my artix/arch spin to Linux 19.2 - Im running an old 2009/10 toshiba laptop.

$ sudo ./spectre-meltdown-checker.sh --explain
Spectre and Meltdown mitigation detection tool v0.40

Checking for vulnerabilities on current system
Kernel is Linux 4.19.2-artix1-1-ARTIX #1 SMP PREEMPT Wed Nov 14 22:39:05 UTC 2018 x86_64
CPU is Intel(R) Core(TM) i7 CPU       Q 740  @ 1.73GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  YES 
    * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  YES 
    * CPU indicates IBPB capability:  YES  (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  YES 
    * CPU indicates STIBP capability:  YES  (Intel STIBP feature bit)
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability:  YES  (Intel SSBD)
  * L1 data cache invalidation
    * FLUSH_CMD MSR is available:  YES 
    * CPU indicates L1D flush capability:  YES  (L1D flush feature bit)
  * 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 explicitly indicates not being vulnerable to Variant 4 (SSB_NO):  NO 
  * CPU/Hypervisor indicates L1D flushing is not necessary on this system:  NO 
  * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA):  NO 
  * CPU supports Software Guard Extensions (SGX):  NO 
  * CPU microcode is known to cause stability problems:  NO  (model 0x1e family 0x6 stepping 0x5 ucode 0xa cpuid 0x106e5)
  * CPU microcode is the latest known available version:  YES  (latest version is 0xa dated 2018/05/08 according to builtin MCExtractor DB v84 - 2018/09/27)
* CPU vulnerability to the speculative execution attack variants
  * Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass):  YES 
  * Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection):  YES 
  * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load):  YES 
  * Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read):  YES 
  * Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass):  YES 
  * Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault):  NO 
  * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault):  YES 
  * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault):  YES 

CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass'
* Mitigated according to the /sys interface:  YES  (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec:  YES  (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO 
* Kernel has mask_nospec64 (arm64):  NO 
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface:  YES  (Mitigation: Full generic retpoline, IBPB, IBRS_FW, STIBP)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES 
    * IBRS enabled and active:  YES  (for kernel and firmware code)
  * Kernel is compiled with IBPB support:  YES 
    * IBPB enabled and active:  YES 
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO 
  * Kernel compiled with retpoline option:  YES 
    * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
> STATUS:  NOT VULNERABLE  (Full retpoline + IBPB are mitigating the vulnerability)

CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'
* Mitigated according to the /sys interface:  YES  (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI):  YES 
  * PTI enabled and active:  YES 
  * Reduced performance impact of PTI:  NO  (PCID/INVPCID not supported, performance impact of PTI will be significant)
* Running as a Xen PV DomU:  NO 
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

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

CVE-2018-3639 aka 'Variant 4, speculative store bypass'
* Mitigated according to the /sys interface:  YES  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
* Kernel supports speculation store bypass:  YES  (found in /proc/self/status)
> STATUS:  NOT VULNERABLE  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)

CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability:  N/A 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'
* Mitigated according to the /sys interface:  YES  (Mitigation: PTE Inversion)
* Kernel supports PTE inversion:  YES  (found in kernel image)
* PTE inversion enabled and active:  YES 
> STATUS:  NOT VULNERABLE  (Mitigation: PTE Inversion)

CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface: VMX: conditional cache flushes, SMT vulnerable
* This system is a host running an hypervisor:  NO 
* Mitigation 1 (KVM)
  * EPT is disabled:  NO 
* Mitigation 2
  * L1D flush is supported by kernel:  YES  (found flush_l1d in /proc/cpuinfo)
  * L1D flush enabled:  YES  (conditional flushes)
  * Hardware-backed L1D flush supported:  YES  (performance impact of the mitigation will be greatly reduced)
  * Hyper-Threading (SMT) is enabled:  YES 
> STATUS:  NOT VULNERABLE  (this system is not running an hypervisor)

> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK

A false sense of security is worse than no security at all, see --disclaimer

Last edited by S7.L (2018-11-19 15:29:54)

Offline

#10 2018-11-19 18:42:27

cloverskull
Member
Registered: 2015-10-01
Posts: 304

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

earlybird wrote:

If I understood correctly, spectre/meltdown-type vulnerabilities apply to tasks/CPU threads executing on the same CPU core. So they should be able to solve at least some of their issues by pinning each VM to a dedicated core or even a CPU. I'm sure that messes up their revenue calculation from sharing CPU cores between low-spec VMs quite a bit but seeing as their product still adds a lot of value by way of cloud platform APIs, they are largely going to be fine. Just build a few more DCs  and done. Then they can phase out their hardware for AMD x86 or ARM, whatever they prefer, as part of the normal machine life cycle.

My company leverages AWS for a lot of our product offerings and the last time they patched for Spectre/Meltdown, our product performance was abysmal. The only options we had were to upgrade our virtual hardware scale. Sad times ahead indeed...

Offline

#11 2018-11-19 20:28:55

twoion
ほやほや
Registered: 2015-08-10
Posts: 2,326

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

cloverskull wrote:
earlybird wrote:

If I understood correctly, spectre/meltdown-type vulnerabilities apply to tasks/CPU threads executing on the same CPU core. So they should be able to solve at least some of their issues by pinning each VM to a dedicated core or even a CPU. I'm sure that messes up their revenue calculation from sharing CPU cores between low-spec VMs quite a bit but seeing as their product still adds a lot of value by way of cloud platform APIs, they are largely going to be fine. Just build a few more DCs  and done. Then they can phase out their hardware for AMD x86 or ARM, whatever they prefer, as part of the normal machine life cycle.

My company leverages AWS for a lot of our product offerings and the last time they patched for Spectre/Meltdown, our product performance was abysmal. The only options we had were to upgrade our virtual hardware scale. Sad times ahead indeed...

Hello extra 1000s of $ in hosting fee… I wouldn't expect any different from them than that, that is using primarily software mitigations to extract maximum HVM tenant counts from their hardware.


Im grünen Wald, dort wo die Drossel singt…

Offline

#12 2018-11-19 21:37:15

cog
Member
From: New Mexico, USA
Registered: 2015-10-27
Posts: 135

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

https://www.phoronix.com/scan.php?page= … BP-Comment

Apparently disabling SMT is way more practical than STIBP by default.  Looks like the kernel devs are reconsidering their defaults.

Theo de’radt was right all along.

Last edited by cog (2018-11-19 21:44:11)


10% of The Fishermen Catch 90% of The Fish

Offline

#13 2019-01-20 16:38:21

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 974

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

Just a thanks to Twoion for pointing out the option of simply disabling the mitigations and further the prospect of doing that during a custom compile. Appreciate the links outlining which are involved and what to look at.

Second obvious thought here is AMD perhaps, shrugs. As a personal gnu/Linux user, I'm not losing sleep over this anyway. Also can't help but have this tickle my madcapped conspiracy senses whenever bothering to think about these vulnerabilities. Not that I've invested any real effort into understanding the specifics involved. Have to assume it's significant due to the impacts it's had. Just don't see how something like this. An extremely obscure, uber hard to find and potentially far ranging vulnerability affecting a decade of chips from the worlds premiere manufacturer just "happens by coincidence".

Offline

#14 2019-02-16 07:53:51

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 974

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

Learned a bunch more on this topic and the options to disable whichever mitigations for my architecture and kernel version. Got a 4.19 vanilla kernel cooking, for the very good reason, that I'm a dork. The ancient laptop is compiling its widdle heart out. Already been an hour and 40mins.

Am getting rid of Google Inc's retpoline thingy and will jettison other mitigations later. Will see how it turns out.

Last edited by BLizgreat! (2019-02-16 08:19:03)

Offline

#15 2019-02-16 08:59:19

brontosaurusrex
Middle Office
Registered: 2015-09-29
Posts: 1,667

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

I'am pretty sure Intel will step in and with great joy and passion open-source it's ICC compiler, thus mitigating the speed difference.

Offline

#16 2019-02-16 10:46:34

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 974

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

Well pleased with the outcome. Have gotten decent gains in this. Though still really premature and cannot conclusively attribute any gains from compiling with retpoline not supported has anything to do with it. Though I get a nice long warning about it during boot.

Spectre V2 mitigation: kernel not compiled with retpoline; no mitigation available!

Errrr, yeah I know, since I just spent nearly 3 hrs of compile time to do it. Looking around for how to get rid of that warning now. Couple other things to sort too. So far not seeing any meaningful sign of problems.

Here's a kernel config option in menuconfig that blew me away, it's found under kernel hacking > choose kernel unwinder. Choose the help for an explanation of what the dang orc unwinder is/does, says.

This unwinder is more accurate across interrupt entry frames than the pointer unwinder (which is the default by the way). It also enables a 5-10% performance improvement across the entire kernel compared to frame pointers.

Needless to say I had to try it over the default. Not even up to speed on the above but will have to research, no way I wasn't going to give it a try.

Offline

#17 2019-02-17 01:58:09

DeepDayze
Member
From: In Linux Land
Registered: 2017-05-28
Posts: 605

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

BLizgreat! wrote:

Well pleased with the outcome. Have gotten decent gains in this. Though still really premature and cannot conclusively attribute any gains from compiling with retpoline not supported has anything to do with it. Though I get a nice long warning about it during boot.

Spectre V2 mitigation: kernel not compiled with retpoline; no mitigation available!

Errrr, yeah I know, since I just spent nearly 3 hrs of compile time to do it. Looking around for how to get rid of that warning now. Couple other things to sort too. So far not seeing any meaningful sign of problems.

Here's a kernel config option in menuconfig that blew me away, it's found under kernel hacking > choose kernel unwinder. Choose the help for an explanation of what the dang orc unwinder is/does, says.

This unwinder is more accurate across interrupt entry frames than the pointer unwinder (which is the default by the way). It also enables a 5-10% performance improvement across the entire kernel compared to frame pointers.

Needless to say I had to try it over the default. Not even up to speed on the above but will have to research, no way I wasn't going to give it a try.

How's the new kernel you compiled stripping out all the Spectre and Meltdown mitigations plus switching to the new unwinder? Have you tried any benchmarking to determine the performance difference between the stock 4.20 kernel vis a vis your custom one? Would be interesting to see this.


Real Men Use Linux

Offline

#18 2019-02-17 09:36:58

damo
....moderator....
Registered: 2015-08-20
Posts: 4,592

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

And how does a custom kernel compare with using these boot parameters?

GRUB_CMDLINE_LINUX="pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier"

Be Excellent to Each Other...

FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt  «» BunsenLabs on DeviantArt

Offline

#19 Yesterday 01:27:14

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 974

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

@DeepDayze

Retpoline is supposed to be a spectre 2 mitigation. If someone compiles a kernel without it, they forego those mitigations and any overhead they introduce. Am not even sure it's advisable or has much of any impact. Choosing the orc unwinder, instead of the default is another option someone can choose in the .config file they're using to compile with. If it lives up to the hype I've seen on it,  likely more distro's will be using it.

Of course as the kernel development progresses new config options are added. This kernel doesn't have all mitigations for spectre and meltdown compiled out. Still using pti but as Damo mentions are supposed to be many options someone can use via grub to have them en/dis-abled.

Have tried nopti, nospectre_v2 and others, update_grub, reboot, run the commands to check status of vulnerability and still show pti is being used, looks the same as before adding the flags. Just got a list together for reference. May be missing something and will keep dorking around.

Lmao, yep, may have been adding these to the wrong line in /etc/default/grub. Thanks Damo, will check real quick. From what I've read about these, they can be kernel version dependent. Makes sense as options and these new flags to control them are a work in progress. Also gather which flags to use are architecture dependent ie: amd64 etc.

In terms of better performance, never been able to get much that's noticeably improved over stock kernels and this latest is no exception. Though  does seem more responsive and cut 10mbs off initial ram/idle. Offhand want to attribute that to orc.

Am sure there are test results comparing kernels with and w/o mitigations in a given workload/application etc online. I just use things like free -m/ps_mem, top, uptime, sensors, checking cpu freqs, boot time w systemd-analyze and actually timing it, same for applications responsiveness, general timing and impression. I tend to frequently do these anyway while using a comp. Being a dork like that.

Boot time for the new kernel is comparable to stock too. Have thought a bunch of times of doing a kernel how-to and likely won't bother, as I'm not really qualified. Though are several config options someone may only be able to play with via custom compiling.

Vll!

More babble, one of those configs being timer interrupt freq, every "desktop performance kernel", I've ever seen sets this @1000hz VS stock tend to be 250hz. I'm conservative in this and opt for 300hz though. Other stuff said to be more applicable to desktop gnu/nix.

Like I've said, don't want to babble too much about the Linux kernel.

Last edited by BLizgreat! (Yesterday 01:58:54)

Offline

#20 Yesterday 02:20:01

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 974

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

Dang it try as might these mitigation flags continue to give me the finger, so remain unsure of them and proper use. Will have to keep dorking around. Obviously missing something here.

Offline

#21 Yesterday 03:59:06

DeepDayze
Member
From: In Linux Land
Registered: 2017-05-28
Posts: 605

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

Try an LTS kernel such as 4.14?


Real Men Use Linux

Offline

#22 Yesterday 05:11:57

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 974

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

^Oops forgot to mention that too. Went with v 4.19 cause it's supposed to get a couple years of support. The v 4.20 kernel also has 350 thou new lines of code. Surely none of which would provide any benefits for my crusty old laptop.  Zero idea how much of that is related to spectre/meltdown either.

Though as time passes they'll no doubt get better at mitigation for them. Will implement better patching and control flags too.

One thing that occurs about this and find kind of aggravating, as far as I'm aware with only one /etc/default/grub file so flags set are applied to all installed kernels. Likely are work arounds, oh well.

Went ahead and looked up the kernel config option which applies to pti, it's

CONFIG_PAGE_TABLE_ISOLATION and retpoline's is CONFIG_RETPOLINE while choosing options in a .config file with them.

Think it's clear most of these control flags and mitigation patching is aimed at admins, with desktop nixers being a far distant consideration but that's fair, as it should be in my opinion.

Might recompile to disable pti in the kernel too. Again not fully aware of all the implications of doing that type of thing. Still other junk I want to fiddle with and will devote more time + care, if decide to proceed this time around.

Still overall pleased thus far with the effort. Kind of surprised given the sloppiness and other circumstances here, how well things turned out. However I am willing to attribute this to my mega massive super nix ninja powers. tongue

Offline

#23 Yesterday 05:20:41

BLizgreat!
Resident Babbler - vll!
Registered: 2015-10-03
Posts: 974

Re: Linux 4.20 likely to bring a performance reduction of 20-40% on Intel

Massive mega super nix ninja after thought. Since it's a custom compile, none of that year's of support matters to me (w/o recompile), ah, still rather go with something that's deemed lts. Do have the v 4.20 and one of the v 5.0rc kernels source onhand. Nah will stick w 4.19.

Last edited by BLizgreat! (Yesterday 05:22:36)

Offline

Board footer

Powered by FluxBB