Linux kernel developers have added protection against problematic Intel Granite Rapids microcode that could cause Xeon 6 servers to throw machine check exceptions.
According to Phoronix, the fix landed in Linux 7.3-rc4 and prevents certain microcode revisions from loading unless the processor has already passed an essential intermediate update. Chipzilla’s Granite Rapids microcode revision 0x1000405 introduced internal changes needed before later revisions can be loaded safely.
Linux will now refuse to load revision 0x1000405 or newer if the machine has not previously been updated to 0x1000405. The protection applies to both early and late microcode loading. Without that sequencing, affected Xeon 6 systems risk a machine check exception, which is generally not the sort of excitement administrators want from a firmware update.
Intel lists the problem as GNR98 in its specification update and says it involves changes to the inter-microcode communication interface. A second issue, GNR101, concerns Granite Rapids microcode revision 0x1000423, which has an incorrect minimum runtime microcode update revision.
The kernel change has been merged into Linux 7.3 and marked for backporting to existing stable kernels, so the protection will not be confined to users living on the bleeding edge. The same batch of x86 fixes tackles another Chipzilla headache involving Flexible Return and Event Delivery on Panther Lake processors, which could make some Windows games crash or freeze under Wine and Steam Play.
Kernel developers have dealt with a separate problem involving CONFIG_X86_NATIVE_CPU, where -march=native builds on upcoming Intel processors could accidentally use Advanced Performance Extensions before Linux was ready for them.
Those builds could generate instructions using APX extended general-purpose registers R16 through R31 and cause trouble on Intel engineering systems. Linux now explicitly blocks APX and EGPR use in native-optimised kernel builds until proper kernel support is ready.
