Earlier this month, Linux 5.13 disabled Intel’s ENQCMD feature for upcoming Xeon “Sapphire Rapids” processors because the kernel software code surrounding it was deemed “broken beyond repair.” Most of the recent fixes submitted by Intel regarding the kernel code rework for the upcoming CPU functionality have turned out to be rather thorny having already been put in place and so another batch of urgent x86 fixes were sent out this morning.
Over the past year, numerous low-level x86 (x86_64) kernel code changes around Intel’s Linux 5.13 have disabled Intel’s ENQCMD feature for future Xeon “Sapphire Rapids” processors because the code kernel software surrounding it was deemed “broken beyond repair”. This stems from changes made by Intel over the past year around XSAVES supervision states and kernel readiness for Application Flow Control (CET) technology, Intel Processor Trace (PT), ENQCMD with Sapphire Rapids and other features requiring extended supervision (xstate) manipulation.
Earlier this month, when the Intel ENQCMD feature was disabled, the kernel developer discovered its bad form while “digesting the XSAVE-related horrors that were introduced with the supervisor / user separation, the recent addition of the functionality related to ENQCMD appeared on radar and turned out to be broken in the same way. ” It was noted that the kernel code was “broken beyond repair” and will need to be reworked for a future version of the kernel, at which time it can be reactivated.
Now, there is more fallout dealt with by the kernel changes made by Intel’s FPU / XSTATE. Longtime developer Borislav Petkov (SUSE) noted in today’s pull request, “A first set of urgent fixes for the FPU / XSTATE management mess ^ W code. (There is a lot more in the pipe).”
Among the current fixes, it is to prevent corruption of the XSTATE buffer in signal handling by validating what is copied from user space, by invalidating the FPU registers kept in case of XRSTORE failure, by restoring the appropriate PKRU value in case the user space has changed it and resetting the FPU State when signal restoration fails.
Given the poor form of this code and being processed only after it has already been integrated into the kernel, this raises further questions regarding the kernel code review processes. In any case at least the problems are discovered now.
These fixes are now on their way for the major release of Linux 5.13 ahead of today’s 5.13-rc7 release. We’ll see what “much more in the pipe” means in the next few days for Linux 5.13, or what larger changes might be diverted to the 5.14 cycle.