Bug#676921: ITP: amd64-microcode -- Processor microcode firmware for AMD CPUs
On Sat, 23 Jun 2012, Ben Hutchings wrote:
> On Fri, 2012-06-22 at 16:03 -0300, Henrique de Moraes Holschuh wrote:
> > On Fri, 22 Jun 2012, Ben Hutchings wrote:
> > > On Sat, 2012-06-16 at 15:08 -0300, Henrique de Moraes Holschuh wrote:
> > > > They have to:
> > > >
> > > > 1. Issue sysfs commands to refresh running microcode
> > >
> > > With a current kernel, udev will load the firmware just as for any other
> > > device.
> >
> > Yes, it will. At boot. And only if the driver is modular. And only if
> > something specifically modprobes microcode, because it has no autoloading
> > support in kernel 3.2 and earlier (I think that support was to land in 3.5,
> > but it might already have landed in 3.4).
> >
> > So, Microcode needs to be refreshed when you upgrade the data files, and
> > also when the driver is not modular (at least last time I tested it in a 3.0
> > kernel for Intel), and that requires postinst and initramfs specific magic
> > (quite a lot for Intel, nearly none for AMD).
>
> > Backporting the autoload code is not straigthforward.
>
> I backported the general support for x86 CPU module autoloading in
> 3.2.21-1. The rest should be easy, shouldn't it?
Probably yes.
However, the microcode core also went through a large code change
because it was ported from half-braindead sysdev to a full blown device.
I am not sure if you can do the autoloading properly without that
conversion, it depends on whether the code in 3.2 generates the required
uevents and sysfs attributes, or not.
Do we have a git tree with the Debian kernel somewhere?
> > > > and update the initramfs when updated/installed.
> > >
> > > firmware-nonfree can do that (some network drivers need firmware).
> >
> > Is it amicable to special postinst code? If it is, it can take care of
> > amd64-microcode.
>
> The package template system currently only supports one optional
> postinst action, but it wouldn't be hard to extend to add others.
Let's see if I can get that to work over the weekend. I will be unable to
do any Debian work next week, which is rather unfortunate given the freeze
deadline.
> > > > 2. Ensure that the microcode module and processor microcode will be added
> > > > to the initramfs.
> > >
> > > Can be done by initramfs-tools.
> >
> > Yes, it can. But initramfs-tools has no specific code other than some NFS
> > stuff, so we would probably benefit from a firmware-cpu-tools or whatever,
> > which could drop the initramfs helper, dpkg triggers and helper scripts to
> > get things done for both amd and intel microcode.
> >
> > I'd rather not duplicate this code for Intel and AMD, so it would need to
> > end up in a -common/-util package of some sort (or in intramfs-tools
> > directly, but I don't think that's a good idea): soon we will also need a
> > new type of hook to piggyback the microcode using a initramfs-like
> > container, either to the initramfs itself, or to the kernel image (I am not
> > clear on that detail yet), and the microcode will be loaded on the BSP very
> > very early, and on other cores BEFORE they're activated.
>
> Why is this 'needed'; are future processors expected to be particularly
> buggy?
A few current ones already are, and there is no reason to believe it
won't happen again in the future. "buggy" here means something the
kernel wants (or cannot afford not to) to test for only once, and
disable functionality if the relevant microcode update is not already
installed in the processor.
Anyway, we will need to update the userspace microcode facilities for
new kernels, as early-init microcode update support should land in 3.6
or 3.7 and will require changes on how it interacts with the initramfs.
I'd rather this was something simple to do for wheezy-stable through
either a stable update, or a backport or a single simple package.
> Named firmware files can generally be included in the kernel image, but
> of course we won't do that in official Debian packages.
It won't go through the firmware interface, that thing is not available
early enough... the microcode update needs to be available during the
bootstrap processor init. So far, it looks like it will be something
initramfs-like that gets either added to the real initramfs or to the
kernel image (I am not sure of the details), and has files with specific
names inside with the relevant data blobs.
Anyway, it will require updated userland to be used to its full
functionality, so I'd prefer to have all userland logic in a single
place that we can update and backport, instead of at least two copies of
it.
I suggest we add a new firmware-x86-cpu-helpers package to handle this.
It can provide an update-processor-microcode script, which
firmware-x86-amd64 and intel-microcode/firmware-x86-intel will call on
postinst.
firmware-x86-cpu-helpers (or whatever we name it) will have initramfs
helpers and any relevant scripts (we need at least one,
"update-processor-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: