update 2018-03-15: from C’t: new micro codes for intel iCPUs (2011 and onwoards) seem to fix Spectre v2 (CVE-2017-5715) 60minutes: https://www.heise.de/security/meldung/Spectre-Luecke-Intels-Microcode-Updates-fuer-Linux-und-Windows-3994347.html
As Einstein already knew energy = matter = energy.
great comparison: bugs in hardware – only solution: change / update the hardware regularly or sue the producer.
Translated into computer science this would be: software = hardware = software.
It is one and the same.
But software with security flaws can be updated (fixed) easier than hardware that would have to be replaced partially or completely.
„The Value of the System is the value of the features minus the risks that it creates. If we can’t cope with those computer security problems – the net value of the systems that we produce is going to be falling – and the more complicated systems will be less valuable than the one’s that we already have.“ (Paul Kocher)
Means: An old Nokia phone is more valuable than an IPhone 10 if it can’t be hacked for the simple reason of having a smaller attack surface (less software running, less complex chips in use) – if twitter isn’t working might not be as important to you as being unable to call someone.
Intel is rolling microcode (cpu firmware) updates of basically all it’s last 10 year processors to address Spectre and Meltdown Side-Channel-Attacks of reading RAM by non-previliged processes.
dmesg|grep micro; # what is my current microcode version? (CentOS7) [ 0.000000] microcode: microcode updated early to revision 0x20, date = 2017-01-27 [ 1.313870] microcode: sig=0x40651, pf=0x40, revision=0x20 [ 1.313998] microcode: Microcode Update Driver: v2.2. cat /proc/cpuinfo |grep model; # what is my cpu model? model : 69 model name : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz model : 69 model name : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz model : 69 model name : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz model : 69 model name : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz Intel Processor Microcode Package for Linux 20180108 Release -- Updates upon 20171117 release -- IVT C0 (06-3e-04:ed) 428->42a SKL-U/Y D0 (06-4e-03:c0) ba->c2 BDW-U/Y E/F (06-3d-04:c0) 25->28 HSW-ULT Cx/Dx (06-45-01:72) 20->21 Crystalwell Cx (06-46-01:32) 17->18 BDW-H E/G (06-47-01:22) 17->1b HSX-EX E0 (06-3f-04:80) 0f->10 SKL-H/S R0 (06-5e-03:36) ba->c2 HSW Cx/Dx (06-3c-03:32) 22->23 HSX C0 (06-3f-02:6f) 3a->3b BDX-DE V0/V1 (06-56-02:10) 0f->14 BDX-DE V2 (06-56-03:10) 700000d->7000011 KBL-U/Y H0 (06-8e-09:c0) 62->80 KBL Y0 / CFL D0 (06-8e-0a:c0) 70->80 KBL-H/S B0 (06-9e-09:2a) 5e->80 CFL U0 (06-9e-0a:22) 70->80 CFL B0 (06-9e-0b:02) 72->80 SKX H0 (06-55-04:b7) 2000035->200003c GLK B0 (06-7a-01:01) 1e->22 -- Microcode update instructions -- This package contains Intel microcode files in two formats: * microcode.dat * intel-ucode directory microcode.dat is in a traditional text format. It is still used in some Linux distributions. It can be updated to the system through the old microcode update interface which is avaialble in the kernel with CONFIG_MICROCODE_OLD_INTERFACE=y. To update the microcode.dat to the system, one need: 1. Ensure the existence of /dev/cpu/microcode 2. Write microcode.dat to the file, e.g. dd if=microcode.dat of=/dev/cpu/microcode bs=1M dd: error writing ‘/dev/cpu/microcode’: Invalid argument 1+0 records in 0+0 records out 0 bytes (0 B) copied, 0.00173194 s, 0.0 kB/s intel-ucode dirctory 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 throught the microcode reload interface. 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/ /usr/bin/cp -rv * /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 dmesg|grep micro [ 0.000000] microcode: microcode updated early to revision 0x20, date = 2017-01-27 [ 1.313870] microcode: sig=0x40651, pf=0x40, revision=0x20 [ 1.313998] microcode: Microcode Update Driver: v2.2. [20126.928129] microcode: updated to revision 0x21, date = 2017-11-20 [20146.465773] microcode: error! Bad data in microcode data file [20164.317266] microcode: error! Bad data in microcode data file cat /proc/cpuinfo |grep micro microcode : 0x21 microcode : 0x21 microcode : 0x21 microcode : 0x21
You can check if the kernel updated the microcode on boot by looking for „microcode updated early to“ lines in the kernel log:
dmesg | grep "microcode" journalctl -b -k | grep "microcode" zgrep "microcode" /var/log/kern.log*
debian microcode update utility is open source but the updates itself not.
Please install the amd64-microcode package (for systems with AMD AMD64 processors), or the intel-microcode package (for systems with Intel processors). You will have to enable both contrib and non-free in /etc/apt/sources.list.
Microcode updates are only applied at boot, so you have to reboot to activate them. You will have to keep the packages installed as explained above: the microcode updates have to be reapplied at every boot.
Processor microcode is akin to processor firmware. The kernel is able to update the processor’s firmware without the need to update it via a BIOS update. A microcode update is kept in volatile memory, thus the BIOS/UEFI or kernel updates the microcode during every boot.
Processors from Intel and AMD may need updates to their microcode to operate correctly. These updates fix bugs/errata that can cause anything from incorrect processing, to code and data corruption, and system lockups.
It is very difficult to know for sure whether you need a microcode update or not, but it is not safe at all to just ignore them. You might not notice their effect and have precious data silently corrupted, or an important program silently misbehave. Or you could experience one of those unexplainable and infrequent software issues (such as kernel oops, application segfaults) or hardware issues (including sudden reboots and hangs).
Releases of new microcode updates are more frequent on young processors, but the release of new microcode updates for older processors do happen.
The BIOS (or UEFI) updates the CPU microcode during boot, however most of the time either the motherboard vendor won’t issue frequent BIOS/UEFI updates, or the user won’t install such updates. For these reasons, the system processor is likely to be running with outdated microcode on a vast number of systems.