Freeze exception request: x86 microcode support for Wheezy
This email is related to bug #681352 (amd64-microcode), and to an
yet-unfilled freeze exception request for intel-microcode.
non-free stable and non-free wheezy are currently seriously lacking in
microcode support. It is worth notice that nearly all recent Intel
_and_ AMD processors have been issued microcode updates, quite often
fixing relevant issues.
Stable lacks support for AMD system processors in userspace entirely,
and deprecated, half-useful support for Intel system processors. Wheezy
currently has half-done userspace support for AMD system processors that
requires manual intervention to even work, and the same crap as stable
for Intel system processors.
These shortcomings have been fixed in non-free unstable for both Intel
and AMD microcode packages.
A simple initramfs helper, along with documentation for those who
compile their own kernels and don't use an initramfs, was added to
amd64-microcode in unstable. It manages to load processor microcode as
early as it is possible for the current Wheezy kernel. The freeze
exception (unblock request) is in bug #681352, along with the debdiff.
This initramfs helper, which is also used on the updated intel-microcode
packages, is compatible with past and current kernels (tested in
2.6.32.x stable, 3.0.x stable, 3.2.x stable, 3.4.x stable), with the
soon-to-be-issued stable fix for the microcode core that accepts
requests only for the BSP (bootstrap processor) -- tested with 3.0 and
3.2 + fix backport, and with the upcoming per-system microcode sysfs ABI
that does away/deprecates the current per-core sysfs ABI.
Fixing intel-microcode [properly] was _much_ harder. The ABI used by
microcode.ctl (/dev/cpu/microcode) has been deprecated in the kernel for
_years_ and will be removed sooner or later. Switching to the sysfs /
firmware-loader based ABI requires new userspace, and in fact the new
intel-microcode package declares a "breaks: microcode.ctl" because the
very microcode data format required by the new ABI is unsupported by
microcode.ctl.
Since it is incredibly hard to deal with Intel microcode release
management, I had to actually write a heavy-duty tool (iucode-tool,
already accepted into Wheezy contrib) to even _know_ WTF I was pushing
to users at every new upstream microcode release. I've been using it
for a while now. This tool is also used to generate the
firmware-loader-compatible binary files split by processor
family-model-stepping required to update Intel processor microcode.
The same initrd helper used in amd64-microcode was also added to the
intel-microcode package. The two packages CAN BE INSTALLED AT THE SAME
TIME in a system: the helpers do not collide, and they're smart enough
to notice the duplication, and attempt the microcode update only once
during boot.
Unfortunately, Intel ships a _LOT_ of microcode. It's about 550KiB
uncompressed, split over a lot of files in /lib/firmware. This would
waste a lot of initramfs space, so, should iucode-tool also be present
in the system at update-initramfs time, the intel-microcode package will
by default install to the initramfs only the microcode for the exact
system processors found (which typically means at most 32KiB worth of
uncompressed microcode :p).
Also, using iucode-tool, it was possible to restrict the number of
microcodes shipped in the intel-microcode binary package for the amd64
arch, by removing microcodes for very old processors that do not support
64-bit mode. I also managed to salvage microcode for older processors
(Pentium II, Pentium III, Pentium-M, 1st and 2nd-gen Xeon) that Intel
did not ship anymore, but which still have Debian users.
This required a complete refactoring of the source package, and the
resulting debdiff for intel-microcode is, well, enourmous. Mostly
because the *source* package now ships every Intel microcode ".dat" file
to date (each one is ~1.5MiB in size), in order to find the relevant
microcodes for older processors. To keep the source package
_compressed_ size under control, I switched to XZ compression, and the
compressed source package is still < 1MiB.
The packages in unstable are well tested, and I'd really appreciate if
the Wheezy release managers would grant freeze exceptions for
amd64-microcode and intel-microcode.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: