Rodrigo pointed out https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d171045069c804e5ffaa18be590c42c6af0cf3f
This looks like some CPU microcode revisions know how to properly verify a signature. Users probably need to get a new enough microcode installed via a BIOS update in order for the CPUID(1).EAX checks in need_sha_check() to say that the CPU doesn't need the hash-check. So the hash check is intended for systems where the BIOS isn't updated -- and I believe the intention is that the kernel's table of SHAs won't be populated for future microcode updates. Which means that this hash mitigation would only get a user so far before they're no longer able to install microcode updates, and if our packaging only ships the latest version, they'll be stuck on the factory firmware. If I'm understanding all this correctly (it's possible I got it wrong, this feels like some real spaghetti) then users pretty much need to install BIOS updates in order to get updated microcode. On some systems, this is super easy, barely an inconvenience. On other systems it's basically impossible. I don't like leaving users behind on known unsafe microcode versions but in a world where users don't install BIOS updates because it is complex or not even offered, there may not be a good outcome. Maybe we could maintain sha hashes for the "future" microcodes for those users? Or bundle in the microcode to the kernel .. and maybe then disable subsequent loads? add only those hashes to the driver? -- 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
