Debian Security – Should Modifications Be Left on /etc/default/intel-microcode?

debianfirmwareintelSecurity

I have a quad-core intel machine having i5-7400 CPU @ 3.00GHz .

Recently, Intel introduced a new bunch of updates for machines affected by the spectre vulnerabilities.

One can see the changelog.gz of the newest update at Debian paste. I have just shared the latest update.

Now when I run the following command – 

$ sudo iucode_tool -tb -lS /lib/firmware/intel-ucode/*

I get a list of all the bundles and am able to confirm that the firmware was updated by checking the pf_mask hexcodes, dates, revision number and filesize in bytes.

My issue or question is: should I leave the modifications as I have put or comment them out again in /etc/default/microcode ?

$ cat /etc/default/intel-microcode
# Configuration script for intel-microcode version 3

#
# initramfs helper
#

# Set this to "no" to disable automatic microcode updates on boot;
# Set this to "auto" to use early initramfs mode automatically (default);
# Set this to "early" to always attempt to create an early initramfs;
IUCODE_TOOL_INITRAMFS=auto

# Set this to "yes" (default) to use "iucode_tool --scan-system" to reduce
# the initramfs size bloat, by detecting which Intel processors are active
# in this system, and installing only their microcodes.
#
# Set this to "no" to either include all microcodes, or only the microcodes
# selected through the use of IUCODE_TOOL_EXTRA_OPTIONS below.
#
# WARNING: including all microcodes will increase initramfs size greatly.
# This can cause boot issues if the initramfs is already large.
IUCODE_TOOL_SCANCPUS=yes

# Extra options to pass to iucode_tool, useful to forbid or to
# force the inclusion of microcode for specific processor signatures.
# See iucode_tool(8) for details.
#IUCODE_TOOL_EXTRA_OPTIONS=""

Looking forward to know what is the best way. I did also consult the wiki page for the same and it seemed to have some interesting details – 

$ zgrep "microcode updated early to" /var/log/kern.log*
/var/log/kern.log:Nov 14 02:59:32 debian kernel: [    0.000000] microcode: microcode updated early to revision xxxx, date = 2019-04-01
/var/log/kern.log:Nov 15 10:16:23 debian kernel: [    0.000000] microcode: microcode updated early to revision xxxx, date = 2019-08-14

I did find that there were a couple of updates to intel-microcode and I have the latest update – 

$ apt-cache policy intel-microcode
intel-microcode:
  Installed: 3.20191112.1
  Candidate: 3.20191112.1
  Version table:
 *** 3.20191112.1 900
        900 http://cdn-fastly.deb.debian.org/debian testing/non-free amd64 Packages
        100 http://cdn-fastly.deb.debian.org/debian unstable/non-free amd64 Packages
        100 /var/lib/dpkg/status

What seems to be interesting from the kernel log is that the revision hex code/version changed drastically from the version before.

Best Answer

/etc/default/intel-microcode is managed as a conffile, so dpkg will prompt if necessary during upgrades. It’s safe to make changes to it, and keep them; that’s what the whole conffile system is designed for.

However, your changes only amount to uncommenting default settings, so you won’t lose anything by reverting to the original version, and it will avoid any prompting whatsoever during upgrades.

Regarding revision bumps, that’s up to Intel; it seems they had to go through a number of revisions internally for some CPUs before getting the updates stabilised (and fixing the issues they were supposed to fix).

Related Question