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

[darkbasic]

The photo perfectly depicts what Intel CPUs truly deserve.

[CommunityMember]

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.

[sa666666]

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.

[CommunityMember]

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.

[waxhead]

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

[Dr_ST]

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