I just read in opensuse news that the long-term support 4.4 kernel has been patched against Meltdown/Spectre vulnerabilities, but that the 4.14.12 kernel hasn’t.
So-oo, I took a look in Yast, found ucode-intel with a date of 20171117-2.1. I tried to update; nothing happened. Will a later version arrive with upcoming Tumbleweed snapshots? Will I even need to care about the microcode, if an upcoming kernel addresses Meltdown/Spectre in other ways?
Fellow Tumblweed users, I’m confused about what to do, if anything! I know a rolling distro lives in a different world than conventional releases. How are you dealing with the vulnerability on your systems?
That must be a mistake.
Both 4.14.11 and 4.14.12 do have patches for these vulnerabilities, they even caused problems for users (32bit applications crashing on AMD CPUs, system not booting/freezing).
4.14.13 should have some more fixes (for the problems in particular).
So-oo, I took a look in Yast, found ucode-intel with a date of 20171117-2.1. I tried to update; nothing happened. Will a later version arrive with upcoming Tumbleweed snapshots?
The latest update is in the queue and should be in one of the next Tumbleweed snapshots.
IIANM, that 20171117 does contain fixes already, for some CPUs.
Will I even need to care about the microcode, if an upcoming kernel addresses Meltdown/Spectre in other ways?
Sure.
The MELTDOWN vulnerability is a “bug” in the CPUs themselves, and can only be fixed wih a firmware update AIUI. (although part of the fix is in the kernel)
How are you dealing with the vulnerability on your systems?
Not at all.
Except for installing available updates as usual.
Thanks for the response, Wolf. In that case, it sounds like I should keep an eye out for new snapshots, run zypper dup as usual, and take no other measures.
At the moment,
Based on varied reports it’s likely that patches will be replaced as time goes one due to many reasons, among them that we’re discovering that designs and implementations haven’t always been exactly as publicized, and the installed features of the many CPUs affected. In fact, because of some of these heretofore unknown inconsistencies, some systems have been crashing… And this is without regard of the running OS.
Some openSUSE Forum discussions on this topic, current up to a few days ago so probably very little change as of this post
The second link is to a thread that points to a script that evaluates your system’s exposure and vulnerability, both software and hardware.
Because it’s likely that there will be new patches and patches replaced, you will likely want to run the script multiple times for he forseeable future to regularly check your current status.
Sorry, that’s wrong. Meltdown is avoided (not really fixed) in software by hiding kernel address space from user programs. Microcode updates are not related to Meltdown, but are used by one of mitigation techniques for one Spectre variant - disabling branch prediction across critical code. This requires new microcode that implements support for new instructions (and CPU features).
Is why in my post I described what I saw the script doing… at the time I posted, the script did not run PoC.
BUT,
I don’t agree with the evaluation that such scripts give people a false sense of security.
At the time I posted, the script does plenty while depending on the the work of people we already trust… The openSUSE and kernel maintainers and possibly other trusted contributors. It’s not much different than any other code we trust when running openSUSE.
And,
As I pointed out in that second thread,
By the time I posted again only a couple days later, the script had changed substantially to reflect evolving input to the author of the script.
Bottom line,
The script is not meant to be a PoC of any vulnerability, and even today I would consider even a PoC possibly suspect depending on how it’s written because these vulnerabilities might be susceptible to other vectors than are tested (eg published Javascript Spectre PoC, but what about other languages and vector, eg pipes instead of networking?)
IMO even today it’s possibly too early to understand the scope of possible attack vectors and this is important when current Spectre patches appear to try to block only the attack vector when we don’t yet know how to fix the source of the problem.
As ordinary Users (assuming my audience doesn’t include people actually trying to write code), IMO a scanning tool like the script can serve a useful purpose, to know if you’re protected as best as possible at that moment (but, keep checking until some announcement that the vulnerabilities are fixed once and for all).
Not that I’m aware of. Note that it only can fix Meltdown; Spectre vulnerabilites are very unlikely to be fixed in hardware, at least without total redesign.
As about a month ago when I researched the state of what Intel CPUs were affected (I didn’t check any other CPU including AMD),
Any Intel CPU shipped from factory with a date stamp 2017 or later can be patched.
But, only CPUs shipped after Feb/Mar 2018 likely shipped with a patch applied.
It was unclear to me whether firmware patches to address Meltdown/Spectre could be applied through an OS update or if a firmware upgrade had to be performed. In any case, as I opined in an earlier post in this thread updated patches have been released regularly to block attack vectors.
There is no performance impact of microcode updates per se. Do you have numbers that prove performance drop using one year old kernel (i.e. kernel without patches)?
I hope that the Spectre issue will have an “silicon” fix soon.
Fixing known Spectre vulnerabilities is easy - just remove speculative execution and pipelines. I doubt you will like the result.
What you apparently miss is that Spectre simply demonstrates that virtually anything that CPU does can potentially be abused to guess some information that would normally not be available to attacker. What we have seen were just most low hanging fruits.
It talks about combined microcode and kernel update. If course it will have performance impact, nobody disputes it.
https://newsroom.intel.com/editorials/advancing-security-silicon-level/
Even this one says “Variant 1 will continue to be addressed via software mitigations”. Of course it may be possible to design mitigation for known vulnerabilities. But since the first announcement multiple new variations of Spectre have already been discovered (at least made known). This will be never-ending story given current shared nature of CPU. Unless each execution thread can be completely isolated from another, this will continue.
