Even with all the light shed on Spectre over the past nearly two years, with the Spectre RSB (Return Stack Buffer) disclosure that did affect IBM POWER processors it turns out the mitigations applied didn't cover all of the CPUs that should have been in place until this week.

Adding to the list of changes on deck for the Linux 5.5 kernel is a new "sanitizer" for spotting data race conditions.

LinuxBoot is approaching two years of age as the effort led by Facebook and others for replacing some elements of the system firmware with the Linux kernel.

IBM developers and others continue exploring the potential for address space isolation in the Linux kernel to reduce the risk of leaking sensitive data in attacks like L1 Terminal Fault (L1TF), MDS, and other vulnerabilities. Though this does increase the complexity of the kernel code and the performance hit is still to be evaluated.

We first wrote about the Landlock Linux security module in 2016 with its aspirations for offering powerful security sandboxing abilities. Landlock has seen revisions every few months and this week marks the 11th time the patches have been volleyed for this interesting sandboxing Linux Security Module (LSM).

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.