[Bug 2130658] Re: hashed microcode updates

Wed Jan 28 18:33:54 UTC 2026

Bringing more information about my findings on this matter

It was confirmed with AMD that the BIOS update is a hard requirement for the microcode to be able to be updated through OS level (amd64-microcode package) starting from a specific version for each family 19h processor.
This because of the signature issue known as EntrySign[1] (CVE-2024-36347), which enables an attacker to load microcodes not properly signed.
To fix it, the CPU microcode needs to be updated to a level where the next microcodes have the signature correctly verified, hence the BIOS update necessity.

The hashes bundled in kernel[2] were the step in the middle while the major issue (EntrySign) was being fixed and released to OEMs to update their BIOS.
That means that now that the BIOS update is established, there is no need to maintain the SHA checksummed patches in the kernel anymore.

The biggest problem seems to be with non-updated BIOS users, where in an attempt to update to a newer microcode as distributed in amd64-microcode, a failure would happen and the resulting microcode running would be what was in BIOS originally, meaning that the user would actually downgrade when trying to upgrade.
For such cases AMD has released a second option in the microcode binaries that, if an user is on an old BIOS that does not have the EntrySign fix, it is updated to this second option right before the EntrySign fix, meaning that such user is not protected against EntrySign and possible new issues but it is "at least" not downgraded.

For all of that (SHA checksummed patches, fallback to microcode prior to
EntrySign) to work correctly, a set of kernel patches must be in place,
I'm listing them below.

As a validation, with an amd64-microcode built locally with updated binaries, I tested the following scenarios:
* old BIOS machine with ucode: 0x0a001173
+ Resolute (6.18 with all patches applied)
  * 3.20250708.1ubuntu1 (before): 0x0a0011d5
  * 3.20251202.1ubuntu1 (after): 0x0a0011d5
  - Result: didn't upgrade to the latest, but didn't downgrade -> used the "fallback"/secondary ucodes.
[    0.874594] microcode: Current revision: 0x0a0011d5
[    0.874603] microcode: Updated early from: 0x0a001173

+ Jammy (5.15 without any patches applied)
  * 3.20191218.1ubuntu2.3 (before): 0x0a0011d5
  * 3.20251202.0ubuntu0.22.04.1 (after): 0x0a001173
  - Result: didn't upgrade and downgraded.
[    0.000000] unchecked MSR access error: WRMSR to 0xc0010020 (tried to write 0xffff8880966415ea) at rIP: 0xffffffff9ac70557 (__apply_microcode_amd+0x17/0x40)
[    0.000000] Call Trace:
[    0.000000]  <TASK>
[    0.000000]  apply_microcode_early_amd.isra.0+0x99/0xd0
[    0.000000]  load_ucode_amd_bsp+0x57/0x77
[    0.000000]  load_ucode_bsp+0xff/0x128
[    0.000000]  x86_64_start_kernel+0xe5/0x106
[    0.000000]  secondary_startup_64_no_verify+0xc2/0xcb
[    0.000000]  </TASK>
...
[    1.123706] microcode: CPU0: patch_level=0x0a001173

Kernel commits that I found which are probably related (more/less may be needed):
50cef76d5cb0e199cda19f026842560f6eedc4f7	x86/microcode/AMD: Load only SHA256-checksummed patches
058a6bec37c6c3b826158f6d26b75de43816a880	x86/microcode/AMD: Add some forgotten models to the SHA check
31ab12df723543047c3fc19cb8f8c4498ec6267f	x86/microcode/AMD: Fix __apply_microcode_amd()'s return value
805b743fc163f1abef7ce1bea8eca8dfab5b685b	x86/microcode/AMD: Extend the SHA check to Zen5, block loading of any unreleased standalone Zen5 microcode patches
c0a62eadb6fd158e4d6d4d47d806109e7ae32e8b	x86/microcode/AMD: Use sha256() instead of init/update/final
2329f250e04d3b8e78b36a68b9880ca7750a07ef	x86/microcode/AMD: Add TSA microcode SHAs
fcf8239ad6a5de54fa7ce18e464c6b5951b982cb	x86/microcode/AMD: Handle the case of no BIOS microcode
876f0d43af78639790bee0e57b39d498ae35adcf	x86/microcode: Fix Entrysign revision check for Zen1/Naples
8a9fb5129e8e64d24543ebc70de941a2d77a9e77	x86/microcode/AMD: Limit Entrysign signature checking to known generations
d23550efc6800841b4d1639784afaebdea946ae0	x86/microcode/AMD: Add more known models to entry sign checking
dd14022a7ce96963aa923e35cf4bcc8c32f95840	x86/microcode/AMD: Add Zen5 model 0x44, stepping 0x1 minrev
8d171045069c804e5ffaa18be590c42c6af0cf3f	x86/microcode/AMD: Select which microcode patch to load
150b1b97e27513535dcd3795d5ecd28e61b6cb8c	x86/microcode/AMD: Fix Entrysign revision check for Zen5/Strix Halo

[1]: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/cpu/microcode/amd_shas.c

-- 
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
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