Arch Linux

Should note the default kernel protection only applies to processes using seccomp or specifically opting in using prctl.

I there any plan to address this?

For CVE-2018-3639 linux is fixed, qemu is fixed, linux-firmware which includes AMD microcode does not need updating as per https://xenbits.xen.org/xsa/xsa263-unstable/0001-x86-AMD-Mitigations-for-GPZ-SP4-Speculative-Store-By.patch that leaves no public microcode update from Intel and the patches for libvirt so that AMD systems could pass mitigations on to libvirt guests.
For CVE-2018-3640 that appears to be Intel only the mitigation is planned to be bundled with the microcode update with the mitigation for CVE-2018-3639.

Thanks loqs, but at the moment when I use the spectre/meltdown check fom https://github.com/speed47/spectre-meltdown-checker, I appear as vulnerable for this two. Anything I need to do in configuration?

****
CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability: NO
> STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability)

> How to fix: The microcode of your CPU needs to be upgraded to mitigate this vulnerability. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make s ure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode up date for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CP U by searching for your CPUID (indicated in the Hardware Check section). The microcode update is enough, there is no additional O S, kernel or software change needed.

CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface: NO (Vulnerable)
* Kernel supports speculation store bypass: YES (found in /proc/self/status)
> STATUS: VULNERABLE (Your CPU doesn't support SSBD)

> How to fix: Your kernel is recent enough to use the CPU microcode features for mitigation, but your CPU microcode doesn't actua lly provide the necessary features for the kernel to use. The microcode of your CPU hence needs to be upgraded. This is usually d one at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're usi ng a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availabilit y of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is av ailable for your CPU by searching for your CPUID (indicated in the Hardware Check section).

****

The last microcode update package from Intel *still* didn't contain SSBD support (which is needed to mitigate CVE-2018-7550) for at least two CPU signatures (0x000306c3 aka "Haswell" and 0x000506E3 aka "Skylake H/S"), and yet big vendors like Dell and Lenovo have been shipping BIOS updates containing newer microcode versions *with* SSBD support for several weeks now.

For example, for Haswell, Intel's microcode tarball only contains microcode version 0x24 (which lacks SSBD), but Dell and Lenovo have been shipping BIOS updates containing microcode version 0x25 (with SSBD support) for more than a month now. For Skylake H/S, Intel's tarball contains release 0xC2 whilst the current microcode version would actually be 0xC6. To get the current 0x25 version if the microcode, just extract it from Lenovo's BIOS update ISO for the Thinkpad T440p:

cd $(mktemp -d) ; curl -O "https://download.lenovo.com/pccbbs/mobiles/gluj38us.iso" ; iucode_tool -t r --write-all-named-to . gluj38us.iso ; iucode_tool -L .

This method also works for other models, but it has a few restrictions:

- From the EXE versions of Lenovo's BIOS updates, it will only be able to extract very outdated microcode versions. From the ISO versions, however, you'll usually get a whole pile of microcode versions, including the current one (which you actually want).

- Dell's BIOS updates are a lot more difficult to use. They usually come only in the form of an EXE file (which can be used for BIOS updates directly from the BIOS without any need for Windows, though). They first need to be decompressed (using "dell_extract_hdr.py" from the AUR package "uefi-firmware-parser"), and then you'll have to manually dig through them using "uefitool" (from the AUR package "uefitool-git") and manually search for sections containing microcode signatures, which you then extract, and onto which you can then unleash iucode_tool.

Aside from the microcode update, qemu would also need a few patches from git cherrypicked to support SSBD. Funny enough, upstream has released qemu 2.11.2 with SSBD support 3 weeks ago, but still haven't released a fixed version for the 2.12 branch (although the code is sitting in their git repo).

Libvirt 4.4.0 actually supports SSBD and is thus fine, but of course, it can only leverage that SSBD support when used with a qemu version that supports it as well.