Originally published on CSDN (ID: CSDNnews)
Compiled by Su Ma
Recently, the Linux development team announced that they have successfully completed the development of the Linux kernel version 6.13 rc7, and barring any unforeseen circumstances, the final stable version will be officially released next week.
As a key figure in Linux, Linus Torvalds also mentioned in the weekly Linux kernel development status report:
At the beginning of this week, things seemed a bit quiet, but then progress picked up, and after two quiet holiday weeks, our pace has fully resumed.
This rc7 is slightly larger than usual, but considering the timing, it is basically in line with my expectations, and there is nothing particularly outstanding. Everything looks normal from the modification statistics, and the additional brief log content shows no anomalies.
Therefore, unless something unexpected happens next week, I expect to release the final version 6.13 as scheduled.
Meanwhile, a cheerful Linus revealed that in his spare time, he enjoys building Lego sets and assembling guitar effect pedal kits. He jokingly mentioned that he was looking for an excuse to continue crafting, so he wanted to see if there were any “unlucky” kernel developers who would like one, which he would personally make and give to the lucky winner.
While Linus was celebrating the completion of his work, on the other side, Microsoft developers made a blunder while contributing code. If it weren’t for Intel and AMD engineers discovering and stopping it at the last moment, this code could have potentially disrupted Linux 6.13 on certain systems.
1. Improper Code Modification Nearly Causes Disaster
The changes made by Microsoft engineers primarily involved a kernel configuration named ARCH_HAS_EXECMEM_ROX, which allows executable memory (EXECMEM) to be cached with read-only execute (ROX) permissions.
This feature, intended as a performance enhancement, was planned to be introduced in Linux 6.13 for the x86_64/AMD64 architecture, specifically targeting 64-bit AMD and Intel processors.
However, this change was pushed online without formal confirmation (Ack) from the x86 kernel maintainers, resulting in the disruption of control flow integrity (CFI) features on these CPUs.
2. Fortunately, Intel and AMD Engineers Discovered It in Time
In response, Intel engineer Peter Zijlstra urgently submitted a request to revert the changes related to EXECMEM_ROX support, as the feature was not ready to be pushed online. In his submission, he wrote:
“x86: Disable EXECMEM_ROX support
The entire implementation of module_writable_address() completely messed up the alternative.c file and brought numerous issues—especially some control flow integrity (CFI) features crashing directly.
Although Mike has been working hard to fix these issues, it is clear that this part of the functionality is not ready for deployment at this time.
Let’s disable it for now, and we will try again in the next cycle.”
For readers unfamiliar with it, Control-flow Enforcement Technology (CET) is an important security feature that introduces shadow stacks and indirect branch targeting (IBT).
-
Shadow Stack ensures the integrity of return addresses by comparing the normal program stack with a hardware-stored copy, thus defending against Return Oriented Programming (ROP) attacks.
-
Indirect Branch Targeting is used to protect against Call Oriented Programming (COP) or Jump Oriented Programming (JOP) attacks.
In simple terms, the shadow stack can prevent malware from hijacking the execution flow of legitimate software and prevent potentially compromised software from running by marking it.
The changes made by Microsoft engineers could lead to issues in certain configurations that enable CFI.Reports indicate that devices equipped with Intel Alder Lake processors experienced failures when resuming from sleep.
Currently, the problematic code still exists but will not be included in the upcoming stable kernel version.
AMD engineer Borislav Petkov also expressed his dissatisfaction, sarcastically stating:“I really love this kind of operation, where changes are submitted without any confirmation (Ack) from x86 maintainers, resulting in a mess, but they are not reverted. I hope this doesn’t happen again in the future.”
This has also raised many questions about why the modified code was able to go live without being reviewed by maintainers. Some netizens believe that, “Linux faces challenges in dealing with the complex x86_64 hardware ecosystem. Developers familiar with early Intel CPUs are gradually retiring, while Linux developers typically use the latest hardware, so they may not prioritize researching older Intel CPUs. Therefore, when someone adds changes that cause Linux to malfunction on older systems, it is not surprising. This situation also adds to the workload of Linux developers and distribution maintainers.”