| Both sides previous revision Previous revision Next revision | Previous revision |
| spectre_and_meltdown_fixes_-_release_dates_for_linux_distros [09.04.2018 16:39] – [Microcode Update - Yes it's necessary too!] Pascal Suter | spectre_and_meltdown_fixes_-_release_dates_for_linux_distros [24.10.2018 21:40] (current) – [Performance Impact] Pascal Suter |
|---|
| |
| ==== 3: Update your BIOS ==== | ==== 3: Update your BIOS ==== |
| Intel BIOS packages also include the latest microcode for the CPU upon release of the BIOS package. Usually you will get the microcode first in the microcode package mentioned in 2), and once the next BIOS is released after the microcode update has been released, the BIOS update should include the Microcode package as well. Because Linux only loads the microcode from its own package when it's newer than the version loaded by the bios, a BOIS upddate 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 :) | 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. | 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 release notes ==== | ===== Understanding the microcode release notes ===== |
| Intel's releasenotes are somewhat cryptic. Here is how to read the following lines of the current release notes: <code> | Intel's 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 |
| * ''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: |
| 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. |