Slashdot Mirror

← Back to Stories (view on slashdot.org)

Two Linux Kernels Revert Performance-Killing Spectre Patches (phoronix.com)

Posted by EditorDavid on from the cures-worse-than-diseases dept.

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?"

56 of 103 comments (clear)

  1. Consider by 3seas · · Score: 3, 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.

    1. Re:Consider by 110010001000 · · Score: 4, Insightful

      Moore's Law has been dead for many years now. We can only expect single digit improvements in CPU performance from now on. Of course, someone will reply with "what about quantum computers?" but those people don't even understand what quantum computers are.

    2. Re:Consider by 110010001000 · · Score: 1, Troll

      Moore's Law is dead and applies to computers based on transistors. It says nothing about "the cloud".

    3. Re:Consider by 110010001000 · · Score: 1, Insightful

      Thanks for the tip. Some pedant always points this out. No one cares. The end result is that CPUs have hit a dead end.

    4. Re:Consider by aliquis · · Score: 1

      Reminds me of these clips:
      https://www.youtube.com/watch?...

      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?...

    5. Re:Consider by ArchieBunker · · Score: 1

      Oh Christ you again. Moore's law is about transistor count, not speed.

      --
      Only the State obtains its revenue by coercion. - Murray Rothbard
    6. Re:Consider by drinkypoo · · Score: 2

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    7. Re:Consider by gweihir · · Score: 4, Insightful

      Indeed. And eventually even those single digit improvements will go away. Maybe we can start writing better software now?

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:Consider by kobaz · · Score: 1

      SSD?

      --

      The goal of computer science is to build something that will last at least until we've finished building it.
    9. Re:Consider by 110010001000 · · Score: 1

      I never said it was CPU "speed". It is transistor density which directly maps to performance. And Moore's Law is dead.

    10. Re:Consider by ceoyoyo · · Score: 1

      Moore's law is about transistor *cost*.

    11. Re:Consider by PhunkySchtuff · · Score: 1

      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 character there, but the fact remains that overall latency has increased as computers have got faster.

      https://danluu.com/input-lag/
      https://danluu.com/keyboard-la...

      --
      Specialist Mac support for creative pros, Melbourne
    12. Re:Consider by HiThere · · Score: 1

      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.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    13. Re:Consider by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    14. Re: Consider by peppepz · · Score: 1

      Dear companion in old age, are you sure you remember the responsiveness of your C64, or lack thereof? Let's not talk in hyperboles to the point that words no longer have a meaning.

    15. Re:Consider by Ungrounded+Lightning · · Score: 1

      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 achieve prodigious computational feats by massive parallelism. They serve as a proof-of-concept that practical and useful massively-parallel computations are possible.

      --
      Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
    16. Re:Consider by tlhIngan · · Score: 1

      Moore's Law has been dead for many years now. We can only expect single digit improvements in CPU performance from now on. Of course, someone will reply with "what about quantum computers?" but those people don't even understand what quantum computers are.

      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 processor are for memory - the transistors doing the actual calculation are far far fewer than you'd think - random logic transistors are far less dense than memory).

      As a result, Moore's Law applies more towards memory (RAM, flash, etc) than logic devices. Logic devices are dominated by how dense you can make the wiring. In fact, there are so few transistors, chip makers traditionally sprinkle those areas with footprints for inactive transistors so they have spares they can wire in during minor stepping revisions.

    17. Re:Consider by sad_ · · Score: 1

      why not?

      --
      On a long enough timeline, the survival rate for everyone drops to zero.
    18. Re:Consider by HiThere · · Score: 1

      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 heuristics returning the same result yields something "close enough" to the correct answer.

      It also depends on how complex the problem is that you're trying to deal with. Simple problems are more likely to not benefit from complex approaches.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    19. Re:Consider by gweihir · · Score: 1

      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 very much mistaken.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    20. Re:Consider by Bengie · · Score: 1

      I've seen a lot of designs that were made single threaded because contention was too high to be useful concurrently, but it was a self-fulfilling prophecy because the engineers never realized that perfect is the enemy of good. There are many cases where certain data types can be lossy and not hurt anything, and in these cases, contention could be virtually eliminated if the engineers could think outside the box.

      I see engineers designing locks with the idea of preserving ordering, even when ordering does not matter, or making sure that an ephemeral aggregate value is 100% correct when 99% correct is good enough. People like to make a problem fit the way they understand the problem instead of changing their understanding to fit the problem.

      After they add all of these meaningless locks around the system, the complain that the problem can't be parallelized effectively.

      Omg, did the packet arrive before the key-press or the other way?! Who the fk cares?! The problem already has fundamental race conditions, adding or removing one more class of race conditions will not matter. Key presses by the user has no synchronization requirements with data coming in from the network. Why create such a dependency? This is a simplistic example of much more complex assumptions of ordering that most people feel compelled to enforce because it simplifies their mental model.

      Personally, I like to take the approach of of distributed systems. For some reason, people can handle accepting no guarantee of ordering when you have distinctly separate computers asynchronously processing event streams than different threads doing the same thing in a CPU. They can't seem to grasp the abstractness of an API, and treat web service API(endpoint) calls as something completely magically different than a library API(method) call.

    21. Re:Consider by Bengie · · Score: 1

      I personally think the biggest block to parallelism is everyone used to using pre-made algorithms or libraries and attempting to shoe-horn their problem domain into a limited collection of general purpose parallel algorithms. I find that fit for purpose parallel algorithms and data structures are quite abundant. I've seen rolling my own for a long time. I started parallel programming around the age of 11. I found it quite intuitive. I see race conditions as a form of edge case. All you need to do is design code that has no edge cases. If you're defined and handled all of your edge cases, you cannot have any race conditions.

  2. Whiskey Lake by JBMcB · · Score: 1

    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.

    --
    My Other Computer Is A Data General Nova III.
    1. Re:Whiskey Lake by aliquis · · 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.

  3. Variants - never by raymorris · · Score: 1

    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.

  4. this is the wrong call by drinkypoo · · Score: 1

    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.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    1. Re:this is the wrong call by 110010001000 · · Score: 1

      If you accidentally install a kernel then I doubt you care about security. If you care about security, don't run intel, or disable Intel's insecure SMT implementation.

    2. Re:this is the wrong call by drinkypoo · · Score: 1

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    3. Re:this is the wrong call by 110010001000 · · Score: 2

      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.

    4. Re:this is the wrong call by drinkypoo · · Score: 1

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    5. Re:this is the wrong call by 110010001000 · · Score: 1

      There is no fix for Spectre, only mitigations.

    6. Re:this is the wrong call by aliquis · · 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 "convenient" but I don't see why it should be that way by default. (I don't think SSH need to run by default (unless the alternative is to run telnet by default instead :D) either but at-least with a username you've got obscurity.)

    7. Re:this is the wrong call by thegarbz · · Score: 3, 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?

    8. Re:this is the wrong call by drinkypoo · · Score: 1, 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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    9. Re:this is the wrong call by drinkypoo · · Score: 3, 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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    10. Re:this is the wrong call by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    11. Re:this is the wrong call by jmccue · · Score: 1

      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.

    12. Re:this is the wrong call by 110010001000 · · Score: 1

      That might be true for Windows/Mac and desktop endusers, but the vast majority of Linux systems affected are going to be servers which administrators "care" about. There is no reason to kill performance on servers which aren't running arbitrary code. Most likely desktop Linux distros will be running with the mitigations, but the number of desktop users is very small.

    13. Re: this is the wrong call by bn-7bc · · 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.

    14. Re:this is the wrong call by HiThere · · Score: 1

      There are fixes for Spectre...but they require redesigned hardware.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    15. Re: this is the wrong call by buchanmilne · · Score: 1

      "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.

    16. Re:this is the wrong call by jaymemaurice · · Score: 1

      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 developer is to code with flexibility enabling or supporting the use cases of the hardware or software in it's ecosystem.
      Also, disabling SMT globally is probably stupid. If you are concerned timing attack vectors from SMT in a particular application or in kernel space, you can mitigate such issues using CPU scheduling options such as isolcpus which will still allow you set the affinity of some SMT optimized applications onto a shared core. The operating system or hypervisor should be the broker of the memory or CPU resources when you are working with a hypervisor or operating system that properly supports it.

      --
      120 characters ought to be enough for anyone
    17. Re:this is the wrong call by thegarbz · · Score: 2

      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.

    18. Re: this is the wrong call by jmccue · · Score: 1

      No I did not know about 'noht', thanks I have not been paying attention kernel/parms flags since the 1.x days, never needed to compile a kernel since then. :)

  5. Hyperthreading going away by Anonymous Coward · · 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.

  6. Is security _all_ that matters? by Anonymous Coward · · 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. SMT _does_ improve performance specially in data crunching pipelines (interestingly what I do for a living). Disabling it may well help me be safer, but I would loose ~40% performance (just ran some quick tests with sysbench). Sure, writing software does not demand much hardware. Vim/NVim/Kakoune do the jobs rather well. But when you write code that also requires performance given the volume of data the user (me) works on... SMT can have a significant impact. So is not as simple as just disabling SMT.

    Probably all that's needed is a bit of common sense when it comes to download software?

    If security is all that matters... why don't you/we/they live in bunkers? Because most properties are fairly easy to break into. Throw a stone to a glass and there's a way in, a bunker would _never_ have that problem... specially because they probably don't even have windows. Not to mention trespassing: gardens, backyards... all they need is to jump in. That problem would never exist in a bunker. However, living in a bunker is pretty inconvenient, isn't it?

    1. Re:Is security _all_ that matters? by 110010001000 · · Score: 1

      Um, Linus never said that SMT didn't improve performance. He just said that people who care about that level of security have already disabled it, so why make bother ruining the performance for people who don't care?

    2. Re:Is security _all_ that matters? by gweihir · · Score: 3, 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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    3. Re:Is security _all_ that matters? by 110010001000 · · Score: 1

      Sometimes I think you are the only sensible person left on the site. I know I am not!

    4. Re:Is security _all_ that matters? by gweihir · · Score: 1

      Thanks ;-)

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  7. Re:So, disable SMT, then what? Ponies? by 110010001000 · · Score: 1

    How would you express performance loss? Percentage by workload is the only meaningful measure. What are you looking for?

  8. Huh? Did you ever use GEOS? by rsilvergun · · Score: 1

    on a base model (64kb) C64? You kids today and your "slow" computers...

    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 our computers at times. Still, if it bother's you then buy a newer CPU, spend $200 bucks on a mobo and another $200 on 32GB of ram and $300 on your SSD. My bro did and that was that. It's not an insurmountable problem, it's not even that expensive (my C64 was $300 in 1992, that's almost $600 today and the monitor was probably another $150 at least, I can't remember). Again, kid's these days...

    --
    Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
  9. intel pay them off to not really slow there chips by Joe_Dragon · · Score: 1

    intel pay them off to not really slow there chips down

  10. Re:So, disable SMT, then what? Ponies? by kobaz · · Score: 1

    I believe the proper metric he's looking for is furlongs per fortnight.

    --

    The goal of computer science is to build something that will last at least until we've finished building it.
  11. Hardware = software by goombah99 · · Score: 1

    These days hardware is software. e.g. management engine, things that fix cosmic rays, race conditions, microcode, .....)

    --
    Some drink at the fountain of knowledge. Others just gargle.
  12. Re:So, disable SMT, then what? Ponies? by q4Fry · · Score: 1

    Slugs per acre, mate. That's proper pressure for you. Alternatively, an indication you're a shit gardener.