[Bug 2130658] Re: hashed microcode updates

[Benjamin Drung]

First reaction after reading this: Oh, no, please don't.

Since that is a one-to-one relation of the kernel to a microcode
version, I can imagine following solution:

1. The amd64-microcode package needs to become versioned. The files in
the package needs to versioned as well so that these versioned packages
can be installed in parallel.

2. The kernel exposes the information which microcode has is looking
for.

3. The kernel declares a dependency on the exact versioned microcode
package.

4. initramfs-tools and dracut take the information from the kernel to
put the correct file into the initrd.

Then the package dependency will prevent incompatible combinations and
removing an old kernel can lead to removing a versioned microcode
version that is not needed any more.

I can help to work on point 4.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to amd64-microcode in Ubuntu.
https://bugs.launchpad.net/bugs/2130658

Title:
  hashed microcode updates

Status in amd64-microcode package in Ubuntu:
  New
Status in dracut package in Ubuntu:
  New
Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  Apologies that this isn't better -- I've been putting this off for too
  long as it is, and doing a poor job seems like it's better than
  waiting until I can do a good job.

  AMD has some problems with microcode updates -- the signature
  verification is not right. (Google put together a microcode update to
  recreate the xkcd random comic.)

  The AMD kernel developers have pushed a mitigation to the Linux kernel
  that hardcodes a single SHA256 hash of the latest microcode update.
  When userspace tries to patch the microcode, the kernel driver will
  compare the proposed new microcode and if it matches, then it is
  loaded. If it doesn't match, then it is not loaded.

  This is simple and easy. I'm afraid it isn't responsive to how we
  deliver updates to our users:

  - the kernel is delivered on its own timeframe; our updates even more so, perhaps over the course of months
  - the amd64-microcode package is delivered on its own timeframe; our updates can be timed with more precision than the kernel updates, but it would be nice to follow AMD closely without stress.

  If we deliver a new kernel with an updated hash from upstream before
  we have delivered the microcode, users will probably be reverted to
  running the factory firmware.

  If we deliver a new microcode package before we have delivered an
  updated kernel, users will probably be reverted to running the factory
  firmware.

  Running the factory firmware might be a performance, safety, security,
  or feature regression vs the user's immediately previous boot. Users
  might not even notice anything anything is wrong.

  I don't pretend to have the best possible solution, so treat this idea
  as something to be improved:

  We should amend our systems to be more flexible in which microcodes we
  will load, to allow loading any of the previous N microcode packages
  that we have shipped.

  We should amend our microcode packages to allow installing multiple
  versions and manage the multiple versions similarly to the Linux
  kernel "keep most recent three" sort of behavior.

  We should amend our kernel to expose in the filesystem, even when not
  running, which microcodes it can load.

  We should amend our initramfs generators to include the newest
  microcode that a kernel can load, for each initramfs that we generate.

  
  Ideally, we would collaborate with Debian on this issue. Probably Debian's situation is better than ours, since they have significantly fewer kernels to wrangle, over fewer supported releases, but I suspect their users would also benefit from some de-coupling.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/amd64-microcode/+bug/2130658/+subscriptions