Re: source-only uploads for future point releases (Re: Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1)
On Sat, 30 Jan 2021, Holger Levsen wrote: > On Fri, Jan 29, 2021 at 04:32:27PM -0300, Henrique de Moraes Holschuh wrote: > > > Please feel free to upload, bearing in mind that the window for 10.8 > > > closes during this weekend. > > Uploaded (source, i386, amd64). > > one can do source only uploads to stable(-security) and oldstable() too. Well, I tried that for *non-free* stretch-security. It didn't work. I don't think I forgot anything: "XS-Autobuild: true" has been in intel-microcode's control file since basically forever, and it does work properly in non-free unstable. Can someone please take a look? Alternatively, I will just upload the binaries to jessie-security. -- Henrique Holschuh
Re: source-only uploads for future point releases (Re: Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1)
On Sat, Jan 30, 2021, at 09:16, Holger Levsen wrote: > On Fri, Jan 29, 2021 at 04:32:27PM -0300, Henrique de Moraes Holschuh wrote: > > > Please feel free to upload, bearing in mind that the window for 10.8 > > > closes during this weekend. > > Uploaded (source, i386, amd64). > > one can do source only uploads to stable(-security) and oldstable() too. > > Can we have source-only uploads for future point releases please? Sure, I wanted to do just that, but given the time frame for the upload and the deadline, I did not want to risk the need for a second upload with binaries. There is a pain point for *non-free* (which is the case here), in that in the past, not all possibilities were covered by autobuilders. And there was (is?) no documentation of such border conditions, because they were not on purpose. I guess I got the cat-and-water behaviour re. that :-) I will assume non-free, non-free backports and non-free security are fully supported by autobuilders for stretch and beyond now. But just in case, what about Jessie ELTS non-free ? -- Henrique de Moraes Holschuh
source-only uploads for future point releases (Re: Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1)
On Fri, Jan 29, 2021 at 04:32:27PM -0300, Henrique de Moraes Holschuh wrote: > > Please feel free to upload, bearing in mind that the window for 10.8 > > closes during this weekend. > Uploaded (source, i386, amd64). one can do source only uploads to stable(-security) and oldstable() too. Can we have source-only uploads for future point releases please? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ signature.asc Description: PGP signature
Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1
On Fri, 29 Jan 2021, Adam D. Barratt wrote: > Control: tags -1 + confirmed > On Fri, 2021-01-29 at 13:27 -0300, Henrique de Moraes Holschuh wrote: > > On Sun, 24 Jan 2021, Henrique de Moraes Holschuh wrote: > > The 3.20201118.1~deb10u1 version of the package (the one I am > > > proposing for the stable update) contains changes not (yet?) in > > > unstable to address the Skylake D0/R0 issue: they had their updates > > > frozen to the same revision currently in Debian stable. > > > > I better explain that in a more direct, clear way: > > Thanks. > > Please feel free to upload, bearing in mind that the window for 10.8 > closes during this weekend. Uploaded (source, i386, amd64). Thank you! -- Henrique Holschuh
Processed: Re: Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1
Processing control commands: > tags -1 + confirmed Bug #980962 [release.debian.org] buster-pu: package intel-microcode/3.20201118.1~deb10u1 Added tag(s) confirmed. -- 980962: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980962 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1
Control: tags -1 + confirmed On Fri, 2021-01-29 at 13:27 -0300, Henrique de Moraes Holschuh wrote: > On Sun, 24 Jan 2021, Henrique de Moraes Holschuh wrote: > The 3.20201118.1~deb10u1 version of the package (the one I am > > proposing for the stable update) contains changes not (yet?) in > > unstable to address the Skylake D0/R0 issue: they had their updates > > frozen to the same revision currently in Debian stable. > > I better explain that in a more direct, clear way: Thanks. Please feel free to upload, bearing in mind that the window for 10.8 closes during this weekend. Regards, Adam
Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1
On Sun, 24 Jan 2021, Henrique de Moraes Holschuh wrote: Regressions were indeed reported (as expected). A few days ago, Intel > published relevant information pinpointing the regression on Skylake D0 > and Skylake R0 processors to specific conditions (detailed below for > completeness). > > The 3.20201118.1~deb10u1 version of the package (the one I am proposing > for the stable update) contains changes not (yet?) in unstable to > address the Skylake D0/R0 issue: they had their updates frozen > to the same revision currently in Debian stable. I better explain that in a more direct, clear way: The reason why I want to update the package in stable is: the updated microcode in this package have security mitigations for a few newer speculative execution sidechannel attacks, and fix some critical defects/"errata" on many recent processor models, *other than Skylake R0/D0*. The s-p-u version of the intel-microcode package I am proposing has *less* changes than the packages currently in unstable/testing. The microcode updates have been tested in unstable since 2020-12-27, and in testing since 2020-01-02. Issues with it were reported in Ubuntu and Arch Linux, for specific system vendors and computer models (not processor models -- i.e. it does not look like a general issue with the microcode updates) when running outdated firmware. A *general* microcode update issue was reported only for Skylake D0/R0. The offending microcode changes for Skylake D0/R0 are *reverted* in this s-p-u package. To do that, the package keeps the microcode for these two processor models *exactly the same* as they already are in Debian stable. The package changes when compared to the packages currently in Debian stable are: 1. microcode binary data (except for Skylake D0 and R0) 2. upstream documentation 3. Debian metadata (changelog, version). Thanks! -- Henrique Holschuh
Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu I'd like to update the intel-microcode package in Debian Buster. This is a security-related update, but since it had a larger potential for regressions, I coordinated with the security team and we agreed that it would be best done in a slow pace, through a stable update. Regressions were indeed reported (as expected). A few days ago, Intel published relevant information pinpointing the regression on Skylake D0 and Skylake R0 processors to specific conditions (detailed below for completeness). The 3.20201118.1~deb10u1 version of the package (the one I am proposing for the stable update) contains changes not (yet?) in unstable to address the Skylake D0/R0 issue: they had their updates frozen to the same revision currently in Debian stable. For the record, that does mean these two Skylake processor models are _NOT_ receiving security updates in Debian stable at this time, and still lack SRBDS mitigations as well as newer mitigations that require newer microcode. Here's the full details about the Skylake D0/R0 microcode update regression, as disclosed by Intel. Problem Statement: Intel has identified an issue when performing OS patch loading of MCU version 0xE2 on SKL R0 (506e3) and SKL D0 (406e3) systems when the existing Microcode Update (MCU) version is earlier than 0x80 Issue description: When an OS loads the latest MCU patches on SKL R0 (506e3) and SKL D0 (406e3), may lead to unexpected failures in the following conditions: * The system has a BIOS containing MCU version earlier than 0x80 (MCU < 0x80) * The user tries to load via OS load mechanism a new MCU version 0xD8 or greater Workaround: Update affected systems to a BIOS containing MCU version 0x80 or greater. A few other regressions might exist, but the situation there is either unclear thus far, or appear to be restricted to specific systems where the vendor likely did something unconvencional in their firmware. Debdiff does not work well with intel-microcode due to symlinks, so I used git diff (attached). Diffstat (from git diff): b/README.md| 106 +++ b/changelog| 60 b/debian/changelog | 87 ++ b/debian/intel-microcode.docs |3 b/intel-ucode/06-3f-02 |binary b/intel-ucode/06-4e-03 |binary b/intel-ucode/06-55-03 |binary b/intel-ucode/06-55-04 |binary b/intel-ucode/06-55-06 |binary b/intel-ucode/06-55-07 |binary b/intel-ucode/06-55-0b |binary b/intel-ucode/06-5c-09 |binary b/intel-ucode/06-5c-0a |binary b/intel-ucode/06-5e-03 |binary b/intel-ucode/06-7a-01 |binary b/intel-ucode/06-7a-08 |binary b/intel-ucode/06-7e-05 |binary b/intel-ucode/06-8a-01 |binary b/intel-ucode/06-8e-09 |binary b/intel-ucode/06-8e-0a |binary b/intel-ucode/06-8e-0b |binary b/intel-ucode/06-8e-0c |binary b/intel-ucode/06-9e-09 |binary b/intel-ucode/06-9e-0a |binary b/intel-ucode/06-9e-0b |binary b/intel-ucode/06-9e-0c |binary b/intel-ucode/06-9e-0d |binary b/intel-ucode/06-a5-02 |binary b/intel-ucode/06-a5-03 |binary b/intel-ucode/06-a5-05 |binary b/intel-ucode/06-a6-00 |binary b/intel-ucode/06-a6-01 |binary b/releasenote.md | 536 + b/s000406E3_m00C0_r00D6.fw |binary b/s000506E3_m0036_r00D6.fw |binary releasenote| 96 -- 36 files changed, 791 insertions(+), 97 deletions(-) Thank you! -- Henrique Holschuh diff --git a/README.md b/README.md new file mode 100644 index 000..47e49c4 --- /dev/null +++ b/README.md @@ -0,0 +1,106 @@ +# Intel Processor Microcode Package for Linux + +## About + +The Intel Processor Microcode Update (MCU) Package provides a mechanism to release updates for security advisories and functional issues, including errata. In addition, MCUs are responsible for starting the SGX enclave (on processors that support the SGX feature), implementing complex behaviors (such as assists), and more. The preferred method to apply MCUs is using the system BIOS. For a subset of Intel's processors, the MCU can also be updated at runtime using the operating system. The Intel Microcode Package shared here contains updates for those processors that support OS loading of MCUs. + +## Why update the microcode? +Updating your microcode can help to mitigate certain potential security vulnerabilities in CPUs as well as address certain functional issues that could, for example, result in
