How to disable Specter protection: a new parameter was added to the Linux kernel
A flag has appeared in the Linux kernel that disables protection against Specter v4 vulnerabilities in all child processes running on the server. More information about the new parameter - under the cut.
/ Flickr / Rie H / CC BY / Photo changed
The Specter processor vulnerability group first became known in early 2018, and over the following months, this family was replenished with new security holes. Vulnerabilities are related to the operation of systems that increase the performance of processors — speculative writing and reading and predicting transitions — and allow attackers to bypass memory isolation mechanisms in processors from Intel and AMD.
')
To close vulnerabilities, operating system developers release patches, but installing them often reduces the speed of servers. For example, on Linux machines, some Specter patches reduce performance by 30–50%.
The system administrators were unhappy with the problem, especially in large data centers. They began to ask Linux kernel developers to selectively disable protection from Specter. Some of the discovered vulnerabilities are only theoretical, and in a number of systems, in principle, they cannot cause harm. For example, render farms and offline supercomputers are disconnected from the Internet, so they are not afraid of malicious code injections.
The Linux team went to meet the users and introduced several features that disable protection against Specter v1, v2 vulnerabilities (we will discuss more about them later) and v4. The last of them was presented at the beginning of February for all current kernel versions - this is the new PR_SPEC_DISABLE_NOEXEC flag.
Specter v4’s vulnerability is called Speculative Store Bypass. It allows malware to gain access to the results of speculative calculations, which the processor has previously discarded as unnecessary.
This situation occurs when the CPU in turn performs read and write operations using indirect addressing. Reading occurs more often than writing, and the processor can use data from the memory to determine the read address, without waiting for the calculation of the indirect addressing offset. If, after calculating the offset, an intersection of memory areas for writing and reading is detected (that is, the reading was not performed from that area), then the second operation is performed again, and the speculative result is discarded.
In theory, it turns out that if an attacker knows the addresses and structure of memory cells, he can extract data from them, such as encryption keys.
The patch for Specter v4 appeared in the Linux kernel a few days after the publication of information about the vulnerability - it by default turned off the memory disambiguation feature, which allowed the extraordinary execution of commands. But it slowed down the processor I / O by 10–40%.
/ Flickr / Rie H / CC BY-SA
And in early June 2018 in the release of the kernel 4.17, the opportunity to disable this protection appeared. There was one problem: the parameter was not passed from the parent to the child process. For them, protection had to be manually disabled, which caused inconvenience to system administrators. But in early February, the kernel developers implemented the PR_SPEC_DISABLE_NOEXEC flag. It complements the previous function and copies the mode of the patch from Specter v4 from the parent process to the child ones. PR_SPEC_DISABLE_NOEXEC is part of prctl, and you can enable it when you start any new process.
In the mailing list for Linux kernel developers, Waiman Long from Red Hat wrote about the introduction of a new flag. According to him, protection against Specter v4 significantly affects the performance of applications that perform many write operations, such as databases. PR_SPEC_DISABLE_NOEXEC will help automate the patch disconnection check and speed up servers with a large number of simultaneously running processes.
At the same time, members of the IT community note that in certain situations, careless handling of a new flag can lead to unpleasant consequences.
In addition to the PR_SPEC_DISABLE_NOEXEC flag, there are other parameters in the Linux kernel that disable Specter protection.
The first one is nospectre_v2 . The function disables the Specter v2 protection, which allows attackers to use a conversion prediction block to “force” the processor to speculatively perform an operation on a specific memory module. To protect the patch disables the function of indirect prediction of transitions and prohibits the transfer of the information obtained between threads in the same CPU core.
Disabling protection leads to an increase in processor performance by 30% - that is how it fell after installing the Specter v2 patch. The new function was supported even by Linux creator Linus Torvalds (Linus Torvalds). According to him, vulnerability threatens only processors with the SMT function, in this particular case it will be more profitable to disable it.
The second parameter, nospectre_v1 , disables protection from Specter’s first option. Hackers with the help of malware can force the processor to predict the result of the conditional transition incorrectly and discard the results of speculative calculations in the memory area that hackers need. Although the v1 patch does not significantly affect performance (according to some data , a decrease in processor speed can be completely neglected), the developers asked to add the ability to disable this protection in the kernel. This allowed us to simplify the structure of networks isolated from external access.
The Linux kernel community remains true to the idea of ​​a free choice that Linus Torvalds laid at the very beginning: users are themselves responsible for balancing the security and performance of Linux systems. Therefore, we should expect that when new vulnerabilities similar to Specter are detected in the kernel, there will be both a patch and the ability to disable it.
/ Flickr / Rie H / CC BY / Photo changed
Why do I need to disable protection
The Specter processor vulnerability group first became known in early 2018, and over the following months, this family was replenished with new security holes. Vulnerabilities are related to the operation of systems that increase the performance of processors — speculative writing and reading and predicting transitions — and allow attackers to bypass memory isolation mechanisms in processors from Intel and AMD.
')
To close vulnerabilities, operating system developers release patches, but installing them often reduces the speed of servers. For example, on Linux machines, some Specter patches reduce performance by 30–50%.
The system administrators were unhappy with the problem, especially in large data centers. They began to ask Linux kernel developers to selectively disable protection from Specter. Some of the discovered vulnerabilities are only theoretical, and in a number of systems, in principle, they cannot cause harm. For example, render farms and offline supercomputers are disconnected from the Internet, so they are not afraid of malicious code injections.
The Linux team went to meet the users and introduced several features that disable protection against Specter v1, v2 vulnerabilities (we will discuss more about them later) and v4. The last of them was presented at the beginning of February for all current kernel versions - this is the new PR_SPEC_DISABLE_NOEXEC flag.
What and why disables the function
Specter v4’s vulnerability is called Speculative Store Bypass. It allows malware to gain access to the results of speculative calculations, which the processor has previously discarded as unnecessary.
This situation occurs when the CPU in turn performs read and write operations using indirect addressing. Reading occurs more often than writing, and the processor can use data from the memory to determine the read address, without waiting for the calculation of the indirect addressing offset. If, after calculating the offset, an intersection of memory areas for writing and reading is detected (that is, the reading was not performed from that area), then the second operation is performed again, and the speculative result is discarded.
In theory, it turns out that if an attacker knows the addresses and structure of memory cells, he can extract data from them, such as encryption keys.
The patch for Specter v4 appeared in the Linux kernel a few days after the publication of information about the vulnerability - it by default turned off the memory disambiguation feature, which allowed the extraordinary execution of commands. But it slowed down the processor I / O by 10–40%.
/ Flickr / Rie H / CC BY-SA
And in early June 2018 in the release of the kernel 4.17, the opportunity to disable this protection appeared. There was one problem: the parameter was not passed from the parent to the child process. For them, protection had to be manually disabled, which caused inconvenience to system administrators. But in early February, the kernel developers implemented the PR_SPEC_DISABLE_NOEXEC flag. It complements the previous function and copies the mode of the patch from Specter v4 from the parent process to the child ones. PR_SPEC_DISABLE_NOEXEC is part of prctl, and you can enable it when you start any new process.
What do experts say
In the mailing list for Linux kernel developers, Waiman Long from Red Hat wrote about the introduction of a new flag. According to him, protection against Specter v4 significantly affects the performance of applications that perform many write operations, such as databases. PR_SPEC_DISABLE_NOEXEC will help automate the patch disconnection check and speed up servers with a large number of simultaneously running processes.
At the same time, members of the IT community note that in certain situations, careless handling of a new flag can lead to unpleasant consequences.
"It is worth noting that in some environments it is not safe to disable protection against Specter v4," said Sergey Belkin, head of the development department at IaaS provider 1cloud.ru . - These include, for example, web services using Java and JavaScript. Deploying the managed code of the contents of the control process can be fatal to the security of the application. "
About other Specter patches in the Linux kernel
In addition to the PR_SPEC_DISABLE_NOEXEC flag, there are other parameters in the Linux kernel that disable Specter protection.
The first one is nospectre_v2 . The function disables the Specter v2 protection, which allows attackers to use a conversion prediction block to “force” the processor to speculatively perform an operation on a specific memory module. To protect the patch disables the function of indirect prediction of transitions and prohibits the transfer of the information obtained between threads in the same CPU core.
Disabling protection leads to an increase in processor performance by 30% - that is how it fell after installing the Specter v2 patch. The new function was supported even by Linux creator Linus Torvalds (Linus Torvalds). According to him, vulnerability threatens only processors with the SMT function, in this particular case it will be more profitable to disable it.
The second parameter, nospectre_v1 , disables protection from Specter’s first option. Hackers with the help of malware can force the processor to predict the result of the conditional transition incorrectly and discard the results of speculative calculations in the memory area that hackers need. Although the v1 patch does not significantly affect performance (according to some data , a decrease in processor speed can be completely neglected), the developers asked to add the ability to disable this protection in the kernel. This allowed us to simplify the structure of networks isolated from external access.
The Linux kernel community remains true to the idea of ​​a free choice that Linus Torvalds laid at the very beginning: users are themselves responsible for balancing the security and performance of Linux systems. Therefore, we should expect that when new vulnerabilities similar to Specter are detected in the kernel, there will be both a patch and the ability to disable it.
Posts from our corporate blog:
Source: https://habr.com/ru/post/442140/
All Articles