Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about the example analysis of Linus Torvalds rejecting Intel CPU vulnerability patches, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following for you. I hope you can get something according to this article.

Linus Torvalds recently rejected a patch submitted by AWS engineers to reduce the risk of data disclosure caused by a new type of snooping attack on Intel CPU.

This new type of attack is called snooping Auxiliary L1 data sampling attack, or Snoop (CVE-2020-0550). In March, Pawel Wieczorkiewicz, a software engineer from AWS, was the first to discover the vulnerability in Intel processors, which could leak data from CPU's internal memory or cache, involving CPU, including Intel's popular Xeon and Core processors. Pawel quickly reported this issue to Intel, and the vulnerability was subsequently identified by Intel as a moderately serious vulnerability.

The new Snoop attack takes advantage of the features of Intel CPU multi-level cache, cache consistency and bus snooping. Through the first-level data cache (L1D) located in the CPU kernel, and through the "bus snooping" (bus snooping) function, which occurs when the data is modified in L1D, the data is leaked from the CPU.

From the perspective of modern CPU, computers usually adopt the design of three-level cache to improve the efficiency of CPU. The third-level cache includes L1-level cache, L2-level cache and L3-level cache. These caches are all integrated in CPU and serve as high-speed data buffers between CPU and main memory. Among them, L1 is the closest to the core of CPU, L2 is the second, and L3 is the second. In terms of running speed, L1 is the fastest, L2 is fast, and L3 is the slowest; in terms of capacity, L1 is the smallest, L2 is larger, and L3 is the largest. When performing a task, CPU will first look for the data needed in the fastest L1, can't find the next fast L2, and can't find it again. Even if there is no L3, L3 will go to memory.

In fact, the first-level cache is also divided into the first-level data cache (Data Cache,D-Cache,L1D) and the first-level instruction cache (Instruction Cache,I-Cache,L1I), which are used to store data and execute data instruction decoding, both of which can be accessed by CPU at the same time, which reduces the conflicts caused by CPU multi-core and multi-thread contention cache and improves the performance of the processor. Generally speaking, L1I and L1D of CPU have the same capacity, for example, L1 of I7-8700K is 32KB+32KB. Snoop attack is an attack method to steal data from L1D cache.

However, Intel users need not be alarmed. According to Intel officials, this new attack is "very difficult to implement" and will not disclose large amounts of data. after all, the data in the L1D cache is very limited and will only exist for a short period of time when the task is running. " We do not think that Snoop attack is a practical attack method in a trusted operating system environment, because to exploit this vulnerability, many stringent conditions need to be met at the same time, such as the attack time should coincide with the time when the user opens the program, and the data called by the program is exactly the data that the attacker wants to steal. "

After the vulnerability was disclosed, another software engineer from AWS, Balbir Singh, submitted a patch for the Linux kernel that gave Linux applications the option to automatically flush the L1D cache during task switching to reduce the risk of Snoop attacks on Linux systems.

"this patch prevents their data from being monitored or leaked through bypass at the end of the mission," Singh explained in April. " He had intended the patch to be released with version 5.8 of the Linux kernel. "if the hardware supports it, this feature will allow you to call the prctl () function based on the optional added application to flush the L1D cache left in the CPU after the task is closed."

However, Phoronix, a well-known technical testing website, pointed out that flushing the L1D cache at the end of the task will degrade the performance of CPU. Linus Torvalds, head of the Linux kernel project, believes that this will lead to a decline in CPU performance for all Linux users who use the patch (with or without Intel CPU), solemnly rejecting the patch and, as always, gossiping.

Torvalds wrote in the mailing list replying to the submission: "because in my opinion, this is basically exporting cache refresh instructions to user space and providing a way for the process to slow down others who have nothing to do with it."

"in other words, as far as I know, this is that the crazy Intel released the flawed CPU, which caused problems for the virtualized code (which I don't care too much about), but now it's completely pointless to affect Linux users who don't have these problems because of its problems."

(original text of Linus in the mailing list)

"I don't want an application to run like,'Oh, I'm a special, beautiful, delicate flower. I want to refresh every task cache on L1D, no matter what CPU I'm on, no matter whether it has vulnerabilities or not. because this application slows down not only itself, but also other applications."

After a very Linus reply, Linus's reference to virtualization is actually for AWS, and AWS, like other cloud service providers, sells virtual cpu that usually enables synchronous multithreading (simultaneous multithreading,SMT). Linus went on to point out that "with SMT enabled, task scheduling is distributed, so it would be foolish to flush the L1D cache between the end of the task and the start of the new task."

It is worth mentioning that Benjamin Herrenschmidt, the chief engineer of AWS, also added some background to the patch debate in a discussion with Ingo Molnar, a contributor to the Red Hat Linux kernel. Herrenschmidt admitted that the patch meant nothing to SMT, but urged Linux kernel developers not to "throw the baby away with the bath water" and refuted the patch because AWS wanted to sell hyperthreading as a virtual cpu. Herrenschmidt said, "these patches are not intended to solve problems within the VM of customers running SMT, nor are they intended to protect VM from other VM attacks on the same system."

In fact, this is not the first time Linus has sternly rejected patches related to Intel CPU. In early 2018, to fix the Spectre vulnerability, Intel engineers provided a patch for the indirect branch limit conjecture (indirect branch restricted speculation, IBRS) function. Linus publicly pointed out in the mailing list at the time that IBRS would significantly degrade the performance of the system, saying bluntly that the patch was "complete rubbish" and "does Intel really want to do this X-like thing?" A mouthful spits fragrance.

Just last month, Linus upgraded his personal computer and unveiled his latest mainframe configuration, replacing his CPU with AMD Ryzen Threadripper and abandoning his 15-year-old Intel processor.

After reading the above, do you have any further understanding of the example analysis of Linus Torvalds rejecting Intel CPU vulnerability patches? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.