Intel and AMD engineers rush to save Linux 6.13 after dodgy Microsoft tweak
- Reference: 1736863327
- News link: https://www.theregister.co.uk/2025/01/14/microsoft_linux_change_pulled/
- Source link:
The change, made in the autumn, was a useful improvement at face value. It was a modification to Linux x86_64 to use large read-only execute (ROX) pages for caching executable pages. The theory was that the alteration would result in increased performance.
However, the code caused problems on some setups and an urgent patch from Intel's Peter Zijlstra was committed yesterday to disable it. The stable release of the 6.13 kernel was due this coming weekend.
[1]
Zijlstra [2]wrote : "The whole module_writable_address() nonsense made a giant mess of alternative.c , not to mention it still contains bugs -- notable (sic) some of the CFI variants crash and burn.
[3]
[4]
Control Flow Integrity (CFI) is an anti-malware technology aimed at preventing attackers from redirecting the control flow of a program. The change can cause issues on some CFI-enabled setups and [5]reports have included Intel Alder Lake-powered machines failing to resume from hibernation.
Zijlstra said the Microsoft engineer "has been working on patches to clean all this up again, but given the current state of things, this stuff just isn't ready. Disable for now, let's try again next cycle."
[6]
The offending source is still present, but won't be included in the upcoming stable kernel build.
[7]Absolute Linux has reached the end – where to next?
[8]Linus Torvalds offers to build guitar effects pedal for kernel developer
[9]Google and Linux Foundation form Chromium love club
[10]Public developer spats put bcachefs at risk in Linux
AMD engineer Borislav Petkov noted that the Linux x86_64 maintainers had not signed off on the change, [11]commenting : "I just love it how this went in without a single x86 maintainer Ack, it broke a bunch of things and then it is still there instead of getting reverted. Let's not do this again please."
Microsoft is notable for dubious quality control standards regarding releases of its flagship operating system, Windows. That one of its engineers should drop some dodgy code into the Linux kernel is not hugely surprising, and the unfortunate individual is not the first and will not be the last to do so, regardless of their employer.
However, the processes that allowed it to remain in the build this close to public release will be a concern. While it is amusing that engineers from both Intel and AMD were involved in dealing with the issues arising from the contribution of a Microsoft engineer, and the problem never reached the stable release, it is concerning. Petkov will not be the only one wondering how the change made it in without a review by the Linux x86/x86_64 maintainers. ®
Get our [12]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z4aYNTK4FuHbq-6fef58FgAAANA&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=a9bbe341333109465605e8733bab0b573cddcc8c
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z4aYNTK4FuHbq-6fef58FgAAANA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z4aYNTK4FuHbq-6fef58FgAAANA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://lore.kernel.org/lkml/Z4U1HGUfFLJH8Y55@intel.com/#t
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z4aYNTK4FuHbq-6fef58FgAAANA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://www.theregister.com/2025/01/14/the_end_of_absolute_linux/
[8] https://www.theregister.com/2025/01/13/linus_torvalds_guitar_pedal_offer/
[9] https://www.theregister.com/2025/01/10/google_linux_foundation_chromium/
[10] https://www.theregister.com/2024/11/22/bcachefs_linux/
[11] https://lore.kernel.org/lkml/20250113115151.GDZ4T-VwIq_6ZafRE4@fat_crate.local/
[12] https://whitepapers.theregister.com/
Re: Surprise?
All your kernels are belong to us...
Intel x86_64 is part of the problem
Linux has a problem with the complexity of the x86_64 hardware ecosystem. Devs well versed in older Intel CPU’s are aging out. Linux devs generally have current hardware, and are not likely to make understanding older Intel CPUs a priority, so it should not be surprising when someone adds something that breaks linux on older systems. This adds to the Linux dev and distro support workloads.
Re: Intel x86_64 is part of the problem
It is surprising when it skips all review and checks and just lands and ships though.
Did we lean nothing from xz ?
Re: Intel x86_64 is part of the problem
Not to be to picky about it...But it sounds like Windows also "has a problem with the complexity of the x86_64 hardware ecosystem".
Few people use the raw Kernel.
Few people use the raw Linux kernel - they get them from their kernel distribution and which has undergone more testing and is not bleeding edge.
Of course, I'm the sort that downloads the kernel sources and compiles them myself - something that I've been doing for 20+ years and never a problem. I get the near bleeding edge kernels - ones that have been out a few weeks and have several revisions done to it.
Well none of the Microsoft guys are going to be getting the guitar pedal.
A sad trombone, more like.
Extra checks please!!!
On Microsoft submissions given "Microsoft is notable for dubious quality control standards regarding releases of its flagship operating system, Windows."
Considering how Microsoft engineers bork the Microsoft Windows OS, why on earth isn't code from MS engineers peer reviewed and then reviewed again? Jesus H Christ, no code from MS should be taken at face value. MS has form.
No code ever should be merged without review, I wonder how that even happened? I thought Linux had a pretty strict review mechanism.
My guess would be that it was reviewed, but not by the right people…
Surprise?
Evidently Microsoft are exporting their Windows prowess into other parts of the world.