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.

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.