Hi,

quoting from
https://wiki.debian.org/Microcode#Microcode_update_support_for_current_and_older_Debian_releases:

| Debian 11, codename "Bullseye" is supported, and will receive
| updates both through the bullseye-backports official backports
| repository (faster than point-releases), and through Debian stable
| point-releases and security updates.

Users seem to be relying on this (as I was just asked about policies
when microcode updates are updated/backported).

Would you please consider updating the package in stable? :)
Thanks!

regards
-mika-

Hi,

I'd like to second this.

This [1] popped up in my newsfeed today. I only then realized that the
amd64-microcode package in stable is from 2019.

Since microcode updates are generally fixes, sometimes even important
security fixes, I guess updates to stable (rather than going via
backports) would be permissible?

Best,
Christian

[1] https://lkml.org/lkml/2023/2/22/33

Microcode updates are somewhat plagued with regressions, so usually I won't push them to stable without a reasonable level of feedback.  And that is a lot harder to come from AMD users than Intel users, for unknown-to-me reasons (I can speculate, but that's not helpful).

That said, with enough *it works* feedback, yes, we can push amd64-microcode updates to stable.

Really, you should rely on updated *firmware* if you can.  It still is the only place where you can actually trust a microcode update (from either AMD or Intel) to actually do all it was supposed to do.  I know for a fact the Intel ones disable sections of the update that cannot be activated when not loaded early enough.  For AMD, I know for a fact several updates of earlier processors were never shipped to users because they *must* be done by the firmware, nowadays maybe they do it like Intel.

Yes, they usually are.  We can even send them in as security updates when we get enough data to know it is going to fix a security issue **even when loaded by the O.S.* (see remark above) and that it is not causing serious regressions...

Thank you for the fast reply!

Oh, I wasn't aware of this. I admittedly simply assumed that CPU
microcode updates are minimal (targeted fixes for errata, or some such),
and are thoroughly tested by the manufacturer.

I'd be happy to serve as a beta-tester.

I guess this could be automated to some degree with the help of
autopkgtests for a subset of packages, e.g. the scientific ones tend to
get really "close" to the CPU with their optimizations, and they usually
come with massive test suites.

Good to know, thanks.

With firmware, you mean BIOS updates, correct?

Makes sense but that would suck if still true for AMD, as manufacturers
stop providing updates far earlier than the useful live of the product.

Best,
Christian

There is the rather serios CVE-2023-31315 which means malware can worm
itself into system firmware through leaky SMM on AMD CPUs. This might
promote the bug from wishlist to important.

This is so serious that I think that we are just forced to include the
current AMD microcode in stable. Testing has the current version.

This entry from the testing changelog looks serious enough to warrant
porting to stable for servers, doesn't it?

  * SECURITY UPDATE: Mitigates "Sinkclose" CVE-2023-31315 (AMD-SB-7014) on
    AMD Epyc processors: SMM lock bypass - Improper validation in a model
    specific register (MSR) could allow a malicious program with ring 0
    access (kernel) to modify SMM configuration while SMI lock is enabled,
    potentially leading to arbitrary code execution.
    Note: a firmware update is recommended for AMD Epyc (to protect the
    system as early as possible).  Many other AMD processor models are
    also vulnerable to SinkClose, and can only be fixed by a firmware
    update at this time.

EPYC CPUs are employed just in the kind of machine that would run
stable. Firmware update might be recommened, but doesn't have to be
available with differing mainboard vendors.

I'd be happy to install updated amd64-microcode from
bookworm-backports, but it's not there, I am stuck at
3.20230808.1.1~deb12u1 without starting to mix in packages from testing.