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

Intel DG1 Graphics Card Bring-Up On Linux Continues - Latest Bits For Local Memory

Recently there have been a lot of open-source Linux patches flowing concerning Intel's bring-up of their DG1 discrete graphics card for developers. That work continued this week with the latest patches in wiring up LMEM support. Among the recent Intel DG1 patches for Linux recently have been on the media driver front, compute runtime with OpenCL and Level Zero and as part of that the IGC support, and then most importantly the necessary Linux kernel changes building off the existing Gen12/Xe graphics support. Read more Also: Intel AMX Support Lands In The GNU Assembler

Programming: GStreamer, Drat, RasPi, Python

KF6 Progress Report: Almost Bastille Day (July) Edition

So the world has been hectic lately, dunno if you’ve seen the news, but that means that I didn’t publish an update since my previous KF6 progress report back in February! Now that the lock down has been (temporarily?) lifted where I live and that things are a bit less crazy, it’s time for an update. An actual Qt 6 is not published yet and we didn’t branch for KF6 yet either. Still as can be seen on the KF6 Workboard there are plenty of tasks in our backlog which can be acted upon now. No need to wait to participate, all the work done now will make the transition to KF6 easier later on anyway. What has been done since the last post? On the workboard, we currently have 22 tasks in progress and 4 tasks done. Clearly that’s not a huge activity in more than four months but the state of the world might explain it in part. Obviously with so little tasks done, they mostly revolve around our usual suspects. If you fancy becoming one of the unsung heroes of KDE, come and help working tasks from the KF6 Workboard! More hands are needed and right now is a good time to discover it and get into it than when Qt6 will be released. Indeed, when Qt6 will be around it will be much less quiet around here. :-) Read more

today's howtos