Thank you for the fast reply! On 2023-03-01 12:07, Henrique de Moraes Holschuh wrote: > 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).
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. > That said, with enough *it works* feedback, yes, we can push amd64-microcode > updates to stable. 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. > On Wed, Mar 1, 2023, at 07:09, Christian Kastner wrote: >>> Users seem to be relying on this (as I was just asked about policies >>> when microcode updates are updated/backported). > > 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. 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. >> Since microcode updates are generally fixes, sometimes even important >> security fixes, I guess updates to stable (rather than going via >> backports) would be permissible? > > 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... Best, Christian
