Linux 5.13 Lands More Fixes To The Mucked Up FPU/XSTATE Handling Mess
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.
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.
10 Comments