Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 644100 - sys-firmware/intel-microcode: USE=split-ucode generates different ucode than upstream!
Summary: sys-firmware/intel-microcode: USE=split-ucode generates different ucode than ...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-10 06:37 UTC by Robin Johnson
Modified: 2018-08-08 19:03 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
intel-microcode-20180108-r1.ebuild.diff (intel-microcode-20180108-r1.ebuild.diff,831 bytes, patch)
2018-01-10 06:38 UTC, Robin Johnson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2018-01-10 06:37:31 UTC
I was poking at a more reasonable variation on bug 643786, and noticed that the C tool used to split microcode.dat generates weird results:
- upstream tarball ships already split ucode files.
- intel-microcode2ucode.c* APPENDS to existing split ucode files, bloating their size
- if you clear the upstream split ucode files out the way, and run the split tool, then 24 of the new output split files do NOT match the upstream versions.

!!! Section 'go-overlay' in repos.conf has location attribute set to nonexistent directory: '/code/layman/go-overlay'
 * microcode-20180108.tgz BLAKE2B SHA512 size ;-) ...                                                                                                                                 [ ok ]
 * Installing Intel microcode for ALL cpus
 * See Gentoo wiki for installing a subset of CPUs
>>> Unpacking source...
>>> Unpacking microcode-20180108.tgz to /dev/shm/portage/sys-firmware/intel-microcode-20180108-r1/work
>>> Source unpacked in /dev/shm/portage/sys-firmware/intel-microcode-20180108-r1/work
>>> Preparing source in /dev/shm/portage/sys-firmware/intel-microcode-20180108-r1/work ...
>>> Source prepared.
>>> Configuring source in /dev/shm/portage/sys-firmware/intel-microcode-20180108-r1/work ...
>>> Source configured.
>>> Compiling source in /dev/shm/portage/sys-firmware/intel-microcode-20180108-r1/work ...
iucode_tool: Writing selected microcodes to: microcode.cpio
make -j8 -l10 intel-microcode2ucode 
x86_64-pc-linux-gnu-gcc -O1 -pipe      intel-microcode2ucode.c   -o intel-microcode2ucode
0	intel-ucode
3200	intel-ucode.appended
1700	intel-ucode.regen
1700	intel-ucode.stock
 * Delta stock -> appended
 06-03-02 |    8 +
 06-05-00 |   33 +++++
 06-05-01 |    8 +
 06-05-02 |   35 +++++
 06-05-03 |   36 +++++
 06-06-00 |   13 ++
 06-06-05 |    5 
 06-06-0a |   23 +++
 06-06-0d |   25 +++
 06-07-01 |   10 +
 06-07-02 |    9 +
 06-07-03 |    8 +
 06-08-01 |   39 ++++++
 06-08-03 |   19 ++
 06-08-06 |   43 ++++++
 06-08-0a |   29 ++++
 06-09-05 |   11 +
 06-0a-00 |    7 +
 06-0a-01 |    9 +
 06-0b-01 |   16 ++
 06-0b-04 |   18 ++
 06-0d-06 |    2 
 06-0e-08 |   14 ++
 06-0e-0c |   26 ++++
 06-0f-02 |   31 ++++
 06-0f-06 |   35 +++++
 06-0f-07 |   19 ++
 06-0f-0a |   17 ++
 06-0f-0b |   92 ++++++++++++++
 06-0f-0d |   48 +++++++
 06-16-01 |   43 ++++++
 06-17-06 |   55 ++++++++
 06-17-07 |    9 +
 06-17-0a |   81 ++++++++++++
 06-1a-04 |   53 ++++++++
 06-1a-05 |   37 +++++
 06-1c-02 |   55 ++++++++
 06-1c-0a |   54 ++++++++
 06-1d-01 |    9 +
 06-1e-05 |   24 +++
 06-25-02 |   41 ++++++
 06-25-05 |   10 +
 06-26-01 |   48 +++++++
 06-2a-07 |   41 ++++++
 06-2d-06 |   58 +++++++++
 06-2d-07 |   75 +++++++++++
 06-2f-02 |   58 +++++++++
 06-3a-09 |   60 +++++++++
 06-3c-03 |   93 ++++++++++++++
 06-3d-04 |   73 +++++++++++
 06-3e-04 |   56 ++++++++
 06-3e-06 |   49 +++++++
 06-3e-07 |   83 +++++++++++++
 06-3f-02 |  144 ++++++++++++++++++++++
 06-3f-04 |   80 ++++++++++++
 06-45-01 |   93 ++++++++++++++
 06-46-01 |   84 +++++++++++++
 06-47-01 |   53 ++++++++
 06-4e-03 |  364 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 06-4f-01 |   91 ++++++++++++++
 06-55-04 |  109 +++++++++++++++++
 06-56-02 |  124 +++++++++++++++++++
 06-56-03 |  101 +++++++++++++++
 06-56-04 |   92 ++++++++++++++
 06-5c-09 |   72 +++++++++++
 06-5e-03 |  375 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 06-7a-01 |  264 +++++++++++++++++++++++++++++++++++++++++
 06-8e-09 |  389 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 06-8e-0a |  388 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 06-9e-09 |  376 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 06-9e-0a |  365 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 06-9e-0b |  402 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 0f-00-07 |   17 ++
 0f-00-0a |   23 +++
 0f-01-02 |    4 
 0f-02-04 |   34 +++++
 0f-02-05 |   29 ++++
 0f-02-06 |    8 +
 0f-02-07 |   23 +++
 0f-02-09 |   23 +++
 0f-03-02 |   10 +
 0f-03-03 |    8 +
 0f-03-04 |   38 +++++
 0f-04-01 |   35 +++++
 0f-04-03 |    3 
 0f-04-04 |   15 ++
 0f-04-07 |    6 
 0f-04-08 |   31 ++++
 0f-04-09 |    6 
 0f-04-0a |   15 ++
 0f-06-02 |   17 ++
 0f-06-04 |   16 ++
 0f-06-05 |    9 +
 0f-06-08 |    5 
 94 files changed, 6182 insertions(+), 12 deletions(-)
 * Delta stock -> appended
 06-05-00 |   32 +++++++++++-----------
 06-05-02 |   18 ++++++------
 06-05-03 |   14 +++++-----
 06-06-0a |   12 ++++----
 06-06-0d |   34 ++++++++++++------------
 06-08-01 |   20 +++++++-------
 06-08-06 |   14 +++++-----
 06-08-0a |   22 +++++++--------
 06-09-05 |    4 +-
 06-0b-01 |   12 ++++----
 06-0f-0b |   88 +++++++++++++++++++++++++++++++--------------------------------
 06-0f-0d |    4 +-
 06-16-01 |   52 ++++++++++++++++++-------------------
 06-17-06 |    4 +-
 06-17-0a |    6 ++--
 06-1c-0a |   26 +++++++++---------
 0f-00-07 |   12 ++++----
 0f-00-0a |   16 +++++------
 0f-02-04 |   22 +++++++--------
 0f-02-05 |   30 ++++++++++-----------
 0f-02-07 |   12 ++++----
 0f-02-09 |   20 +++++++-------
 0f-04-01 |   30 ++++++++++-----------
 0f-04-08 |   28 ++++++++++----------
 24 files changed, 266 insertions(+), 266 deletions(-)
Comment 1 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2018-01-10 06:38:25 UTC
Created attachment 514058 [details, diff]
intel-microcode-20180108-r1.ebuild.diff

Quick diff to test ebuild used for comparing ucode tools
Comment 2 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2018-01-10 06:52:40 UTC
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.
Comment 3 Thomas Deutschmann gentoo-dev Security 2018-01-10 16:32:07 UTC
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)
Comment 4 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2018-01-10 17:28:05 UTC
(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
Comment 5 Larry the Git Cow gentoo-dev 2018-01-10 22:14:08 UTC
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(+)
Comment 6 Manuel Mausz 2018-01-10 23:50:30 UTC
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
Comment 7 Manuel Mausz 2018-01-11 00:19:14 UTC
(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.
Comment 8 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2018-01-12 06:18:17 UTC
(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.
Comment 9 Manuel Mausz 2018-01-12 10:54:22 UTC
(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
Comment 10 Aweal 2018-01-13 14:52:30 UTC
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
Comment 11 Manuel Mausz 2018-01-13 15:03:58 UTC
(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
Comment 12 Thomas Deutschmann gentoo-dev Security 2018-01-13 16:05:44 UTC
> 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.
Comment 13 Thomas Deutschmann gentoo-dev Security 2018-08-08 19:03:51 UTC
We are no longer using C tool or microcode.dat file.