'Beyond stupid': Linus Torvalds trashes 5.8 Linux kernel patch over opt-in Intel CPU bug mitigation

[erek]

Trashed. Respectable insight from Linus

"The discussion reveals the frustration among the kernel maintainers over the difficulty of keeping Linux secure in the face of CPU bugs, and the fact that these cache-related attacks have so many variations. Referencing a past software fallback for clearing the data buffers to address am MDS (Microarchitectural Data Sampling) bug, Torvalds said: "That one turned out to be not only incredibly expensive, but it didn't work reliably anyway, and was really only written for one microarchitecture."

Amazon as a public cloud provider is particularly sensitive to these data-stealing vulnerabilities because of the implications if one customer were able to spy on the data belonging to another, or data on a virtual machine host. Another AWS engineer, Benjamin Herrenschmidt, entered the discussion to explain: "These patches aren't trying to solve problems happening inside of a customer VM running SMT nor are they about protecting VMs against other VMs on the same system." AWS has a vast range of services all of which need to be secure.

Torvalds said that he is "more than happy to be educated on why I'm wrong" but that "for now I'm unpulling it for lack of data." If AWS can convince him of the value of the patch, it may return. ®"

https://www.theregister.com/2020/06/02/linus_torvalds_kernel_intel_patch/

 

[SecretStash]

AWS profiting off the backs of open source pushing newb code that hopefully goes in. When it's just going to make every else's life more miserable for their all important fix that isn't needed, especially for certain systems. Ah well, at least they are the 3rd tier of supporters to the linux foundation.

 

[1_rick]

I may be mixing up a couple of these vulnerabilities, but aren't the L1 cache vulns mostly there because of HT? That is, one thread in a core is able to snoop cache lines the other thread is using? Isn't that why some of the first mitigations involved turning HT off?

ISTM that just stopping there would have made more sense than flushing the L1 cache constantly, although I guess either way you wind up with a performance hit.

 

[Red Falcon]

I may be mixing up a couple of these vulnerabilities, but aren't the L1 cache vulns mostly there because of HT? That is, one thread in a core is able to snoop cache lines the other thread is using? Isn't that why some of the first mitigations involved turning HT off?

ISTM that just stopping there would have made more sense than flushing the L1 cache constantly, although I guess either way you wind up with a performance hit.

Yes, exactly, it isn't a flaw with all CPU ISA's SMT implementation, just Intel's HyperThreading, which in order to help mitigate this, needs to be disabled.

 

[/dev/null]

on my vm servers @ home I turned HT off. Even though that makes it dual socket 8 cores, it's more than enough to run my infra. On my desktops I reboot/turn off if I'm going to play games, reboot turn back on if I'm doing stuff like web browsing.

I think most of that is going to go away once I finish moving stuff over to my 3900x box.....what an upgrade! (4770k -> 3900x)

 

[Lakados]

on my vm servers @ home I turned HT off. Even though that makes it dual socket 8 cores, it's more than enough to run my infra. On my desktops I reboot/turn off if I'm going to play games, reboot turn back on if I'm doing stuff like web browsing.

I think most of that is going to go away once I finish moving stuff over to my 3900x box.....what an upgrade! (4770k -> 3900x)

All my critical stuff will be moved over to AMD in the next month, Internet facing Intel systems now only have public and non secure data stored on them. It's the only way to be safe.