[Bug 2130658] Re: hashed microcode updates

In measured environments, supplying "microcode.amd_sha_check=off" would
cause the TPM-computed magic registers to have wrong values and thus
prevent supplying FDE keys or whatever it is that happens when TPMs
fail.

In unmeasured environments this hash-patch changes the situation from
"an attacker can affect the current boot" to "an attacker can affect the
next boot", I think: this will prevent someone from very silently
changing the behavior of important instructions (such as RDRAND
https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-
microcode-hacking ) to now also needing to modify the kernel command
line and then waiting or forcing a reboot.

I don't know if AMD was able to address the core of the problem in
microcode updates or not -- the rumors are that there's just not that
much storage space to work with, they may not physically have the space
in the CPU patching mechanism to include both good signature
verification and whatever other fixes are necessary. (This would, of
course, only help people who install BIOS updates. fwupd is wonderful
for the machines that support it, but some machines require using
horrible tools and probably most of those never get updated.)

A single hash feels like it's fine for people who distribute their amd64
microcode in the same package as their kernel packages. But we don't,
and now we've got a mess to clean up to get even this papier-mache
mitigation to functional. I'll grant that checking a hash is easier to
verify for correctness than a whole signature mechanism, so it made
sense as a tourniquet damage control. But it's been a year and I'm sad
they haven't done something better. So, we should figure out how to make
this fit our needs.

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
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
Status in linux 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