Bug#1014593: amd64-microcode: Updated version for bullseye/stable?
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
Bug#1014593: amd64-microcode: Updated version for bullseye/stable?
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. 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. > 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... -- Henrique de Moraes Holschuh
Bug#1014593: amd64-microcode: Updated version for bullseye/stable?
Hi, On 2022-07-08 15:36, Michael Prokop wrote: > 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! 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
Bug#1014593: amd64-microcode: Updated version for bullseye/stable?
Package: amd64-microcode Version: 3.20191218.1 Severity: wishlist 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-
