Announcement

Collapse
No announcement yet.

Linux Developers Discuss Flushing L1 Cache On Context Switches In Light Of Vulnerabilities

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dr_ST
    replied
    Originally posted by CommunityMember View Post

    Depending on the specific implementation, HT can have substantial performance disadvantages in some computationally intensive applications (as a thread swap results in the flushing of caches being used by other threads). That is obviously something very targeted to specific codes, but the HPC market has those specific codes, and most competent HPC computing centers have run the tests for their codes to know what (HT on, HT off) is better.
    Well the point is I was the guy doing the benchmark for my research purpose, and on these specific codes, HT was useful (GROMACS for instance, or virtual docking experiments) :-) Yes, that means I could work on the coronavirus (but it is not my main research of area).

    Leave a comment:


  • waxhead
    replied
    I have not looked into the details of the L1 cache flush pr. context, but the first impression is that this is a GLOBAL feature. The first thing that crosses my mind is , why not set this on a per. cpu / socket basis so that you effectively have a safe and/or unsafe scheduling domain. This means that you could have set the processor affinity for unsecure programs to run on the CPU group that flushes the L1 cache while things that you trust could run without mitigations on other CPU's. Servers today usually have a handful of CPU cores to play with , and even if you did not have that many CPU's to pay with you could probably reduce some of the performance impact by modifying the scheduler to group programs safe/unsafe so that you would not have to flush the L1 cache as often...

    Leave a comment:


  • CommunityMember
    replied
    Originally posted by Dr_ST View Post
    I'm a computing researcher (in biology) and for many years I'm told that in large computing centers they always disable HT (since 2007-8 or so)
    Depending on the specific implementation, HT can have substantial performance disadvantages in some computationally intensive applications (as a thread swap results in the flushing of caches being used by other threads). That is obviously something very targeted to specific codes, but the HPC market has those specific codes, and most competent HPC computing centers have run the tests for their codes to know what (HT on, HT off) is better.

    Leave a comment:


  • sa666666
    replied
    As long as something like this can be disabled for AMD CPUs, then I would have no issues with it. Intel have long wanted to bring in 'fixes' that make performance poor on all platforms, so it doesn't look as bad for them. Other processors that don't have flaws shouldn't have to suffer the performance degradation just to make Intel work better. If something is an Intel-only issue, it should only affect them.

    Leave a comment:


  • CommunityMember
    replied
    Originally posted by Danny3 View Post
    Oh come on, not another performance crippling change. ....
    The cloud providers do need those protections, because they depend on the operational efficiencies of hyperscalling. And, like it or not, the hyperscallers run what people think of as the Internet.

    In my opinion. do all the security enhancement you want, but stop enabling them by default !
    If you are not tall enough to understand how, and in what conditions, to unbuckle the seat belts, well, perhaps one does need them after all. Some less competent people are not going to know anything about anything (the computer is a toaster, not something they understand), so the default should typically be to default to safety.
    Last edited by CommunityMember; 19 March 2020, 02:14 PM.

    Leave a comment:


  • darkbasic
    replied
    The photo perfectly depicts what Intel CPUs truly deserve.

    Leave a comment:


  • Dr_ST
    replied
    Originally posted by ermo View Post
    What is the reason that not as many vulnerabilities targeting AMD have yet been published? Even thought I've only been buying AMD hardware for the past 5+ years, I have a hard time believing that AMD's products are just that much more fundamentally secure?

    Is it simply a question of market share at this point, in the sense that it is more valuable to undertake vulnerability research on intel products?
    I'd say at a certain point Intel lagged in performance and started seeing market share diminution (AMD Athlon, and the 64-bits race), so they had to find "a way back". And BAM, "HyperThreading came"... This was just simple cheating from my Point Of View.

    I'm a computing researcher (in biology) and for many years I'm told that in large computing centers they always disable HT (since 2007-8 or so) so my guess is that some of these vulnerabilites are known "for years", but know the public audience is wider, that's all.

    Why AMD is less affected? by design, I'd say :-)

    Leave a comment:


  • skeevy420
    replied
    Originally posted by Danny3 View Post
    Oh come on, not another performance crippling change.
    I'm tired of these "In the name of security..."
    I bet there are 1000 more things we can do here, clear / erase every cache after each instruction, encrypt / decrypt, but come one not everyone has supercomputers or Threadrippers at home that can handle everything you throw at it.

    In my opinion. do all the security enhancement you want, but stop enabling them by default !
    Just leave the people who need NASA level security to enable them themselves.
    I'm gonna assume you meant NSA, not NASA

    Leave a comment:


  • Emmanuel Deloget
    replied
    Originally posted by Danny3 View Post
    Oh come on, not another performance crippling change.
    I'm tired of these "In the name of security..."
    I bet there are 1000 more things we can do here, clear / erase every cache after each instruction, encrypt / decrypt, but come one not everyone has supercomputers or Threadrippers at home that can handle everything you throw at it.

    In my opinion. do all the security enhancement you want, but stop enabling them by default !
    Just leave the people who need NASA level security to enable them themselves.
    As I understand it, the final implementation (if it ever reach this stage) would require a specific process to call prctl() to set the bit that will force a L1D flush on context swtiches. So in this case it seems that you'll get what you want: the slowdown will only impact the applications that requires it (so it should be barely noticeable).

    Leave a comment:


  • willmore
    replied
    Why do I get the feeling that there's yet another horrible vulnerabilty that's known by a few insiders who are quickly working to patch it and that this is some of the early fruits of that effort?

    Leave a comment:

Working...
X