[Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x20 (or later)

dmesg | grep microcode
grep microcode /proc/cpuinfo

Intel Processor Microcode Package for Linux
CPU microcode is a mechanism to correct certain errata in existing systems.

The normal preferred method to apply microcode updates is using the system

BIOS, but for a subset of Intel's processors this can be done at runtime 

using the operating system. This package contains those processors that 

support OS loading of microcode updates.

The target users for this package are OS vendors such as Linux distributions

for inclusion in their OS releases. Intel recommends getting the microcode

using the OS vendor update mechanism. Expert users can of course update their

microcode directly outside the OS vendor mechanism. This method is complex and

thus could be error prone.

Microcode is best loaded from the BIOS. Certain microcode must only be applied

from the BIOS. Such processor microcode updates are never packaged in this

package since they are not appropriate for OS distribution. An OEM may receive

microcode packages that might be a superset of what is contained in this

package.

OS vendors may choose to also update microcode that kernel can consume for early

loading. For example, Linux can update processor microcode very early in the kernel 

boot sequence. In situations when the BIOS update isn't available, early loading

is the next best alternative to updating processor microcode. Microcode states

are reset on a power reset; hence, it is required to be updated every time during the 

boot process.

Loading microcode using the initrd method is recommended so that the microcode 

is loaded at the earliest time for best coverage. Systems that cannot tolerate 

downtime may use the late reload method to update a running system without a

reboot.

== About Processor Signature, Family, Model, Stepping and Platform ID ==

Processor signature is a number identifying the model and version of a

Intel processor. It can be obtained using the CPUID instruction, and can

also be obtained via the command lscpu or from the content of /proc/cpuinfo.

It's usually presented as 3 fields: Family, Model and Stepping.

(In the table of updates below, they are shorten as F, MO and S.)

The width of Family/Model/Stepping is 12/8/4bit, but when arranged in the

32bit processor signature raw data is like 0FFM0FMS, hexadecimal.

e.g. if a processor signature is 0x000906eb, it means

Family=0x006, Model=0x9e and Stepping=0xb

A processor product can be implemented for multiple types of platforms,

So in MSR(17H), Intel processors have a 3bit Platform ID field,

that can specify a platform type from at most 8 types.

A microcode file for a specified processor model can support multiple

platforms, so the Platform ID of a microcode (shorten as PI in the table)

is a 8bit mask, each set bit indicates a platform type that it supports.

One can find the platform ID on Linux using rdmsr from msr-tools.

== Microcode update instructions ==

-- intel-ucode/ --

intel-ucode directory contains binary microcode files named in

family-model-stepping pattern. The file is supported in most modern Linux

distributions. It's generally located in the /lib/firmware directory,

and can be updated through the microcode reload interface.

To update early loading initrd, consult your distribution on how to package

microcode files for early loading. Some distros use update-initramfs or dracut.

As recommended above, please use the OS vendors are recommended method to ensure 

microcode file is updated for early loading before attempting the late-load 

procedure below.

To update the intel-ucode package to the system, one need:

1. Ensure the existence of /sys/devices/system/cpu/microcode/reload

2. Copy intel-ucode directory to /lib/firmware, overwrite the files in

/lib/firmware/intel-ucode/

3. Write the reload interface to 1 to reload the microcode files, e.g.

  echo 1 > /sys/devices/system/cpu/microcode/reload

If you are using the OS vendor method to update microcode, the above steps may

have been done automatically during the update process.

-- intel-ucode-with-caveats/ --

This directory holds microcode that might need special handling.

BDX-ML microcode is provided in directory, because it need special commits in

the Linux kernel, otherwise, updating it might result in unexpected system

behavior. 

OS vendors must ensure that the late loader patches (provided in

linux-kernel-patches\) are included in the distribution before packaging the

BDX-ML microcode for late-loading.

[root@localhost ]# lsinitrd  /boot/initramfs-3.10.0-862.3.2.el7.x86_64.img
Image: /boot/initramfs-3.10.0-862.3.2.el7.x86_64.img: 20M
========================================================================
Early CPIO image
========================================================================
drwxr-xr-x   3 root     root            0 Jun  1 20:37 .
-rw-r--r--   1 root     root            2 Jun  1 20:37 early_cpio
drwxr-xr-x   3 root     root            0 Jun  1 20:37 kernel
drwxr-xr-x   3 root     root            0 Jun  1 20:37 kernel/x86
drwxr-xr-x   2 root     root            0 Jun  1 20:37 kernel/x86/microcode
-rw-r--r--   1 root     root        99328 Jun  1 20:37 kernel/x86/microcode/GenuineIntel.bin
========================================================================
Version: dracut-033-535.el7

/usr/lib/dracut/skipcpio initramfs-3.10.0-862.3.2.el7.x86_64.img | gunzip -c | cpio -idv

 man dracut

       --early-microcode
           Combine early microcode with ramdisk

	The Linux Microcode Loader

Authors: Fenghua Yu <fenghua.yu@intel.com>
	 Borislav Petkov <bp@suse.de>

The kernel has a x86 microcode loading facility which is supposed to
provide microcode loading methods in the OS. Potential use cases are
updating the microcode on platforms beyond the OEM End-Of-Life support,
and updating the microcode on long-running systems without rebooting.

The loader supports three loading methods:

1. Early load microcode
=======================

The kernel can update microcode very early during boot. Loading
microcode early can fix CPU issues before they are observed during
kernel boot time.

The microcode is stored in an initrd file. During boot, it is read from
it and loaded into the CPU cores.

The format of the combined initrd image is microcode in (uncompressed)
cpio format followed by the (possibly compressed) initrd image. The
loader parses the combined initrd image during boot.

The microcode files in cpio name space are:

on Intel: kernel/x86/microcode/GenuineIntel.bin
on AMD  : kernel/x86/microcode/AuthenticAMD.bin

During BSP (BootStrapping Processor) boot (pre-SMP), the kernel
scans the microcode file in the initrd. If microcode matching the
CPU is found, it will be applied in the BSP and later on in all APs
(Application Processors).

The loader also saves the matching microcode for the CPU in memory.
Thus, the cached microcode patch is applied when CPUs resume from a
sleep state.

Here's a crude example how to prepare an initrd with microcode (this is
normally done automatically by the distribution, when recreating the
initrd, so you don't really have to do it yourself. It is documented
here for future reference only).

---
  #!/bin/bash

  if [ -z "$1" ]; then
      echo "You need to supply an initrd file"
      exit 1
  fi

  INITRD="$1"

  DSTDIR=kernel/x86/microcode
  TMPDIR=/tmp/initrd

  rm -rf $TMPDIR

  mkdir $TMPDIR
  cd $TMPDIR
  mkdir -p $DSTDIR

  if [ -d /lib/firmware/amd-ucode ]; then
          cat /lib/firmware/amd-ucode/microcode_amd*.bin > $DSTDIR/AuthenticAMD.bin
  fi

  if [ -d /lib/firmware/intel-ucode ]; then
          cat /lib/firmware/intel-ucode/* > $DSTDIR/GenuineIntel.bin
  fi

  find . | cpio -o -H newc >../ucode.cpio
  cd ..
  mv $INITRD $INITRD.orig
  cat ucode.cpio $INITRD.orig > $INITRD

  rm -rf $TMPDIR
---

The system needs to have the microcode packages installed into
/lib/firmware or you need to fixup the paths above if yours are
somewhere else and/or you've downloaded them directly from the processor
vendor's site.

2. Late loading
===============

There are two legacy user space interfaces to load microcode, either through
/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file
in sysfs.

The /dev/cpu/microcode method is deprecated because it needs a special
userspace tool for that.

The easier method is simply installing the microcode packages your distro
supplies and running:

# echo 1 > /sys/devices/system/cpu/microcode/reload

as root.

The loading mechanism looks for microcode blobs in
/lib/firmware/{intel-ucode,amd-ucode}. The default distro installation
packages already put them there.

3. Builtin microcode
====================

The loader supports also loading of a builtin microcode supplied through
the regular builtin firmware method CONFIG_EXTRA_FIRMWARE. Only 64-bit is
currently supported.

Here's an example:

CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09 amd-ucode/microcode_amd_fam15h.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"

This basically means, you have the following tree structure locally:

/lib/firmware/
|-- amd-ucode
...
|   |-- microcode_amd_fam15h.bin
...
|-- intel-ucode
...
|   |-- 06-3a-09
...

so that the build system can find those files and integrate them into
the final kernel image. The early loader finds them and applies them.

Needless to say, this method is not the most flexible one because it
requires rebuilding the kernel each time updated microcode from the CPU
vendor is available.

[root@localhost ]# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 94
model name	: Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz
stepping	: 3