Two Linux Kernels Revert Performance-Killing Spectre Patches (phoronix.com) 103
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?"
Whiskey Lake (Score:2)
Supposedly Whiskey Lake has hardware mitigations for some variants. I think Cannon Lake is supposed to have mitigations for everything, but the 10nm process is having problems.
Re: (Score:1)
Cannon lake definitely doesn't have mitigations for everything.
Intel has claimed that software and hardware mitigations together would defend against the much more resent found flaws too I don't know whatever that's correct or not.
Variants - never (Score:2)
Variations on the idea will ALWAYS be present in any high performance SMT processor. CPUs are just so complicated and there are so many interactions that as long as there are simultaneous threads, one thread will be able to create resource contention with another.
A solution would be to have a very simple (slow) processor, probably an ARM chip, which handles cryptographic tasks. Complexity is very much the enemy of security, especially regarding the types of side channel attacks you mentioned.
Hardware = software (Score:2)
These days hardware is software. e.g. management engine, things that fix cosmic rays, race conditions, microcode, .....)
Consider (Score:4, Insightful)
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.
Re:Consider (Score:5, Insightful)
Re: (Score:2, Troll)
Re: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2)
Single-threading is falling off the Moore's Law style scaling. Lots of programs are sequential even if they could have been parallelized, so the lazy-man approach of just buying a new machine in one-point-five-ish years to get the same program to run twice as fast is no longer
But the real Moore's law - transistors per chip with adequate yield for market penetration - is still going strong. Parallelizable computations continue to benefit in proportion.
Human minds are built of 'WAY slow logic elements but a
Re: (Score:2)
Oh Christ you again. Moore's law is about transistor count, not speed.
Re: (Score:1)
Re: (Score:2)
Moore's law is about transistor *cost*.
Re:Consider (Score:5, Insightful)
Indeed. And eventually even those single digit improvements will go away. Maybe we can start writing better software now?
Re: (Score:2)
The only real way forwards appears to be parallel processing. Unfortunately, many workloads have limiting serial components, and others appear to, because designing good parallel algorithms is really difficult. And, FWIW, there's suggestive evidence that correct, rather than usually correct, algorithms are going to be really hard to do. I don't think it's been proven impossible for most useful cases, but I wouldn't bet money.
It may well be that neural net type applications are the optimal approach.
Re: (Score:2)
Since parallel architectures have been studied for a long, long time (anybody remember Transputers?), we do know that most things do not really benefit from more cores. The thing were they do best is server loads with lot of independent tasks being run. But most standard stuff does not benefit a lot or not at all. In addition, most coders cannot do multi-threaded software, as that is a lot harder than it looks. Deadlocks, races, etc. are not fun and testing loses effectiveness fast.
Re: (Score:2)
No. What we know is that using our current algorithms most things don't really benefit for more parallelism. You can't reasonably use the same algorithm on a process for parallel computation as for serial computation. And designing good parallel algorithms is *HARD*. So we've only got a few.
There's also suggestive evidence that there's often not a good algorithm, but only quite good heuristics, and often you can test the answer faster than you can solve it. When you can't, you gamble that multiple heuri
Re: (Score:2)
We have been designing parallel algorithms for 40 years now, because it was always clear that multi-core will eventually be the only way to scale and because we have had massive parallel systems for about that long. What we have is hence the results from intensive studies. It is not much. It is likely close to what we will have long-term.
Hence our "current" algorithms very much include parallel ones. If you think that we do not have more good parallel algorithms is a result from too little research, you are
Re: (Score:2)
Re: (Score:2)
I see engineers designing locks with the idea of preserving ordering, even when ordering does n
Re: (Score:2)
Moore's Law doesn't say anything about performance. It only applies to transistor density. And transistor density has nothing to do with performance - other than being able to cram more cache into a processor. (The vast majority of transistors in a process
Re: (Score:1)
Reminds me of these clips:
https://www.youtube.com/watch?... [youtube.com]
I've seen others too with say booting the machine, launch word processor, type something, save or print and then turning it off again where the much older machine did it quicker.
https://www.youtube.com/watch?... [youtube.com]
Re: (Score:3)
sometimes I feel the responsiveness of my windows system running on an i7 is slower than a commodore 64.
For some operations, it is, because the C64 was doing nothing in the background and it could respond immediately. On the other hand, most of your peripherals have more processing power in them than had the C64, and your computer is capable of feats that could not reasonably be achieved with a million C64s wired together. User experience, indeed.
Re: (Score:2)
SSD?
Re: (Score:2)
why not?
Huh? Did you ever use GEOS? (Score:2)
Seriously though, just pop a command window or the text version of emacs up (which is more or less the experience on your C64) and you'll find it plenty responsive. OTOH pull up 20+ browser tabs, run a compile and a video encoder in the background and maybe throw in some crypto currency mining and a bittorrent client for fun and yeah, you might occasionally see some lag on a window change.
I think we're asking for a bit much from
Re: (Score:2)
If you thought that your i7 is less responsive than a C64... Then you might actually be correct.
Have a look at this guy's research on latency and input lag. Granted, some of the machines he has tested on are fairly dated by now, but the general concept remains that a newer machine, while being essentially infinitely faster than a C64 or an Apple 2e, they all generally take longer to put a character on the screen once you've hit a key on the keyboard. Granted, they're also doing a lot more to put that charac
Re: Consider (Score:2)
this is the wrong call (Score:2)
Distributions should handle this for everyday users, so they don't have to care. People who accidentally install a kernel should get safe defaults. Defaulting to insecure is wrong.
Re: (Score:2)
Re: (Score:2)
If you care about security, don't run intel
I don't, but this isn't about me. Or at least, it's not about me at home. It doesn't really matter anyway, because basically nobody will ever install this kernel, but the principle stands.
Re: (Score:3)
Re: (Score:2)
Most companies will use this kernel.
I don't think they will. There is supposedly another fix coming soon, so I think they'll just skip it and either bide or revert until the next kernel comes along.
Re: (Score:2)
Re: (Score:2)
There are fixes for Spectre...but they require redesigned hardware.
Re:this is the wrong call (Score:4, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
If the Linux default kernel options compiled in such a way that it turned your computer into a toaster, it shouldn't matter.
Pretty much every distro provides their own customized build and releases it through their own package management system.
A distro designed for use in toasters should be mindful of what features, patches and mitigation apply to them... conversely a server or desktop flavor should have specific applicable tuning. If you are running the wrong distro, that's another topic.
The job of a deve
Re: (Score:2)
If you care about security, don't run intel, or disable Intel's insecure SMT implementation.
Correct, OpenBSD defaults to disabling SMT and they stated some hardware there is no option to disabled SMT. So having an option in Linux to disabled SMT is probably all that is needed. Seems Linux is jumping through hoops to fix hardware issues that seem to never have an end.
Re: this is the wrong call (Score:2)
"So having an option in Linux to disabled SMT is probably all that is needed. "
You do know that (boot with the noht flag) has existed since hyperthreading support landed, right? Or you can compile a kernel without hyperthreading support.
Re: (Score:2)
Re: (Score:1)
I agree one shouldn't ship in an insecure state (possibly locally like if granting video and audio access require extra permissions / could be locked down then I'm fine with that being usable from the start) but I'm well aware most distributions and operating systems doesn't do so.
I used to use the BSDs quite often and then installed Fedora or something and for root password I used "ok" because whatever just that the machine ran SSH and allowed remote root logins by default. I guess someone may find that "c
intel pay them off to not really slow there chips (Score:2)
intel pay them off to not really slow there chips down
Re:this is the wrong call (Score:4, Interesting)
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?
Re: (Score:2, Flamebait)
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.
What? Put down the crack pipe, me laddo.
I mean I assume you're okay with booting the entire world off that dangerous internet.
You, and umption.
You've said you're happy with crippling performance
at boot time, and by default, but can be disabled
for an incredibly low risk that hasn't been shown to be exploited anywhere in the public
Oh, how cute. You're planning only for today. Go ahead, karma, show him what he's won.
Re: (Score:3)
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 sho
Re: this is the wrong call (Score:1)
Ok I know performane is important, but shuld a disc write realy return before the bits are actuaky safly on disc (i mean writen nor on an on device cache) otherwise how can the calling code, and ultimatly the user, know what is written and not? Is is obvioushereIâ(TM)m norat all an expert on this so Iâ(TM)m sure Iâ(TM)m missing somthing obvius, any input is greatly apreciated.
Re: (Score:2)
I agree. But Linus is the big-picture guy here, so I can accept that he has overriding concerns. Personally, I do not even have a CPU that does SMT, as it is a pretty bad technology anyways.
Hyperthreading going away (Score:1)
9th gen core i7 losing hyperthreading anyway, Intel realizes that the only way to be safe to to eliminate hyperthreading. The real solution has always been to turn off hyperthreading. So many fixes have already been proving to be flawed and exploited, which is why some are implementing just disabling hyperthreading through the OS.
Is security _all_ that matters? (Score:1)
Linus made a point here, however, I think even he is wrong.
Would people be happy working on a 486 architecture that is 100% safe? (let's pretend 100% safe exists for the sake of the argument). I'd rather get things done quickly than spend part of the afternoon to complete just one of the jobs I'm meant to do. Would you spend, say, 10 times more to complete your jobs in a totally safe system as opposed to complete them much faster in a system that is quite safe, but not 100%?
And now where Linus gets it wrong
Re: (Score:2)
Re:Is security _all_ that matters? (Score:4, Informative)
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.
Re: (Score:2)
Re: (Score:2)
Thanks ;-)
Re: (Score:2)
Re: (Score:2)
I believe the proper metric he's looking for is furlongs per fortnight.
Re: (Score:2)
Slugs per acre, mate. That's proper pressure for you. Alternatively, an indication you're a shit gardener.