Approaching the two year anniversary next month of the L1TF / Foreshadow vulnerability, a Google engineer has proposed allowing the default mitigation state to be controlled via a Kconfig build-time option.

Version 0.8 of the Linux Kernel Runtime Guard (LKRG) has been released for further enhancing the runtime security provided by this out-of-tree kernel code plus other general improvements.

This weekend we reported on how injecting ACPI tables could lead to bypassing Linux's lockdown / UEFI Secure Boot protections and let attackers load unsigned kernel modules. That earlier issue was found on a patched version of the Ubuntu 18.04 LTS kernel while now a similar attack vector has been discovered on the mainline Linux kernel.

There are some urgent fixes pending for the x86/x86_64 speculative execution handling for the Linux kernel following a Google security engineer discovering these issues, including one of the fixes address a situation that unfairly impacted AMD CPUs.

Security Enhanced Linux is seeing some nice optimizations with the in-development Linux 5.8 kernel.

For those very concerned about CPU data sampling vulnerabilities, the Linux 5.8 kernel comes with the ability to flush the L1 data cache on each context switch. That's good for security, but will hurt the system performance with all the excess L1 cache flushing.

As a result of at least "a few AArch64 platforms" lacking firmware support for mitigating Spectre Variant Two, Google engineers are evaluating the possibility of Retpolines for the 64-bit Arm architecture.

The Linux kernel patches that have been spearheaded by Amazon AWS engineers to optionally flush the L1 data cache on each context switch have now been queued in the x86/mm branch ahead of the upcoming Linux 5.8 kernel cycle.

Thunderspy is a class of seven vulnerabilities found within Intel's Thunderbolt 3 hardware and the researchers having found nine realistic scenarios for exploiting these Thunderbolt issues across platforms.

The latest Linux kernel security work being pursued by Thomas Gleixner is tightening up access around the kernel's per-CPU TLB state access for the translation lookaside buffer.

Patches have been revised for allowing Linux to support kernel stack base address offset randomization for each system call.

A new patch series sent out just under one month ago was providing opt-in L1 data cache flushing on context switching. That work has now been revived again and now with documentation added it's clear that this work is being done in response to a recent CVE being made public.

A few months back when we last looked at the performance impact of having SELinux enabled there was a hit but not too bad for most workloads. But we'll need to take another look soon as with the Linux 5.7 kernel are some performance improvements and more for SELinux.

Earlier this month there was the proposal by a Linux kernel engineer for Amazon to flush the L1 data cache on context switches as another safeguard against the ever increasing CPU vulnerabilities.

Going back to over a year ago were discussions by Oracle engineers and others about a secure launch boot protocol for the Linux kernel to in turn tie into the Trenchboot open-source project working on various system integrity features. We are now finally seeing new patches out of Oracle for wiring more Trenchboot support into the Linux kernel.

It turns out the Point-to-Point Protocol Daemon (PPPD) used for dial-up models, DSL, and other point-to-point network setups on Linux has been bugged for the past seventeen years with a buffer overflow vulnerability that could lead to remote code execution at the system level.

While there are many new features in the forthcoming Linux 5.6 kernel, the ongoing Address Space Isolation support is not one of them.

Fuzzing is an important means of finding unintended/invalid behavior within software and now there exists a fuzzer for providing Spectre-type vulnerabilities.

Herbert Xu sent in all of the crypto subsystem changes on Tuesday for the in-development Linux 5.6 kernel. Interesting us the most out of this crypto work is the AMD Trusted Execution Environment (TEE) driver.

SELinux maintainer Paul Moore sent in the Security Enhanced Linux updates for the 5.6 merge window, which amounts to "one of the bigger SELinux pull requests in recent years."

Back in September was an initial "request for comments" by Google on some kernel work they are doing with Kernel Runtime Security Instrumentation (KRSI) for providing eBPF-powered security helpers, ultimately for creating dynamic MAC and audit policies. Just before Christmas the first official version of this new eBPF-based instrumentation was sent out and is being prepared for deployment within Google.

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.