News: 1591100360

Linus Torvalds has removed a patch in the next release of the Linux kernel intended to provide additional opt-in mitigation of attacks against the L1 data (L1D) CPU cache.

The [1]patch from AWS engineer Balbir Singh was to 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 vulnerabilities, to flush their L1D on being switched out. This protects their data from being snooped or leaked via side channels after the task has context switched out."

Snoop-assisted [2]L1 data sampling is one of a [3]family of vulnerabilities in Intel microprocessors where malware may be able to infer private and sensitive data via inspecting the cache. "Snoop-assisted L1D sampling requires the snoop to hit a modified cache line in the exact same single core clock cycle window as the faulting/assisting/aborting load," explains Chipzilla.

Clearing the cache whenever the active thread or process switches out attempts to mitigate this and other potential threats, but harms performance.

The patch was added to the code for the 5.8 kernel, which will be the next release, but [4]removed after review by Torvalds. "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'," he said. "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 CPUs that don't need it and configurations where it's completely pointless'.

"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' … I do not want the kernel to do things that seem to be "beyond stupid".

Meltdown The Sequel strikes Intel chips – and full mitigation against data-meddling LVI flaw will slash performance [5]READ MORE

There are plenty of nuances here. One of Torvald's points is that if SMT (simultaneous multi-threading or "hyper threading") is enabled then flushing the cache "is crazy, since an attacker would just sit on a sibling core and attack the L1 contents *before* the task switch happens," he said. In this scenario, "it's just an incredibly stupid waste of time and effort to do that, and I can see some poor hapless ssh developer saying 'yes, I should enable this thing because ssh is very special', and then ssh just starts wasting time on something that doesn't actually help." He added that the code is hard to follow, saying "some of the code scares me."

Another question is whether it makes sense to do this mitigation at a low level when it may not matter, because all the processes belong to the same user. "Context switch in itself isn't really relevant as a security domain transfer, but it *is* relevant in the sense that switching from one user to another is a sign of 'uhhuh, now maybe I should be careful when returning to user mode'," said Torvalds.

Singh replied: "I am not so sure. A user can host multiple tasks and if one of them was compromised, it would be bad to let it allow the leak to happen. For example if the plugin in a browser could leak a security key of a secure session, that would be bad."

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 [6]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. ®



[1] https://lkml.kernel.org/lkml/87mu7akwdx.fsf@nanos.tec.linutronix.de/T/

[2] https://software.intel.com/security-software-guidance/software-guidance/snoop-assisted-l1-data-sampling

[3] https://www.theregister.com/2020/03/10/lvi_intel_cpu_attack/

[4] https://lore.kernel.org/lkml/CAHk-=wgXf_wQ9zrJKv2Hy4EpEbLuqty-Cjbs2u00gm7XcYHBfw@mail.gmail.com/

[5] https://www.theregister.com/2020/03/10/lvi_intel_cpu_attack/

[6] https://lore.kernel.org/lkml/b159ba4c53fcf04cc4eb747c45e1d4d2d83310a3.camel@kernel.crashing.org/