| Summary: | sys-firmware/intel-microcode: USE=split-ucode generates different ucode than upstream! | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Robin Johnson <robbat2> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | alexander, gaweal, hydrapolic, kensington, manuel-gentoo, security |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | intel-microcode-20180108-r1.ebuild.diff | ||
|
Description
Robin Johnson
2018-01-10 06:37:31 UTC
Created attachment 514058 [details, diff]
intel-microcode-20180108-r1.ebuild.diff
Quick diff to test ebuild used for comparing ucode tools
Digging into the generated ucodes to start, it seems the order within the generated files differs. I'm not sure what impact this would have. Yes, we are re-generating the ucodes from the provided *.dat files relying on intel-microcode2ucode helper. We are doing this now for more than 6 years [1]. Arch Linux [2], Debian [3], RH/CentOS [4] and SuSE [5] are all doing it the same way. I don't see a real problem here as long as Intel is providing that *.dat file. We are actively maintaining the helper (last update was https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9bd08f12708f4e323910f7f1be17b26bfe7bed57). Yes, the *.dat file is deprecated so you can treat this like a hack. For the first Meltdown/Spectre microcode update wave, Intel only provided ucodes (no *.dat file) file which forced me to rewrite the ebuild and to temporarily drop "monolithic" USE flag. Given that we are deprecating microcode-ctl (requires newer genkernel and documentation) we can probably move away from *.dat file usage at all. But there's no need to do that now because there's nothing wrong with our re-generated ucodes. They are fine. Or are there any reason to believe we must change this ASAP? [1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/microcode-data/microcode-data-20110915-r1.ebuild?hideattic=0&view=log [2] https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/intel-ucode#n27 [3] https://sources.debian.org/src/intel-microcode/3.20171215.1/debian/rules/#L35 [4] https://git.centos.org/blob/rpms!microcode_ctl.git/c7/SPECS!microcode_ctl.spec#L72 [5] https://build.opensuse.org/package/view_file/openSUSE:Factory/ucode-intel/ucode-intel.spec?expand=1 (L51) (In reply to Thomas Deutschmann from comment #3) > Yes, we are re-generating the ucodes from the provided *.dat files relying > on intel-microcode2ucode helper. We are doing this now for more than 6 years > [1]. It's not really regenerating: it's extracting from the *.dat and APPENDING to the upstream-provided-split files without removing them. > Arch Linux [2], Debian [3], RH/CentOS [4] and SuSE [5] are all doing it the > same way. Debian uses iucode_tool to split it, everybody else uses intel-microcode2ucode.c; there looks like there is a little bit of divergence between distros in intel-microcode2ucode.c as well. > But there's no need to do that now because there's nothing wrong with our > re-generated ucodes. They are fine. Or are there any reason to believe we > must change this ASAP? Does the order of ucodes in each split file matter? I think it might, and worse that we bloat them by duplicating content. Right now, USE=split-ucodes, for each CPU, ends up extracting the ucode from the dat, and appending it onto the upstream split files, and then installing that. At best, it wastes space. At worst, it means with USE=split-ucode the files we generate don't apply properly. microcode bundle 1: /dev/shm/portage/sys-firmware/intel-microcode-20180108-r1/work/intel-ucode.appended/0f-02-05 001/001: sig 0x00000f25, pf_mask 0x01, 2004-08-11, rev 0x0029, size 2048 001/002: sig 0x00000f25, pf_mask 0x02, 2004-08-11, rev 0x002a, size 2048 001/003: sig 0x00000f25, pf_mask 0x04, 2004-08-11, rev 0x002b, size 2048 001/004: sig 0x00000f25, pf_mask 0x10, 2004-08-26, rev 0x002c, size 2048 001/005: sig 0x00000f25, pf_mask 0x10, 2004-08-26, rev 0x002c, size 2048 001/006: sig 0x00000f25, pf_mask 0x02, 2004-08-11, rev 0x002a, size 2048 001/007: sig 0x00000f25, pf_mask 0x01, 2004-08-11, rev 0x0029, size 2048 001/008: sig 0x00000f25, pf_mask 0x04, 2004-08-11, rev 0x002b, size 2048 microcode bundle 1: /dev/shm/portage/sys-firmware/intel-microcode-20180108-r1/work/intel-ucode.stock/0f-02-05 001/001: sig 0x00000f25, pf_mask 0x01, 2004-08-11, rev 0x0029, size 2048 001/002: sig 0x00000f25, pf_mask 0x02, 2004-08-11, rev 0x002a, size 2048 001/003: sig 0x00000f25, pf_mask 0x04, 2004-08-11, rev 0x002b, size 2048 001/004: sig 0x00000f25, pf_mask 0x10, 2004-08-26, rev 0x002c, size 2048 The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=de233b906ee278949e0e140d42d44f087f76d395 commit de233b906ee278949e0e140d42d44f087f76d395 Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2018-01-10 21:57:09 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2018-01-10 22:13:35 +0000 sys-firmware/intel-microcode: rewrite to use iucode_tool. - Use the Intel upstream 'iucode_tool' to process all of the input microcode, from both the text-format microcode.dat file and other inputs, then generate a clean set of split outputs & optionally also initramfs output. - Allows easy inclusion of any future split-ucode releases for single CPUs. - No longer uses intel-microcode2ucode.c from $FILESDIR. - Expert users can use the new MICROCODE_SIGNATURES variable to install only a subset of microcodes on their system, as requested by bug 643786. - Avoids accidently bloated split-ucode files per bug #644100. - USE=monolithic is no longer supported, please see iucode_tool for any fallback. - USE=initramfs now writes to /boot/intel-uc.img (8.3-safe naming). Fixes: https://bugs.gentoo.org/643786 Fixes: https://bugs.gentoo.org/644100 Package-Manager: Portage-2.3.16, Repoman-2.3.6 Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> .../intel-microcode-20180108-r1.ebuild | 78 ++++++++++++++++++++++ 1 file changed, 78 insertions(+) Hi, I've emerged sys-firmware/intel-microcode-20180108-r1, however (at least) the generated ucode file for one of ours servers show the wrong revision. @gentoo # iucode_tool -s 0x000406f1 -l /lib/firmware/intel-ucode/06-4f-01 microcode bundle 1: /lib/firmware/intel-ucode/06-4f-01 selected microcodes: 001/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624 @centos # iucode_tool -s 0x000406f1 -l /lib/firmware/intel-ucode/06-4f-01 microcode bundle 1: /lib/firmware/intel-ucode/06-4f-01 selected microcodes: 001/001: sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648 The correct/current revision for this server is 0xb000025 (In reply to Manuel Mausz from comment #6) > I've emerged sys-firmware/intel-microcode-20180108-r1, however (at least) > the generated ucode file for one of ours servers show the wrong revision. Nevermind. Looks like intel still ships an older ucode revision in the 20180108 package for this particular cpu?! 20171117_p20171215-r1 includes the newer one. (In reply to Manuel Mausz from comment #7) > Nevermind. Looks like intel still ships an older ucode revision in the > 20180108 package for this particular cpu?! 20171117_p20171215-r1 includes > the newer one. Sorry, to ensure I understand you there 20171117_p20171215-r1 had a firmware that was newer than 20180108? That would be a concern. (In reply to Robin Johnson from comment #8) > Sorry, to ensure I understand you there 20171117_p20171215-r1 had a firmware > that was newer than 20180108? That would be a concern. Yes. And I'm not the only one noticing that: https://bodhi.fedoraproject.org/updates/microcode_ctl-2.1-20.fc27#comment-717745 and it's reply https://bodhi.fedoraproject.org/updates/microcode_ctl-2.1-20.fc27#comment-717804 sys-firmware/intel-microcode-20180108-r1::gentoo USE="initramfs split-ucode" 0 KiB
Why microcode.dat doesn't install ?
~ # microcode_ctl -u
microcode_ctl: cannot open source file '/lib/firmware/microcode.dat' errno=2 (No such file or directory)
EBUILD:
...
# This will take ALL of the upstream microcode sources:
# - microcode.dat
# - intel-ucode/
# In some cases, they have not contained the same content (eg the directory has newer stuff).
MICROCODE_SRC=(
"${S}"/microcode.dat
"${S}"/intel-ucode/
)
...
~ # gzip -dc /usr/portage/distfiles/microcode-20180108.tgz| tar -t| grep .dat
microcode.dat
(In reply to Manuel Mausz from comment #9) > (In reply to Robin Johnson from comment #8) > > Sorry, to ensure I understand you there 20171117_p20171215-r1 had a firmware > > that was newer than 20180108? That would be a concern. > > Yes. And I'm not the only one noticing that: > https://bodhi.fedoraproject.org/updates/microcode_ctl-2.1-20.fc27#comment- > 717745 and it's reply > https://bodhi.fedoraproject.org/updates/microcode_ctl-2.1-20.fc27#comment- > 717804 According to https://bugzilla.opensuse.org/show_bug.cgi?id=1074919 the ucode 06-4f-01 has been withdrawn. Intel has also issued a statement about this: https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/ And Dell as well: http://www.dell.com/support/article/us/en/19/sln308588/microprocessor-side-channel-vulnerabilities-cve-2017-5715-cve-2017-5753-cve-2017-5754-impact-on-dell-emc-products-dell-enterprise-servers-storage-and-networking-?lang=en > Why microcode.dat doesn't install ? Using microcode.dat is deprecated. We are in the progress to last-rite sys-apps/microcode-ctl. Please move to the "new" kernel microcode loading interface (https://wiki.gentoo.org/wiki/Microcode). @ Manuel: I can't find anything from Dell regarding an issue with the microcode. Anyway, we are going to track the issue in an own bug. > Sorry, to ensure I understand you there 20171117_p20171215-r1 > had a firmware that was newer than 20180108? That would be a concern. No, this isn't a concern. I haven't compared current release with previous release yet but this has happen before. See iucode_tool documentation: Best way would be to track any ucode manually and don't rely on upstream's tarball because Intel is adding/removing ucodes without notice. I.e. in the past they often have dropped microcodes for older processors (=EOL products) from distribution without any reason. This is a problem if you still use that processor. Once an issue was found, a specific ucode version needs to be blacklisted in kernel. That's the proper way to handle that. We are no longer using C tool or microcode.dat file. |