Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#58700 - [linux][linux-firmware][libvirt][qemu][intel-ucode] CVE-2018-3639 CVE-2018-3640

Attached to Project: Arch Linux
Opened by loqs (loqs) - Wednesday, 23 May 2018, 01:31 GMT
Last edited by Doug Newgard (Scimmia) - Thursday, 09 August 2018, 16:35 GMT
Task Type Bug Report
Category Security
Status Closed
Assigned To Tobias Powalowski (tpowa)
Jan Steffens (heftig)
Laurent Carlier (lordheavy)
Anatol Pomozov (anatolik)
Levente Polyak (anthraxx)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

CVE-2018-3639 Description:
Systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka Speculative Store Bypass (SSB), Variant 4.
Kernel fixes in 4.14.43 4.16.11 (note requires new microcode / firmware update)
QEMU no new release relevant commits in git
https://git.qemu.org/?p=qemu.git;a=commit;h=d19d1f965904a533998739698020ff4ee8a103da
https://git.qemu.org/?p=qemu.git;a=commit;h=cfeea0c021db6234c154dbc723730e81553924ff
https://git.qemu.org/?p=qemu.git;a=commit;h=d19d1f965904a533998739698020ff4ee8a103da
libvirt no new release commits in git
https://libvirt.org/git/?p=libvirt.git;a=commit;h=1dbca2eccad58d91a5fd33962854f1a653638182
https://libvirt.org/git/?p=libvirt.git;a=commit;h=9267342206ce17f6933d57a3128cdc504d5945c9
CVE-2018-3640 Description:
Systems with microprocessors utilizing speculative execution and that perform speculative reads of system registers may allow unauthorized disclosure of system parameters to an attacker with local user access via a side-channel analysis, aka Rogue System Register Read (RSRE), Variant 3a.
requires new microcode
This task depends upon

Closed by  Doug Newgard (Scimmia)
Thursday, 09 August 2018, 16:35 GMT
Reason for closing:  Fixed
Additional comments about closing:  intel-ucode 20180807-1 libvirt 4.4.0-1 qemu 2.12.1-1
Comment by loqs (loqs) - Wednesday, 23 May 2018, 01:44 GMT
Should note the default kernel protection only applies to processes using seccomp or specifically opting in using prctl.
Comment by Jonathan Courtois (johnlamericain) - Friday, 15 June 2018, 18:37 GMT
I there any plan to address this?
Comment by loqs (loqs) - Friday, 15 June 2018, 22:50 GMT
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.
Comment by Jonathan Courtois (johnlamericain) - Tuesday, 19 June 2018, 07:01 GMT
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).

****
Comment by Pascal E. (hardfalcon) - Friday, 13 July 2018, 08:37 GMT
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.
Comment by Pascal E. (hardfalcon) - Friday, 13 July 2018, 08:43 GMT
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.

Loading...