spectre_and_meltdown_fixes_-_release_dates_for_linux_distros

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
spectre_and_meltdown_fixes_-_release_dates_for_linux_distros [24.01.2018 18:19] – [Spectre and Meltdown fixes] Pascal Suterspectre_and_meltdown_fixes_-_release_dates_for_linux_distros [24.10.2018 21:40] (current) – [Performance Impact] Pascal Suter
Line 27: Line 27:
  
 ===== Microcode Update - Yes it's necessary too! ===== ===== Microcode Update - Yes it's necessary too! =====
-Update 22.1.2017: ** [[https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/|has found the root cause for the latest reboot-issues and revokes all Microcode updates delivered between 01 and 20 January]]. This means, that you should NOT follow the bleow instructions to upgrade your microcode at the moment until intel releases the next version!** 
- 
 After you have installed the latest OS updates, your system should be protected against Variant 1 and 3, in order to protect against Variant 2, you also need to install a newer microcode (firmware of the CPU).  After you have installed the latest OS updates, your system should be protected against Variant 1 and 3, in order to protect against Variant 2, you also need to install a newer microcode (firmware of the CPU). 
-Usually the microcode package is also a package in your distributions repository and is updated during a normal os upgrade. However, there where some [[https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/|stability issues]] with the microcodes released by Intel until today (18.1.18) so that for example RedHat removed them from their repos.  
  
-So now you have two options: 1.) wait until a stable microcode update is available and stay vulnerable until then or 2.) install the currently available microcode update and risk having less stable systemI have to mentionthat intel says that only "some configurations" are affected without furhter specifying which configurations they areI would therefore recommendto simply try the new microcode and if it does indeed make your system unstable, revert to the currently used microcode+There are three ways to get to the latest microcode updates 
 +==== 1: Wait for your linux distribution to include it ==== 
 +Usually the microcode package is also a package in your distributions repository and is updated during normal os upgradeHoweverthere where some [[https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/|stability issues]] with the microcodes released by Intel early this year ( around 18.1.18) so that for example RedHat removed them from their repos
  
-Here ishow you can download the microcode package (for all intel processors) and then insert this into your Linux installation for Linux to load the latest microcode. +after thatintel pulled the microcode updates back from their own webpage as well and went back to alpha and beta testing. they have now released a bunch of updated microcodes for their cpu's. generally what we see is, that they start with the newest cpu'and work their way back. I would expect, that the final microcode releases will make it into the respective microcode packages in your linux distribution. the Easiest way is just to run updates regularly and eventually you should get the latest microcode update for your cpu that will enable the Variant 2 fix
  
-The latest officially released Microcodes can be found on the intel downloadcenter page. currently [[https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?v=t|this download here]] is the latest. there should be a banner at the top linking to a newer versiononce released.+==== 2: Download the latest microcode from intel and install it manually ==== 
 +besides waiting for your distro to include the update for you, you can also manually download the latest microcode package from intel (includes microcodes for all intel cpus in one package) and install that on your computer manuallyHere ishow that's done: 
  
-**NOTE: see update above: Intel discurages the use of these microcodes as it seems that they can cause your system to be unstableIntel in fact changed their recommendations as of Jan22 from "ask your vendor to get the latest microcote" to "OMG, don'install the latest microcode!".** +The latest officially released Microcodes can be found on the intel downloadcenter pagecurrently [[https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?v=t|this download here]] is the latest. there should be a banner at the top linking to a newer versionshould this link no longer lead to the latest version. So far they have updated the link target together with new releases to always point to the latest release
- +
-<del>It seems howeverthat this package does not include the latest microcodes as they where distributed by RedHat before they removed them from their repos. For example the microcode for the ''Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz'' cpu is still at version ''21'' while the latest supplied by RedHat was ''25''''21'' does not yet have the patches for Variant 2. You can download a {{ :meltdown:intel-ucode_rh.tar.gz |copy of the intel-ucode from the removed RedHat Package here}}</del>+
  
   - download the package of your choice to your System: <code>   - download the package of your choice to your System: <code>
Line 55: Line 53:
 you should now be up to date with the latest patches for all three Variants of the Spectre & Meltdown vulnerability.  you should now be up to date with the latest patches for all three Variants of the Spectre & Meltdown vulnerability. 
  
-==== Understanding the release notes ==== +==== 3: Update your BIOS ==== 
-Intel's releasenotes are somewhat cryptic. Here is how to read the following lines of the current release notes: <code>+BIOS packages from the mainboard vendor should also include the latest microcode for the CPU upon release of the BIOS package. sometimes you can get microcode updates earlier through a BIOS update than you can get them through the intel microcode package download. However, if your mainboard producer supplies no mor BIOS updates or if they have a slow release cycle, the intel package might be the faster solution for you. Because Linux only loads the microcode from its own package when it's newer than the version loaded by the bios, a BOIS update that gets you the new Microcode will work even with old Linux Versions that might be out of maintenance. However, if you are using such a Distro, you probably aren't worried too much about security anyway and your system is hopefully only running in a well protected internal network with trusted users.. in that case, don't worry about Meltdown :)  
 + 
 +If you do worry about meltdown and want to upgrade the microcode through a new bios, you can find a list of the latest BIOS releases that contain Variant 2 fixes in their included microcode on this [[https://www.intel.com/content/www/us/en/support/articles/000026622/server-products.html|Intel-SA-00088 for Intel® Server Boards]] overview page. The list is updated as soon as new bioses become available.  
 + 
 +===== Understanding the microcode release notes ===== 
 +Intel'Microcode releasenotes are somewhat cryptic. Here is how to read the following lines of the current release notes: <code>
 -- Updates upon 20171117 release -- -- Updates upon 20171117 release --
 IVT C0 (06-3e-04:ed) 428->42a IVT C0 (06-3e-04:ed) 428->42a
Line 83: Line 86:
     * ''06-4e-03'' is actually the most useful part, it tells you what cpu that is in cpu-family, model and stepping. you can get this information from ''/proc/cpuinfo'' with this command: <code>     * ''06-4e-03'' is actually the most useful part, it tells you what cpu that is in cpu-family, model and stepping. you can get this information from ''/proc/cpuinfo'' with this command: <code>
 grep -P "^(cpu family)|(model\s*:)|(stepping)" /proc/cpuinfo | tail -3 grep -P "^(cpu family)|(model\s*:)|(stepping)" /proc/cpuinfo | tail -3
-</code>. ''06'' is the family, ''4e'' is the stepping in HEX format (use google or a scientific calculator to convert if you are lazy :)) and ''03'' is the stepping. +</code>. ''06'' is the family, ''4e'' is the model in HEX format (use google or a scientific calculator to convert if you are lazy :)) and ''03'' is the stepping. 
     * the last part ''ba->c2'' is the relevant part of the version number that changed. For this specific Skylake CPU the Spectre Patch is supposed to be in releases ''0xc2'' or newer, so this one here contains the patch. Sadly the list with all these releases is under NDA, so i can't share it here. But in general you can expect everything that is released starting with the current package to have the fix in place.      * the last part ''ba->c2'' is the relevant part of the version number that changed. For this specific Skylake CPU the Spectre Patch is supposed to be in releases ''0xc2'' or newer, so this one here contains the patch. Sadly the list with all these releases is under NDA, so i can't share it here. But in general you can expect everything that is released starting with the current package to have the fix in place. 
   * by the way, ''06-4e-03'' is also the filename of that microcode.    * by the way, ''06-4e-03'' is also the filename of that microcode. 
 +  * rather than browsing through the entire history of the release notes you can also check the version of a specific microcode file using this command: ''iucode_tool -l intel-ucode/06-4f-01''
 +
 ===== Minimalistic Fix on CentOS 7.4 ===== ===== Minimalistic Fix on CentOS 7.4 =====
 Should you, for some reason, not be able or willing to run a full update, I have here a minimalistic fix for your centos:  Should you, for some reason, not be able or willing to run a full update, I have here a minimalistic fix for your centos: 
Line 124: Line 129:
 echo 0 > /sys/kernel/debug/x86/ibpb_enabled echo 0 > /sys/kernel/debug/x86/ibpb_enabled
 echo 0 > /sys/kernel/debug/x86/ibrs_enabled echo 0 > /sys/kernel/debug/x86/ibrs_enabled
 +echo 0 > /sys/kernel/debug/x86/retp_enabled
 </code> </code>
 by default all three fixes are enabled, if you want to disable them permanently (=on every boot) you can add these three options to your kernel command line:  by default all three fixes are enabled, if you want to disable them permanently (=on every boot) you can add these three options to your kernel command line: 
 <code> <code>
-noibrs noibpb nopti+noibrs noibpb nopti noretp spectre_v2=off
 </code> </code>
 +the last ''spectre_v2=off'' is redhat/CentOS specific and might be redundant with the previous ones.
  • spectre_and_meltdown_fixes_-_release_dates_for_linux_distros.1516814348.txt.gz
  • Last modified: 24.01.2018 18:19
  • by Pascal Suter