Changeset 3c19265

Timestamp:

05/19/2019 08:52:16 PM (4 years ago)

Author:

Ken Moffat <ken@…>

Branches:

10.0, 10.1, 11.0, 11.1, 11.2, 11.3, 12.0, 9.0, 9.1, kea, ken/inkscape-core-mods, lazarus, lxqt, plabs/python-mods, qt5new, trunk, upgradedb, xry111/intltool, xry111/soup3, xry111/test-20220226, xry111/xf86-video-removal

Children:

b18436b4

Parents:

909e238

Message:

Update firmware details re recent intel move to github and newly disclosed vulnerabilities.

git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@21608 af4574ff-66df-0310-9fd7-8a98e5e911e0

Files:

• introduction/welcome/changelog.xml (modified) (1 diff)
• postlfs/config/firmware.xml (modified) (6 diffs)

introduction/welcome/changelog.xml

@@ -42 +42 @@
     </listitem>
     -->
+    <listitem>
+      <para>May 19th, 2019</para>
+      <itemizedlist>
+        <listitem>
+          <para>[ken] - Update details of Intel microcode. Fixes
+          <ulink url="&blfs-ticket-root;12061">#12061</ulink>.</para>
+        </listitem>
+      </itemizedlist>
+    </listitem>
 
     <listitem>

postlfs/config/firmware.xml

@@ -101 +101 @@
     need to be applied on every boot.</para>
 
-    <para>Intel provide frequent updates of their microcode. It is not uncommon
-    to find a newer version of microcode for an Intel processor even two years
-    after its release. New versions of AMD firmware are rare and usually only
-    apply to a few models, although motherboard manufacturers get extra updates
-    which maybe update microcode along with the changes to support newer CPUs
-    and faster memory.</para>
-
-    <para>There used to be two ways of loading the microcode, described as 'early'
+    <para>Intel provide updates of their microcode for SandyBridge and later
+    processors as new vulnerabilities come to light. New versions of AMD
+    firmware are rare and usually only apply to a few models, although
+    motherboard manufacturers get extra updates which maybe update microcode
+    along with the changes to support newer CPUs and faster memory.</para>
+
+    <para>There are two ways of loading the microcode, described as 'early'
     and 'late'. Early loading happens before userspace has been started, late
     loading happens after userspace has started. Not surprisingly, early loading
-    was preferred, (see e.g. an explanatory comment in a kernel commit noted at
+    is preferred, (see e.g. an explanatory comment in a kernel commit noted at
     <ulink url="https://lwn.net/Articles/530346/">x86/microcode: Early load
     microcode </ulink> on LWN.)  Indeed, it is needed to work around one
@@ -121 +120 @@
     uncommon situations. </para>
 
-    <para>As a result, early loading is now expected, although for the moment
-    (4.18 kernels) it is still possible to manually force late loading of
-    microcode for testing. You will need to reconfigure your kernel for either
-    method. The instructions here will create a kernel
-    <filename>.config</filename> to suite early loading, before forcing late
-    loading to see if there is any microcode. If there is, the instructions
-    then show you how to create an initrd for early loading.</para>
+    <para>It is still possible to manually force late loading of microcode,
+    either for testing or to prevent having to reboot. You will need to
+    reconfigure your kernel for either method. The instructions here will
+    create a kernel <filename>.config</filename> to suite early loading, before
+    forcing late loading to see if there is any microcode. If there is, the
+    instructions then show you how to create an initrd for early loading.</para>
 
     <para>To confirm what processor(s) you have (if more than one, they will be
@@ -136 +134 @@
 
      <para>The first step is to get the most recent version of the Intel
-     microcode.  This must be done by navigating to 
-     <ulink url='https://downloadcenter.intel.com/download/28087/Linux-Processor-Microcode-Data-File'/>
-     and following the instructions there.  As of this writing the most recent
-     version of the microcode is <filename>microcode-20180807.tgz</filename>.
-     Extract this file in the normal way to create an <filename>intel-ucode</filename>
+     microcode.  This must be done by navigating to <ulink
+     url='https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/'/>
+     and downloading the latest file there.  As of this writing the most recent
+     version of the microcode is microcode-20190514a.
+     Extract this file in the normal way, the microcode is in the <filename>intel-ucode</filename>
      directory, containing various blobs with names in the form XX-YY-ZZ.
-     This tarball does not contain a top-level directory, two files
-     (microcode.dat which is the old-style of updates, still used by some
-     linux distros, and releasenote) will be extracted into the current
-     directory.</para>
-
-     <note><para>The above URL may not be the latest page.  If it is not,
-     a line at the top of the page will direct you to the latest page.
-     </para></note>
+     There are also various other files, and a releasenote.</para>
+
+     <para>In the past, intel did not provide any details of which blobs had
+     changed versions, but now the releasenote details this.</para>
+
+     <para>The recent firmware for older processors is provided to deal with
+     vulnerabilities which have now been made public, and for some of these such
+     as Microarchitectural Data Sampling (MDS) you might wish to increase the
+     protection by disabling hyperthreading, or alternatively to disable the
+     kernel's default mitigation because of its impact on compile times. Please
+     read the online documentation at <ulink
+     url='https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html'/>.
+     </para>
+
+     <para>To be able to use the microcode which addresses MDS, the kernel must
+     be one of the following stable versions: 5.1.2, 5.0.16, 4.19.43, 4.14.119,
+     4.9.176 or a later version of those series, or a later kernel series such
+     as 5.2.</para>
 
      <para>Now you need to determine your processor's identity to see if there
@@ -189 +197 @@
 <screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
 
-      <para>This example from the Haswell i7 which was released in Q2 2014 and is
+      <para>This old example (from before Intel provided details of the latest
+      versions) from the Haswell i7 which was released in Q2 2014 and is
       not affected by the TSX errata shows it has been updated from revision 0x19
       in the BIOS/UEFI (which this version of the kernel now complains about) to
@@ -313 +322 @@
 <screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
 
+      <para>If you updated to address vulnerabilities, you can look at <filename
+      class="directory">/sys/devices/system/cpu/vulnerabilities/</filename> to
+      see what is now reported.</para>
+
       <para>The places and times where early loading happens are very different
       in AMD and Intel machines. First, an Intel example from an updated
@@ -318 +331 @@
       is mentioned:</para>
 
-<screen><literal>[    0.000000] microcode: microcode updated early to revision 0x25, date = 2018-04-02
-[    0.000000] Linux version 4.18.1-rc1 (ken@plexi) (gcc version 8.2.0 (GCC))
-               #2 SMP PREEMPT Tue Aug 14 20:22:35 BST 2018
-[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.18.1-rc1-sda5 root=/dev/sda5 ro resume=/dev/sdb1
-[    0.275864] microcode: sig=0x306c3, pf=0x2, revision=0x25
+<screen><literal>[    0.000000] microcode: microcode updated early to revision 0x27, date = 2019-02-26
+[    0.000000] Linux version 5.0.16 (lfs@plexi) (gcc version 9.1.0 (GCC))
+               #2 SMP PREEMPT Sat May 18 23:10:29 BST 2019
+[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.0.16-sda5 root=/dev/sda5 ro resume=/dev/sdb1
+[    0.275864] microcode: sig=0x306c3, pf=0x2, revision=0x27
 [    0.275911] microcode: Microcode Update Driver: v2.2.</literal></screen>