Two years after the "Stack Clash" vulnerability came to light, the LLVM compiler is working on adding protection against it similar to the GCC compiler mitigation.

The Linux kernel will begin doing a basic sanity check of x86_64 CPUs with the RdRand instruction to see if it's at least returning "random looking" data otherwise warn the user at boot time. This stems from a recent issue where AMD's RdRand behavior with some hardware (particularly, buggy motherboards) could have borked RdRand issues.

With all of the CPU security bugs over the past two years and heightened concerns about hardware vulnerabilities in general, the upstream Linux kernel has been working to create a formal process for dealing with the disclosure process and addressing said issues within the kernel code.

In addition to the work being led by DigitalOcean on core scheduling to make Hyper Threading safer in light of security vulnerabilities, IBM and Oracle engineers continue working on Kernel Address Space Isolation to help prevent data leaks during attacks.

After going through 40+ rounds of revisions and review, the Linux kernel "LOCKDOWN" feature might finally make it into the Linux 5.4 mainline kernel.

The long-running Linux "Lockdown" patches were sent out again overnight for their 40th time but it remains to be seen if these security-oriented patches will be pulled in for the upcoming Linux 5.4 cycle.

CVE-2019-1125 was made public today or also referred to as the "SWAPGS" vulnerability as a new variant of Spectre V1 affecting Windows and Linux with Intel (and according to mixed information, AMD - though the current Linux kernel patches at least seem to only apply to Intel) x86_64 processors.

Kernel Address Space Isolation is an experimental feature in development by Oracle in aiming to prevent leaking sensitive data from Intel Hyper Threading due to speculative execution attacks like L1TF.

It didn't make it for the Linux 5.2 kernel and now it's up to its 33rd revision on the Linux kernel mailing list... The "lockdown" patches for locking down access to various kernel hardware features has been reworked now and is a Linux Security Module (LSM) as it still tries to get enough endorsements to be mainlined.

As Netflix's first security bulletin for 2019, they warned of TCP-based remote denial of service vulnerabilities affecting both Linux and FreeBSD. These vulnerabilities are rated "critical" but already being corrected within the latest Git code.

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.