Author: ken
Date: Sun May 19 13:52:16 2019
New Revision: 21608
Log:
Update firmware details re recent intel move to github and newly disclosed
vulnerabilities.
Modified:
trunk/BOOK/introduction/welcome/changelog.xml
trunk/BOOK/postlfs/config/firmware.xml
Modified: trunk/BOOK/introduction/welcome/changelog.xml
==============================================================================
--- trunk/BOOK/introduction/welcome/changelog.xml Sun May 19 10:52:30
2019 (r21607)
+++ trunk/BOOK/introduction/welcome/changelog.xml Sun May 19 13:52:16
2019 (r21608)
@@ -41,6 +41,15 @@
</itemizedlist>
</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>
<para>May 18th, 2019</para>
Modified: trunk/BOOK/postlfs/config/firmware.xml
==============================================================================
--- trunk/BOOK/postlfs/config/firmware.xml Sun May 19 10:52:30 2019
(r21607)
+++ trunk/BOOK/postlfs/config/firmware.xml Sun May 19 13:52:16 2019
(r21608)
@@ -100,17 +100,16 @@
released. These updates only last until the machine is powered off, so they
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>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 used to be two ways of loading the microcode, described as
'early'
+ <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
particular erratum in early Intel Haswell processors which had TSX enabled.
@@ -120,13 +119,12 @@
Broadwell-Y</ulink>.) Without this update glibc can do the wrong thing in
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
identical) look in /proc/cpuinfo.</para>
@@ -135,20 +133,30 @@
<title>Intel Microcode for the CPU</title>
<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
is any microcode for it. Determine the decimal values of the cpu family,
@@ -188,7 +196,8 @@
<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
revision 0x24. Unlike in older kernels, the individual CPUs are not
separately
@@ -312,16 +321,20 @@
<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
kernel, showing that the first notification comes before the kernel
version
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>
<para>A historic AMD example:</para>
--
http://lists.linuxfromscratch.org/listinfo/blfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
