Language Selection

English French German Italian Portuguese Spanish

Torvalds Blasts "Beyond Stupid" Flushing L1d On Context Switches - Reverts Code For Now

Filed under
Linux

As part of the initial set of changes merged today for Linux 5.8 was the x86/mm material that included the controversial feature of opt-in flushing of the L1 data cache on context switching. Linus Torvalds ended up deciding to revert this functionality as for now at least he views it as crazy.

While this feature is opt-in via new prctl options and not enabled by default and done in the name of helping those concerned about snoop assisted data sampling vulnerabilities or cache leakage via side channels and yet to be uncovered CPU vulnerabilities, for the time being Linux creator Linus Torvalds is not convinced.

Read more

Original:

  • Re: [GIT PULL] x86/mm changes for v5.8
    >  - Provide an opt-in (prctl driven) mechanism to flush the L1D cache on context switch.
    >    The goal is to allow tasks that are paranoid due to the recent snoop assisted data
    >    sampling vulnerabilites, to flush their L1D on being switched out.
    
    Am I mis-reading this?
    
    Because it looks to me like this basically exports cache flushing
    instructions to user space, and gives processes a way to just say
    "slow down anybody else I schedule with too".
    
    I don't see a way for a system admin to say "this is stupid, don't do it".
    
    In other words, from what I can tell, this takes the crazy "Intel
    ships buggy CPU's and it causes problems for virtualization" code
    (which I didn't much care about), and turns it into "anybody can opt
    in to this disease, and now it affects even people and CPU's that
    don't need it and configurations where it's completely pointless".
    
    To make matters worse, it has that SW flushing fallback that isn't
    even architectural from what I remember of the last time it was
    discussed, but most certainly will waste a lot of time going through
    the motions that may or may not flush the L1D after all.
    
    I don't want some application to go "Oh, I'm _soo_ special and pretty
    and such a delicate flower, that I want to flush the L1D on every task
    switch, regardless of what CPU I am on, and regardless of whether
    there are errata or not".
    
    Because that app isn't just slowing down itself, it's slowing down others too.
    
    I have a hard time following whether this might all end up being
    predicated on the STIBP static branch conditionals and might thus at
    least be limited only to CPU's that have the problem in the first
    place.
    
    But I ended up unpulling it because I can't figure that out, and the
    explanations in the commits don't clarify (and do imply that it's
    regardless of any other errata, since it's for "undiscovered future
    errata").
    
    Because I don't want a random "I can make the kernel do stupid things"
    flag for people to opt into. I think it needs a double opt-in.
    
    At a _minimum_, SMT being enabled should disable this kind of crazy
    pseudo-security entirely, since it is completely pointless in that
    situation. Scheduling simply isn't a synchronization point with SMT
    on, so saying "sure, I'll flush the L1 at context switch" is beyond
    stupid.
    
    I do not want the kernel to do things that seem to be "beyond stupid".
    
    Because I really think this is just PR and pseudo-security, and I
    think there's a real cost in making people think "oh, I'm so special
    that I should enable this".
    
    I'm more than happy to be educated on why I'm wrong, but for now I'm
    unpulling it for lack of data.
    
    Maybe it never happens on SMT because of all those subtle static
    branch rules, but I'd really like to that to be explained.
    
                        Linus
    

Beyond Stupid...

Now that's the Linus I remember and love!

Exercising his freedom of speech

Exercising his freedom of speech

Big changes could be coming to Linux programming

  • Big changes could be coming to Linux programming

    After recently making the switch from Intel to AMD, Linus Torvalds has come out against 80-character-lines as a de facto programming standard.

    As reported by The Register, Torvalds shared his thoughts on the topic of line lengths in a recent Linux kernel clean-up post where he argued that limiting lines to 80 characters makes for lots of line breaks. Others have argued that 80-character lines are a long-standing convention that should remain in place due to the fact that large monitors can handle many small windows when column width is limited.

Linus Torvalds rejects 'beyond stupid' AWS-made Linux patch

  • Linus Torvalds rejects 'beyond stupid' AWS-made Linux patch for Intel CPU Snoop attack

    Linux kernel head Linus Torvalds has trashed a patch from Amazon Web Services (AWS) engineers that was aimed at mitigating the Snoop attack on Intel CPUs discovered by an AWS engineer earlier this year.

    The so-called 'Snoop-assisted L1 Data Sampling', or Snoop (CVE-2020-0550) attacks affecting a range of Intel Xeon and Core CPUs were disclosed in March.

    AWS engineer Pawel Wieczorkiewicz discovered a way to leak data from an Intel CPU's memory via its L1D cache, which sits in CPU cores, through 'bus snooping' – the cache updating operation that happens when data is modified in L1D.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Arcade shooter with a massive skill tree 'BYTEPATH' goes open source

A few years after release, adnzzzzZ has released the source code for their crazy skill-tree arcade shooter BYTEPATH. "Expect BYTEPATH to be a mix of Bit Blaster XL and Path of Exile, created with the intention of expanding Bit Blaster XL's relaxing and addictive gameplay with Path of Exile's build depth, build diversity and RPG elements." Now available under the MIT license, it's another good look into how indie games get made and a good starting point for those looking to see a properly finished game. Not only that, it can now live on with community fixes and continue working far into the future. Read more

Android Leftovers

Proton GE compatibility layer has a big new release up

Proton GE, the community-built fork of the Proton compatibility layer for Linux has a big new release out. Need a quick reminder? Wine is a compatibility layer that can help to run Windows apps and games on Linux. Valve have their own version called Proton which is included with the Linux Steam Client in Steam Play, and Proton GE is a special version of it built by user "GloriousEggroll". Why use it? You might find certain games need adjustments not currently in the official Proton and Proton GE can make them run "out of the box". Proton-5.9-GE-3-ST is the brand new release aimed to now be the stable Proton GE release. It pulls in tons of fixes to help various Windows games run on Linux including GTA V, Metal Gear Solid V: Ground Zeroes, Planet Zoo, Jurassic World: Evolution, Origin client fixes and much more. Read more

COVID-19 has not stalled Linux development

Linus Torvalds and Dirk Hohndel have been telling anyone who will listen that while COVID-19 has slowed down many technologies, while speeding up other tech developments, it hasn't affected Linux development much at all. Torvalds said that none of his co-developers have been hugely impacted either. “I was worried for a while because one of our developers was offline for a month or two.... [But,] it turned out that it was just RSI [repetitive strain injury], and RSI is kind of an occupational hazard to deal with." He added. "One of the things that is so interesting about the Linux community is how much it has always been email-based and remote, how rarely we get together in person.." Torvalds took time out to praise his new AMD Threadripper 3970x-based processor-powered developer desktop. Torvalds later added that, although he had been concerned about its fan noise it actually works well for him. Torvalds moved to this new homebrew computer because he needed the speed. Read more