Tag Archives: Kernel

Improved Spectre/Meltdown Switches Might Finally Come To The Linux Kernel


SECURITY --

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.

It’s been possible from the start to disable most of these mitigations at run-time (sans like __user pointer sanitization for Spectre V1) but the kernel command line parameters to use haven’t been the most straight-forward or easy to remember… There hasn’t been a global switch to kill Spectre/Meltdown mitigations in one easy-to-add option. At this stage to disable the mitigations on most patched Linux kernel releases it comes down to having to remember and add “pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable.” Similarly, if wanting to beef-up the security even more of the system with the “maximum mitigations” there are the “l1tf=full spec_store_bypass_disable=on spectre_v2_user=on” for better securing the system against these vulnerabilities but also hitting the performance even more severely due to HT/SMT being disabled among other measures.

Red Hat developer Josh Poimboeuf has reignited the upstream discussion over offering up some simpler command-line tunables for disabling these CPU speculation mitigations or driving up the protection, rather than having to remember all these multiple options. Poimboeuf’s initial proposal came down to a cpu_spec_mitigations= kernel option with values of off/auto/nosmt.

There has been some resistance to the “cpu_spec_mitigations=” name itself as it’s a bit long, but nothing conclusive has been decided for a shorter and better to remember string besides maybe just “spec_mitigations=” instead. The proposed patches cover just not x86_64 but also CPU spec vulnerabilities affecting ARM, s390, etc.

The work for now is still being discussed on the kernel mailing list and we’ll see what comes of this work, stay tuned.


WireGuard Sent Out Again For Review, Might Make It Into Linux 5.2 Kernel


LINUX KERNEL --

WireGuard lead developer Jason Donenfeld has sent out the ninth version of the WireGuard secure network tunnel patches for review. If this review goes well and lands in net-next in the weeks ahead, this long-awaited VPN improvement could make it into the mainline Linux 5.2 kernel.

WireGuard had aimed to be mainlined in the Linux kernel in 2018 but developers having objections to some elements of the new Zinc cryptography implementation had ultimately stalled that work. But now there’s these “v9” patches that address previous objections and so with a bit of luck we might see Zinc and WireGuard merged for Linux 5.2.

These updated patches no longer have Zinc ship with generated Assembly code but rather the Perl files are shipped that end up generating the Assembly code. The updates patches also have other Zinc improvements, various fixes, and other specific changes to address other technical items brought up during previous rounds of code review.

More details on the WireGuard v9 work can be found via this kernel mailing list thread. Here’s to hoping that the WireGuard kernel bits will be merged for Linux 5.2 as a big step forward for improving the VPN / secure network tunnel support for Linux systems this year. WireGuard also continues advancing on other platforms from Android to Windows to macOS/iOS.

Should you not be familiar with this increasingly popular network security tech over the past few years, visit WireGuard.com to learn more. WireGuard has already earned praise from Linus Torvalds among others — even US senators.


Linux 5.1-rc1 Kernel Released After A “Fairly Normal” Merge Window


LINUX KERNEL --

Linus Torvalds has just closed off the Linux 5.1 kernel merge window and issued 5.1-rc1 as the first test release.

Linux 5.1 was another busy merge window with the landing of a lot of patches from continued Intel Icelake enablement to Fastboot graphics by default to mainline Raspberry Pi 3 Model A+ support to a lot of other new hardware support… See today’s Linux 5.1 feature overview for our original report on all the interesting material in this next version of the Linux kernel.

If all goes well with the release candidates over the weeks ahead, Linux 5.1 should be officially released by the middle of May at which point the cycle repeats with the kicking off of the Linux 5.2 merge window.

Of the past two weeks in landing new code for Linux 5.1, Torvalds commented, “The merge window felt fairly normal to me. And looking at the stats, nothing really odd stands out either. It’s a regular sized release (which obviously means “big” – , but it’s not bigger than usual) and the bulk of it (just over 60%) is drivers. All kinds of drivers, the one that stands out for being different is the habanalabs AI accelerator chip driver, but I suspect we’ll be starting to see more of that kind of stuff. But there are all the usual suspects too – gpu, networking, block devices etc etc.

Stay tuned for the start of Linux 5.1 kernel benchmarks to trickle in beginning in the next week or so.


Intel P-State vs. CPUFreq Frequency Scaling Performance On The Linux 5.0 Kernel


It’s been a while since last running any P-State/CPUFreq frequency scaling driver and governor comparisons on Intel desktop systems, so given the recent release of Linux 5.0 I ran some tests for looking at the current state of affairs. Using an Intel Core i9 9900K I tested both the P-State and CPUFreq scaling drivers and their prominent governor options for seeing not only how the raw performance compares but also the system power consumption, CPU thermals, and performance-per-Watt.

Tested for this comparison was P-State powersave (the default on most distributions with Intel Sandy Bridge and newer), P-State performance, CPUFreq powersave, CPUFreq ondemand, CPUFreq performance, and CPUFreq schedutil (the newest governor for making use of scheduler utilization data to influence the governor’s decisions). All tests were done on the same Intel Core i9 9900K system and running at stock speeds (the reported frequency differences in the system table just come down to whether boost vs. base clock frequencies are reported via sysfs depending upon the driver).

Ubuntu 18.10 was running on the i9-9900K box with RX Vega 64 graphics card while using a near-final snapshot of Linux 5.0. The Phoronix Test Suite that was used for benchmarking these different frequency scaling drivers/governors was monitoring the AC power consumption in real-time using a WattsUp Pro as well as logging the CPU core temperature under each of the tested scenarios. Tests ranged from gaming benchmarks to traditional CPU and system benchmarks.


Xilinx Looking To Contribute Alveo FPGA Accelerator Drivers To The Linux Kernel


HARDWARE --

The upcoming Linux hardware accelerator subsystem could get even bigger with Xilinx now wanting to mainline their FPGA accelerator drivers.

Xilinx already has their Alveo FPGA kernel drivers as open-source as part of their Xilinx XRT Runtime while now they are hoping to get this support upstreamed in the Linux kernel.

Developers at Xilinx posted a request for comments on Wednesday with a link to their GitHub repository hosting this open-source kernel code. We’ll see if this code gets reviewed and ready for the Linux 5.2 cycle this summer.

The Alveo FPGAs are intended for machine learning, video transcoding, financial computing, genomics, and other workloads.