​How Linux is dealing with Meltdown and Spectre

Torvalds and company are not happy with Intel as they continue to move forward with delivering Linux security patches.
Written by Steven Vaughan-Nichols, Senior Contributing Editor

Video: Supercomputing has an undisputed champion -- Linux

Linux can deal with Meltdown and Spectre, the fundamental chip security problems, but that doesn't mean Linux's developers are happy about it. As Linux's creator, Linus Torvalds, said on the Linux Kernel Mailing List [sic]:

I think somebody inside of Intel needs to really take a long hard look at their CPU's, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.

... and that really means that all these mitigation patches should be written with "not all CPU's are crap" in mind.

Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything?' Because if that's the case, maybe we should start looking towards the ARM64 people more.

He's not the only one unhappy with Intel. A Linux security expert is irked at both Google and Intel. He told me that Google Project Zero informed Intel about the security problems in April. But neither Google nor Intel bothered to tell the operating system vendors until months later. In addition, word began to leak out about the patches for these problems. This forced Apple, the Linux developers, and Microsoft to scramble to deliver patches to fundamental CPU security problems.

The result has been fixes that degrade system performance in many instances. While we don't know yet how badly macOS and Windows will be affected, Michael Larabel, a Linux performance expert and founder of the Linux Phoronix website, has ran benchmarks on Linux 4.15-rc6, a Linux 4.15 release candidate, which includes Kernel Page Table Isolation (KPTI) for Intel's Meltdown flaw.

Larbel found serious slowdowns in the Compile Bench and FS-Mark 3.3, synthetic I/O benchmarks; significant performance hits with the PostgreSQL database management system; and the Redis in-memory data structure store was also slower. Other processes, such as H.264 video encoding, timed Linux kernel compilation, and FFmpeg video conversion tasks, ran as fast as ever. As Torvalds told me, "There's no one number. It will depend on your hardware and on your load."

Slowdown or not, securing systems come first. Red Hat, which tends to be the Linux distribution security leader, has already released its first trio of patches to deal with three Meltdown attack variants.

In an email, Red Hat security wrote that the vulnerability affects x86 (Intel and AMD chipsets), POWER 8, POWER 9, System z, and ARM processors. AMD claimed its chips aren't vulnerable. In a statement, AMD said, "AMD is not susceptible to all three [attack] variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time."

Be that as it may, all three attacks have the potential to allow unauthorized read access to memory. There are three unique attack paths that could allow an attacker to execute a side-channel attack to bypass protections to read memory.

The three Common Vulnerability and Exposures (CVEs) for this issue are:

  • CVE-2017-5754 is the most severe of the three. This exploit uses speculative cache loading to enable a local attacker to read the contents of memory. This issue is corrected with kernel patches.
  • CVE-2017-5753 is a Bounds-checking exploit during branching. This issue is corrected with a kernel patch.
  • CVE-2017-5715 is an indirect branching poisoning attack that can lead to data leakage. This attack allows for a virtualized guest to read memory from the host system. This issue is corrected with microcode, along with kernel and virtualization updates to both guest and host virtualization software.

The good news is that these require an attacker to have local access to the targeted system. The bad news is they could still be exploited by an ordinary user on a vulnerable computer running JavaScript code from what appeared to be an innocuous web page. This poisoned code could then read any and all data in memory.

Red Hat warned, "Because of the threat posed by vulnerability chaining (the ability to exploit one vulnerability by exploiting another one first), Red Hat strongly suggests that users update all systems even if they do not believe their configuration poses a direct threat."

Meanwhile, as Mounir Hahad, Juniper Networks' head of threat research, observed: "There is no known exploit in the wild taking advantage of these vulnerabilities yet. But there has been a proof of concept posted by a PhD student from a university in Austria. There is little doubt that some sophisticated threat actors will attempt to take advantage of unpatched systems in the near future."

He's right. This is especially true when running Linux -- or any other operating system -- on servers or the cloud. You won't like the performance hit, but you'd dislike the security breaches even more.

Related stories

Editorial standards