I am a little confused by this as some sites say all modern cpu’s are affected… whilst AMD say they are only partly affected. I don’t think Intel’s press statements have helped. Anyway as someone who owns AMD based pc’s do I need to do anything special with the kernel? Or has this been patched properly by openSUSE? I have had my kernel patched today along with “ucode-intel”; the latter has me puzzled as I have purely AMD…
The following patches were issued today:
> zypper list-patches --all | grep 2018 Hauptaktualisierungs-Repository | openSUSE-2018-1 | security | important | --- | applied | Security update for kernel-firmware Hauptaktualisierungs-Repository | openSUSE-2018-2 | security | important | reboot | applied | Security update for the Linux Kernel Hauptaktualisierungs-Repository | openSUSE-2018-4 | security | important | --- | applied | Security update for ucode-intel >
The AMD firmware is updated with “openSUSE-2018-1”:
> zypper patch-info openSUSE-2018-1 Loading repository data... Reading installed packages... Information for patch openSUSE-2018-1: -------------------------------------- Repository : Hauptaktualisierungs-Repository Name : openSUSE-2018-1 Version : 1 Arch : noarch Vendor : email@example.com Status : applied Category : security Severity : important Created On : Thu Jan 4 11:41:53 2018 Interactive : --- Summary : Security update for kernel-firmware Description : This update for kernel-firmware fixes the following issues: - Add microcode_amd_fam17h.bin (bsc#1068032 CVE-2017-5715) This new firmware disables branch prediction on AMD family 17h processor to mitigate a attack on the branch predictor that could lead to information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715). This update was imported from the SUSE:SLE-12-SP2:Update update project. Provides : patch:openSUSE-2018-1 = 1 Conflicts :  kernel-firmware.noarch < 20170530-14.1 kernel-firmware.src < 20170530-14.1 ucode-amd.noarch < 20170530-14.1 >
The openSUSE standpoint is published here: <https://news.opensuse.org/2018/01/04/current-status-opensuse-and-spectre-meltdown-vulnerabilities/>.
The SUSE standpoint (pointed to by the openSUSE statement) is published here: <https://www.suse.com/c/suse-addresses-meltdown-spectre-vulnerabilities/>.
This Raspberry Pi statement has some detailed background information: <https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/>.
There’s also a small discussion going on in “General Chit-Chat”: <https://forums.opensuse.org/showthread.php/528914-Notice-and-thinkin-R-Brown>.
Thanks for your in depth response; I will check out those links… just to confuse myself further Actually it’s quite fascinating when you dig into these bug fixes; or is it just me. And thanks for the zypper code, it looks like I’m patched; just confusing when I saw that intel install…
a question to the patch.
The patch info says:
As this feature can have a performance impact,
it can be disabled using the “nospec” kernel commandline option.
This feature can be enabled / disabled by the “pti=[on|off|auto]”
or “nopti” commandline options.
Only if the options ‘nospec’ an ‘nopti’ are set the vulnerabilities are closed?
No, it’s exactly the opposite.
These options DISABLE the fixes.
They should be enabled by default (for affected CPUs), so there’s nothing to be done manually.
I have just tried the list-patches command on my system after updating today and nothing shows. How do I find out why these patches have not been installed? Have I got something wrong in my setup? If I list the patches without the grep all I get is:-
zypper list-patches --all Loading repository data... Reading installed packages... Repository | Name | Category | Severity | Interactive | Status | Summary ---------------------------+-------------------------------------+-------------+-----------+-------------+------------+------------------------------------ openSUSE-Tumbleweed-Update | update-test-32bit-pkg | recommended | moderate | --- | not needed | Test-update for openSUSE Tumbleweed openSUSE-Tumbleweed-Update | update-test-affects-package-manager | recommended | moderate | restart | not needed | Test-update for openSUSE Tumbleweed openSUSE-Tumbleweed-Update | update-test-feature | feature | moderate | --- | not needed | Test-update for openSUSE Tumbleweed openSUSE-Tumbleweed-Update | update-test-optional | optional | moderate | --- | not needed | Test-update for openSUSE Tumbleweed openSUSE-Tumbleweed-Update | update-test-reboot-needed | recommended | important | reboot | not needed | Test-update for openSUSE Tumbleweed openSUSE-Tumbleweed-Update | update-test-relogin-suggested | recommended | moderate | --- | not needed | Test-update for openSUSE Tumbleweed openSUSE-Tumbleweed-Update | update-test-security | security | critical | --- | not needed | Test-update for openSUSE Tumbleweed openSUSE-Tumbleweed-Update | update-test-trival | recommended | low | --- | not needed | Test-update for openSUSE Tumbleweed
Thnaks for the answer.
Ok, for the crazy guys who want more performance than security.
You are using Tumbleweed, and these security fixes have been released as normal kernel update in the main repo, like any other kernel update.
“list-patches” only lists special updates (so-called “patches”) from the official update repo though.
Check the version of the kernel-default and ucode-intel/ucode-amd packages, and/or the package changelogs, to see whether you got the fixes.
Or run “lscpu”, it should either show “kaiser” or “pti” in the list of flags (if you are using an intel cpu).
But likely also (partly at least) because the fixes may cause problems…
I must be lucky. Fully up to date TW, so patched, and experiencing no performance loss, at least not yet.
Unless you are hitting the kernel heavy you probably won’t see a human precipitable change. It may be noticed on Servers or heavy network/VM jobs
I was holding off running a couple of Windows 10 VirtualBox VMs until next Wednesday due to the Anti-Virus updates needed for the Windows 10 patch to not cause a “blue screen” and then, there’s the bad news that, the Windows 10 patch renders machines with AMD CPUs unusable (my case).
And now, there’s the Bug Report mentioned by Wolfi.
I’m betting that, I’ll (maybe) run the Windows 10 VMs again, maybe, after Easter . . .
Not only that.
There are a couple of threads here already about users having problems, and further bug reports are being filed.
It only affects some systems though, and in Linux it is possible to disable the fixes as mentioned.
In particular, the Meltdown fix is unnecessary on AMD CPUs as they are not affected by that vulnerability, but it is being applied there by the kernel currently as well (on Tumbleweed at least, where that will be fixed with the next update, I’m not sure about Leap). Adding “nopti” on an AMD CPU therefore does not impose a security risk at all, but still might “fix” possible problems.
I have no idea about Windows 10…
I tested my system with https://github.com/paboldin/meltdown-exploit and I am getting NOT VULNERABLE. I wonder if that is a guarantee that my system is completely safe from any Spectre/Meltdown vulnerabilities?
I cannot really answer your questions (and I somehow doubt anybody can, really)
Regarding Firefox: an update for Tumbleweed has been released today to fix the vulnerability, 52ESR on Leap apparently is not affected.
I found a script that tests for patches and probes your hardware(using Linux OS hardware detection) for exposure to these vulnerabilities and posted to this Forum thread
Just an IMO,
Unless you have a reason to do otherwise, application patches like for FF are less important than patching and understanding your system’s hardware exposure.
IMO the test you ran is only for that particular attack vector, it’s not a more comprehensive evaluation.
Thanks. Unfortunately I am hesitant to use FF at all (check this thread).
@TSU, thanks for the script. It gives me:
Spectre and Meltdown mitigation detection tool v0.16 Checking vulnerabilities against Linux 4.4.104-39-default #1 SMP Thu Jan 4 08:11:03 UTC 2018 (7db1912) x86_64 CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Kernel compiled with LFENCE opcode inserted at the proper places: YES (92 opcodes found, which is >= 70) > STATUS: NOT VULNERABLE CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigation 1 * Hardware (CPU microcode) support for mitigation: NO * Kernel support for IBRS: NO * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * Mitigation 2 * Kernel compiled with retpoline option: NO * Kernel compiled with a retpoline-aware compiler: NO > STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES > STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
I also got feedback from my web hosting server (running CentOS) and they got all three NOT VULNERABLE, pasting the differences from mine only:
Checking vulnerabilities against Linux 2.6.32-696.18.7.el6.x86_64 #1 SMP Thu Jan 4 17:31:22 UTC 2018 x86_64 ... CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigation 1 * Hardware (CPU microcode) support for mitigation: YES * Kernel support for IBRS: YES * IBRS enabled for Kernel space: YES * IBRS enabled for User space: NO * Mitigation 2 * Kernel compiled with retpoline option: NO * Kernel compiled with a retpoline-aware compiler: NO > STATUS: NOT VULNERABLE (IBRS mitigates the vulnerability) ...
What would be the way to get that second one fixed on openSUSE too?
Looks like Linux patches for the retpoline option are still being evaluated based on a Google search with the keywords “retpoline linux kernel”
But, from what I understand, the situation may already be partially mitigated by enabling IBRS for kernel space (If I understand what is written correctly, which admittedly may not be true)
You can read about IBRS and retpoline(return trampoline) yourself from the following Intel information release (section 3.2)
Since the situation is very fluid…
There are new discoveries and new patches released and not yet released…
The script to check these vulnerabilities is being changed to reflect new information and improve the documentation.
I recommend cloning the repo, and running “git pull” to update the repo easily before you run the script each time.
For those new to git, I added a post to that other Forum thread, here it is again