Linux 5.13 Lands More Fixes To The Mucked Up FPU/XSTATE Handling Mess

Written by Michael Larabel in Intel on 20 June 2021 at 07:23 AM EDT. 10 Comments
INTEL
Earlier this month Linux 5.13 disabled Intel's ENQCMD functionality for upcoming Xeon "Sapphire Rapids" processors as the kernel software code around it was deemed "broken beyond repair". More of the recent Intel-submitted patches around reworking kernel code in preparation for upcoming CPU features has been found to be rather hairy after already being mainlined and thus another batch of urgent x86 fixes were sent in this morning.

Over the past year has been a lot of low-level x86 (x86_64) kernel code changes around Intel's Linux 5.13 disabled Intel's ENQCMD functionality for upcoming Xeon "Sapphire Rapids" processors as the kernel software code around it was deemed "broken beyond repair". This stems from changes contributed by Intel over the past year around XSAVES supervisor states and preparing the kernel for Control-Flow Enforcement Technology (CET), Intel Processor Trace (PT), ENQCMD with Sapphire Rapids, and other features needing supervisor extended states (xstate) handling.

Earlier this month when the Intel ENQCMD feature was disabled, the kernel developer discovered its poor shape while "digesting the XSAVE-related horrors which got introduced with the supervisor/user split, the recent addition of ENQCMD-related functionality got on the radar and turned out to be similarly broken." It was noted the kernel code was "broken beyond repair" and will need to be reworked for a future kernel release at which time it can be re-enabled.

Now there is more fallout being addressed from Intel's FPU/XSTATE handling changes to the kernel. Longtime developer Borislav Petkov (SUSE) noted in today's pull request, "A first set of urgent fixes to the FPU/XSTATE handling mess^W code. (There's a lot more in the pipe)."

Among the fixes today are around preventing corruption of the XSTATE buffer in signal handling by validating what is being copied from user-space, invalidating preserved FPU registers on XRSTORE failure, restoring the proper PKRU value in case user-space modified it, and resetting the FPU state when signal restoration fails.


Given how bad of shape this code is reportedly in and only being addressed after already being mainlined in the kernel, it does raise further questions around the kernel's code review processes. In any case at least the issues are being uncovered now.

These fixes are now on their way to mainline Linux 5.13 ahead of today's 5.13-rc7 release. We'll see what the "a lot more in the pipe" amounts to in the coming days still for Linux 5.13 or what harrier changes might be diverted to the 5.14 cycle.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via MichaelLarabel.com.

Popular News This Week