Two Linux Kernels Revert Performance-Killing Spectre Patches (phoronix.com)
Friday Greg Kroah-Hartman released stable point releases of Linux kernel 4.19.4, as well as 4.14.83 and 4.9.139. While they were basic maintenance updates, the 4.19.4 and 4.14.83 releases are significant because they also reverted the performance-killing Spectre patches (involving "Single Thread Indirect Branch Predictors", or STIBP) that had been back-ported from Linux 4.20, according to Phoronix:
There is improved STIBP code on the way for Linux 4.20 that by default just applies STIBP to SECCOMP threads and processes requesting it via prctl() but otherwise is off by default (that behavior can also be changed via kernel parameters). Once that code is ready to go for Linux 4.20, we may see it then back-ported to these stable trees.
Aside from reverting STIBP, these point releases just have various fixes in them as noted for 4.19.4, 4.14.83, and 4.9.139.
Last Sunday Linus Torvalds complained that the performance impact of the STIPB code "was clearly way more expensive than people were told," according to ZDNet: "When performance goes down by 50 percent on some loads, people need to start asking themselves whether it was worth it. It's apparently better to just disable SMT entirely, which is what security-conscious people do anyway," wrote Torvalds. "So why do that STIBP slow-down by default when the people who *really* care already disabled SMT?"
There is improved STIBP code on the way for Linux 4.20 that by default just applies STIBP to SECCOMP threads and processes requesting it via prctl() but otherwise is off by default (that behavior can also be changed via kernel parameters). Once that code is ready to go for Linux 4.20, we may see it then back-ported to these stable trees.
Aside from reverting STIBP, these point releases just have various fixes in them as noted for 4.19.4, 4.14.83, and 4.9.139.
Last Sunday Linus Torvalds complained that the performance impact of the STIPB code "was clearly way more expensive than people were told," according to ZDNet: "When performance goes down by 50 percent on some loads, people need to start asking themselves whether it was worth it. It's apparently better to just disable SMT entirely, which is what security-conscious people do anyway," wrote Torvalds. "So why do that STIBP slow-down by default when the people who *really* care already disabled SMT?"
sometimes I feel the responsiveness of my windows system running on an i7 is slower than a commodore 64. It should make people wonder with all the advances in chip manufacturing, speed and..... Oh wait Moores law doesn't apply to user experience.
Most companies will use this kernel. Although Spectre is bad, it isn't an issue in many workloads. The vast majority of Linux servers wouldn't be affected by Spectre in reality.
People who accidentally install a kernel should get safe defaults. Defaulting to insecure is wrong.
People need to take an axe to their cable modem and only go on the internet once they have a degree in Computer Science majoring in security and risk assessment.
I mean I assume you're okay with booting the entire world off that dangerous internet. You've said you're happy with crippling performance for an incredibly low risk that hasn't been shown to be exploited anywhere in the public, so clearly you support throwing out the baby with the bathwater on security right?
That someone doesn't "care" about security doesn't mean they shouldn't get secure defaults, to the contrary.
It's not *just* about those users either (who "don't care", is in "are yet unaware of X because they're still too busy with all the other shit devs and corporations sling at them"), it's also about them being a vecor of attack / resource drain on yet others.
Exactly this. I couldn't have said it better myself (as evinced by the fact that I didn't) but it's actually more important for people who don't care about security to get secure defaults, specifically because they don't care.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Also take into account that this comment is mostly targeted at virtualized server loads, not desktop computing. While there are these scenarios of "JavaScript in the browser steals your keys", the actual threat is "VM1 steals the keys of VM2", for various reasons. My prediction is that SMT will basically be dropped by CPU manufacturers. AMD was never very keen on it and Intel is currently reversing their propaganda on how great it is.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
at boot time, and by default, but can be disabled
Exactly as I said. People by default should not be allowed on the internet right? I mean it's a security risk that is many orders of magnitude worse than what you are proposing as a default.
Oh, how cute. You're planning only for today.
Nope. We're analysing the risk that is presented and the possible ways it could be exploited with a very clear answer. It won't be, not on a desktop computer, because while you're kicking yourself to close security holes I'm sending emails to your mother claiming I'm Microsoft and due to a problem on her computer she should run an executable.
There's a good reason the vast majority of malware targets users rather than esoteric and hard to exploit bugs.
Protip: The sky isn't falling, and you'd realise that if you do a risk assessment rather than just shout about expensive defaults from the mountaintops.