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 a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2130658 Title: hashed microcode updates To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/amd64-microcode/+bug/2130658/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
