With tests over the past week following the disclosure of the Microarchitectural Data Sampling (MDS) vulnerabilities also known as "Zombieload", we've looked at the MDS mitigation costs (and now the overall Spectre/Meltdown/L1TF/MDS impact) for desktop CPUs, servers, and some laptop hardware. I've also begun doing some tests on older hardware, such as some Phoronix readers curious how well aging Intel Haswell CPUs are affected.

The default Linux mitigations for the new Microarchitectural Data Sampling (MDS) vulnerabilities (also known as "Zombieload") do incur measurable performance cost out-of-the-box in various workloads. That's even with the default behavior where SMT / Hyper Threading remains on while it becomes increasingly apparent if wanting to fully protect your system HT must be off.

Beginning with the Linux 5.2 kernel, it will be easier to disable Spectre, Meltdown, and other CPU vulnerability mitigations if you prefer maximum performance out of your system instead.

Developers at IBM are working on a new concept for the Linux kernel of "system call isolation" in order to isolate parts of the kernel when impacted by vulnerabilities.

Going back to the late Linux 2.6 kernel days has been the CONFIG_DMESG_RESTRICT (or for the past number of years, renamed to CONFIG_SECURITY_DMESG_RESTRICT) Kconfig option to restrict access to dmesg in the name of security and not allowing unprivileged users from accessing this system log. While it's been brought up from time to time, Linux distributions are still generally allowing any user access to dmesg even though it may contain information that could help bad actors exploit the system.

The effort to provide a more convenient / easy to remember kernel option for toggling Spectre/Meltdown mitigations is out with a second revision and they have also shortened the option to remember.

By the time the next Linux kernel is released it will have been roughly a year and a half since the Spectre and Meltdown CPU speculative execution vulnerabilities went public and the mitigations started appearing within the kernel. Finally now it's being discussed again by upstream developers over improving the switches / tunable knobs for easily configuring these performance-degrading mitigations.

As the latest on the Spectre/Meltdown front for the Linux kernel, the in-development Linux 5.1 kernel is bringing an optimization for Retpolines "return trampolines" so GCC will generate more efficient code on x86/x86_64 in its mitigations against Spectre Variant Two.

SPOILER is the newest speculative attack affecting Intel's micro-architecture.

The initial version of the WireGuard open-source secure VPN tunnel is now available for macOS, following the WireGuard for iOS port a few months prior. But sadly on the Linux front, the kernel bits still have yet to be mainlined.

With the upcoming Linux 5.0 kernel release there is initial support for Adiantum and implemented within the fscrypt file-system encryption framework in Google's pursuit to offering more viable data encryption on low-end Android devices.

For the Linux kernel's Speculative Store Bypass Disable (SSBD) handling for Spectre Variant 4 protection is support for processes opting into force disabling of speculation via a prctl() interface. Currently when speculation is disabled, that is carried through to new processes started via the execve() system call. But a new bit will allow clearing that state when a new program is started by a process otherwise relying upon PR_SPEC_DISABLE, in what will help the performance in such cases.

While running the Windows vs. BSD vs. Linux 10GbE network benchmarks among other recent 10GbE Linux network performance figures, the test request came in from a premium patron to look at the current 10GbE network performance hit as a result of the default Spectre+Meltdown mitigations.

With the Linux 5.1 kernel cycle that should get underway in just over one month's time, there will now be the long in development work (it's been through 15+ rounds of public code review!) for supporting atomic replace and cumulative patches.

It's been nearly one year to the day since the Spectre and Meltdown vulnerabilities were made public. While the security vulnerabilities were quickly buttoned up in the Linux space, kernel developers continue working to offset the performance overhead introduced by these mitigations. They made a lot of overhead reductions in 2018 while still there are some patch-sets pending still for bettering the experience. One of these patch-sets was known as "Relpolines" but now has been updated and morphed into what is being called Optpolines.

Nearly one year after the Spectre vulnerabilities were first published, Freescale/NXP PowerPC processors are being mitigated against Spectre Variant Two with the in-development Linux 4.21 kernel.

University researchers out of University of California Riverside have published a paper this week detailing vulnerabilities in current GPU architectures making them vulnerable to side-channel attacks akin to Spectre and Meltdown.

While WireGuard didn't make it for Linux 4.20 to the mainline kernel, if you are using an Apple tablet or phone, there is now an app that allows you to use WireGuard on iOS.

A new CPU side-channel vulnerability made public today that's unrelated to Spectre and Meltdown speculative execution vulnerabilities is dubbed "PortSmash" but more formerly referred to as CVE-2018-5407.

Originally attempted for the Linux 4.19 kernel but not merged that cycle was the STACKLEAK GCC plug-in that was ported for the mainline code-base from the Linux GrSecurity patch-set. That plug-in is now trying to get into the Linux 4.20 (or perhaps relabeled as 5.0) kernel.

On the Spectre front for the recently-started Linux 4.20~5.0 kernel is STIBP support for cross-hyperthread Spectre Variant Two mitigation.

Nadav Amit of VMware has announced their (currently experimental) work on "dynamic indirect call promotion" or what they have dubbed "RELPOLINES" -- not to be confused with the traditional Retpolines for "return trampolines" as one of the Spectre Variant Two software-based mitigation approaches. Relpolines is designed to have lower overhead than Retpolines.

We are approaching one year since the Spectre and Meltdown CPU vulnerabilities shocked the industry, and while no new CPU speculative execution vulnerabilities have been made public recently, the Linux kernel developers continue improving upon the Spectre/Meltdown software-based mitigation techniques for helping to offset incurred performance costs with current generation hardware.

Speculative Store Bypass Safe (SSBS) is a new bit added with ARMv8.5-A for SoCs moving forward like the ARM Cortex-A76 as a means for mitigation against Spectre V4.

Git maintainer Junio Hamano issued new versions of this widely-used version control system today going back to the Git 2.14 release series in order to address a new security vulnerability.

Last week at Kernel Recipes 2018 in Paris, WireGuard lead developer Jason Donenfeld presented on the Zinc crypto API that he has been developing for the Linux kernel to suit his in-kernel secure VPN tunnel needs but also to potentially replace the existing Linux crypto code in the future.

While the maintained Linux 4.x kernel branches have all seen a lot of work on L1TF/Foreshadow and other x86/x86_64 speculation execution mitigation work, the Linux 3.16.59 kernel is bringing a load of work for those still riding this old kernel base.

Besides the Spectre V2 userspace-userspace mitigation patches revised and sent out earlier today, some related Spectre V2 changes are now queued for soon merging to the mainline Linux kernel.

While the Linux kernel has been patched for months (and updated CPU microcode available) to mitigate Spectre Variant Two "Branch Target Injection" this has been focused on kernel-space protection while patches are pending now for userspace-userspace protection.

From June of 2014 with Linux 3.16 until last week, the Linux kernel was affected by another potential local privilege escalation bug.