Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 643786 - sys-firmware/intel-microcode: added USE flag 'scan-system' to only install suitable/applicable microcode
Summary: sys-firmware/intel-microcode: added USE flag 'scan-system' to only install su...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-07 15:23 UTC by Maxxim
Modified: 2018-01-10 22:14 UTC (History)
2 users (show)

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


Attachments
intel-microcode-20171117_p20171215.ebuild (intel-microcode-20171117_p20171215.ebuild,3.48 KB, text/plain)
2018-01-07 15:24 UTC, Maxxim
Details
metadata.xml (metadata.xml,662 bytes, text/xml)
2018-01-07 15:24 UTC, Maxxim
Details
Unified diff patch (diff.patch,4.31 KB, patch)
2018-01-07 15:26 UTC, Maxxim
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Maxxim 2018-01-07 15:23:02 UTC
I extended the ebuild to only install suitable/applicable microcode instead of all available microcode by adding the optional USE flag 'scan-system'.

The new flag affects both install methods (cpio archive, split ucode).

Basis for the modifications was the latest available ebuild (sys-firmware/intel-microcode-20171117_p20171215).

Changes:
- add USE flag 'scan-system'
- add dependency for new flag
- add code to src_compile and src_install to handle new flag
- change install location of cpio archive (*)
- add some helpful elog messages
- add flag description to metadata.xml

(*) The current install location '/lib/firmware/microcode.cpio' is somewhat misleading, as it could hold any sort of microcode. Thus, I changed the location to '/lib/firmware/intel-ucode/initramfs.cpio', which gives some hints
Comment 1 Maxxim 2018-01-07 15:24:19 UTC
Created attachment 513642 [details]
intel-microcode-20171117_p20171215.ebuild

Full modified ebuild
Comment 2 Maxxim 2018-01-07 15:24:48 UTC
Created attachment 513644 [details]
metadata.xml

Full modified metadata.xml
Comment 3 Maxxim 2018-01-07 15:26:05 UTC
Created attachment 513646 [details, diff]
Unified diff patch

Unified diff patch for both ebuild and metadata.xml
Comment 4 Maxxim 2018-01-07 15:28:56 UTC
Sample output for my Intel-driven system:

 * Messages for package sys-firmware/intel-microcode-20171117_p20171215:

 * Signature of detected processor(s): 0x00020652
 * Suitable microcode bundle: 41 (intel-ucode/06-25-02)
 * Suitable microcode bundle: 42 (intel-ucode/06-25-05)
 * 
 * CPIO archive was installed to '/lib/firmware/intel-ucode/initramfs.cpio'
 * This archive needs to be prepended to an existing initramfs image:
 * # cat /lib/firmware/intel-ucode/initramfs.cpio existing-image > combined-image
 * 
 * Split binary ucode files were installed to '/lib/firmware/intel-ucode'
 * 
 * Please refer to the Gentoo Wiki for more detailed information:
 * https://wiki.gentoo.org/wiki/Intel_microcode

Resulting contents of '/lib/firmware/intel-ucode':

  total 32K
  drwxr-xr-x 2 root root 4,0K Jan  7 16:26 .
  drwxr-xr-x 6 root root 4,0K Jan  6 18:57 ..
  -rw-r--r-- 1 root root 8,0K Jan  7 16:26 06-25-02
  -rw-r--r-- 1 root root 3,0K Jan  7 16:26 06-25-05
  -rw-r--r-- 1 root root  12K Jan  7 16:26 initramfs.cpio
Comment 5 Mike Gilbert gentoo-dev 2018-01-07 19:44:15 UTC
That looks like a lot of complexity for very little benefit.
Comment 6 Maxxim 2018-01-07 20:40:44 UTC
I'd say it is reasonable complexity, and the real benefit, aside from saving a little space, is telling the user which microcode is the right one for his system. 

Other bug reports on this package show that people have a hard time figuring out what microcode to use and how to use it - both is addressed by the changes.

That was also why I created this in the first place.
Comment 7 Mike Gilbert gentoo-dev 2018-01-07 20:54:10 UTC
(In reply to Maxxim from comment #6)
> I'd say it is reasonable complexity, and the real benefit, aside from saving
> a little space, is telling the user which microcode is the right one for his
> system. 
> 
> Other bug reports on this package show that people have a hard time figuring
> out what microcode to use and how to use it - both is addressed by the
> changes.

Users don't *need* to figure that out -- the iucode_tool does it for you when you run it, and initramfs generators just include all of the available files.
Comment 8 Maxxim 2018-01-07 21:03:05 UTC
(In reply to Mike Gilbert from comment #7)
> Users don't *need* to figure that out -- the iucode_tool does it for you
> when you run it, and initramfs generators just include all of the available
> files.

And that's exactly what the ebuild does. So what are we talking about?

Please see bug #624846 - it was even a dev pointing out that the ebuild should do more than it currently does.

Perhaps you look at it as someone who knows what microcodes are, how they work and what to do with them. I'd say that's hardly something every other user knows.
Comment 9 Mike Gilbert gentoo-dev 2018-01-07 21:15:47 UTC
(In reply to Maxxim from comment #8)
> (In reply to Mike Gilbert from comment #7)
> > Users don't *need* to figure that out -- the iucode_tool does it for you
> > when you run it, and initramfs generators just include all of the available
> > files.
> 
> And that's exactly what the ebuild does. So what are we talking about?

The ebuild should continue just install all of the available files -- there's no need to filter them at build time.

> Please see bug #624846 - it was even a dev pointing out that the ebuild
> should do more than it currently does.
> 
> Perhaps you look at it as someone who knows what microcodes are, how they
> work and what to do with them. I'd say that's hardly something every other
> user knows.

Building the microcode into your kernel is not a great solution. That's basically the only scenario where you might need to figure out which files are necessary for your target CPU, though including all of them would probably work just fine.

The best supported way to load microcode is to generate an initramfs using a suitable tool (genkernel or dracut).

The wiki article below details several alternative methods. There are several different ways to accomplish essentially the same thing.

https://wiki.gentoo.org/wiki/Intel_microcode
Comment 10 Thomas Deutschmann gentoo-dev Security 2018-01-07 22:13:00 UTC
sys-firmware/intel-microcode[initramfs] creates /lib/firmware/microcode.cpio which can be used in a bootloader. I was thinking about the same (add a use flag which will call iucode_tools with "-S" parameter) when I touched this package.

At least genkernel for example will include all AMD _and_ all Intel firmwares... we are talking about ~1.8MB.
Comment 11 Maxxim 2018-01-08 06:21:09 UTC
(In reply to Mike Gilbert from comment #9)
> Building the microcode into your kernel is not a great solution. That's
> basically the only scenario where you might need to figure out which files
> are necessary for your target CPU, though including all of them would
> probably work just fine.
> 
> The best supported way to load microcode is to generate an initramfs using a
> suitable tool (genkernel or dracut).
> 
> The wiki article below details several alternative methods. There are
> several different ways to accomplish essentially the same thing.
> 
> https://wiki.gentoo.org/wiki/Intel_microcode
You're preaching to the choir here. *I* know all that, I read the whole article half a year ago when I first wanted to add microcode patching to my systems. I wouldn't have been able to modify the ebuild without the knowledge.

After I had figured it out, I thought 'man, this is more complex than it has to be'. See, just because *I* know all about it, I don't assume everyone else does.

Let me explain something:
I've been using Gentoo since 2002, back in the days where a simple world upgrade could easily render one's system unusable, when there was little documentation and one basically already had to be a Linux expert to even use Gentoo. Gentoo has since come a long way, and although it still is and probably always will be an expert distro, I fail to understand why one shouldn't make other users' lives easier when all it takes are 30-40 lines of code (that's what we're talking about here, already including message-only lines).

About the size of intel-microcode: yes, it's only a few megs, but then I never said that this modification is about saving storage space. Isn't one of the major advantages of Gentoo that it's thin and users can tweak it the way they like (at least that's what *I* like about it the most)? This optional USE flag supports exactly that. Also, it may be a few megs now, but there's now way of telling it'll stay that way in the future, so why not take the necessary steps now. And, last but not least: we're talking about *one* package here. If every package would just install a few megs of stuff that has no use, you'll end up with a system quite larger than necessary.
Comment 12 Maxxim 2018-01-08 06:34:37 UTC
(In reply to Mike Gilbert from comment #9)
> Building the microcode into your kernel is not a great solution. That's
> basically the only scenario where you might need to figure out which files
> are necessary for your target CPU, though including all of them would
> probably work just fine.
One last thing to add: that may be you opinion, but the wiki article tells users that this is the *preferred* way of doing it (see https://wiki.gentoo.org/wiki/Intel_microcode#New_method_without_initram-fs.2Fdisk)
Comment 13 Alexander Tsoy 2018-01-08 11:38:36 UTC
(In reply to Maxxim from comment #12)
> (In reply to Mike Gilbert from comment #9)
> > Building the microcode into your kernel is not a great solution. That's
> > basically the only scenario where you might need to figure out which files
> > are necessary for your target CPU, though including all of them would
> > probably work just fine.
> One last thing to add: that may be you opinion, but the wiki article tells
> users that this is the *preferred* way of doing it (see
> https://wiki.gentoo.org/wiki/Intel_microcode#New_method_without_initram-fs.
> 2Fdisk)

that in turn is opinion of user Janos666

https://wiki.gentoo.org/index.php?title=Intel_microcode&type=revision&diff=551478&oldid=539942
Comment 14 Mike Gilbert gentoo-dev 2018-01-08 14:13:03 UTC
I am still opposed to this patch, but I will defer to other base-system members before closing the bug.
Comment 15 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2018-01-08 19:39:34 UTC
I'll take a compromise:
- I don't want all the iucode_tool complexity in the ebuild.
- But I will allow a simpler selection method to install a subset of microcode, maybe by the same filename fragment like passed to the kernel?
Comment 16 Larry the Git Cow gentoo-dev 2018-01-10 22:14:13 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(+)