The Month in Linux [0x01]

Okay, let's give this monthly roundup thing a go! So the plan is to pick out some highlights that I think are interesting and worth sharing from the last month or so in the Linux space. Caveat of course being unfortunately I have to do other lame things like eat and sleep, so feel free to let me know if I've missed anything cool!

Rust for Linux

Due to it's emphasis on memory safety, among other things, and increasing popularity there's been growing momentum to introduce Rust^[1] as a second programming language for the Linux kernel.

The drive is being coordinated by the aptly named Rust for Linux project and has been making progress; earlier in June it was announced that the Internet Security Research Group has contracted - with financial support from Google - Linux kernel developer Miguel Ojeda to work full-time on the project.^[2]

From what I gather there's still a ways to go before we see it mainlined. Regardless of the potential pros/cons of Rust vs C in the Linux kernel, I think the fact that after 30 years of solely C that the question of introducing a second language is being asked and actively discussed within the community is a good sign of the longevity of the Linux kernel in its ability to continuously improve and evolve.

For more information, I'd check out this lwn article for a more nuanced discussion on Rust for Linux and where is sits within the kernel development community.

Linux 5.13 Kernel

On the 27th June we saw the release of the 5.13 Linux kernel, which is one of the larger 5.x releases with contributions from over 2000 developers! Among the many new features are:

Early support for Apple's M1 chip
AMD GPU FreeSync/Adaptive-Sync (pre 2.1) HDMI support
Support for Clang's control flow integrity (CFI) enforcement
Kernel stack randomisation (boot param randomize_kstack_offset) support for every syscall

Find out more over at Phoronix, lwn & itsfoss.

15 Year Old Netfilter Vuln

On March 30th Google security engineer @_tsuro announced the 1.0 release of kCTF, a Kubernetes based infrastructure for CTFs. Two days later?

I broke it :) https://t.co/FJc4WcOM7n
— Andy Nguyen (@theflow0) April 1, 2021

A few months later, Andy Nguyen has published an awesome write-up for how he used a 15 year old heap out-of-bounds write vulnerability in Netfilter to bypass SMAP, KASLR and break the Kubernetes pod isolation.

Steam Deck

On the 15th of July Valve formally announced the Steam Deck, a portable handheld console.^[1] Except it's not a console, but "all-in-one portable gaming PC with an integrated controller" is a bit of a mouthful. So wait, it's NOT a console?

Nope! Out-of-the-box the Steam Deck runs the latest version of Valve's Arch-based SteamOS. But ... it doesn't have to. There is no walled garden with the Steam Deck like you come to expect with consoles, instead you have full control to install any game stores, applications or even a completely different OS.

Now what's really exciting about this is the knock-on effect the Steam Deck is already having for all Linux gamers. Valve has contributed a lot in the past to Linux gaming (which seems to make even more sense now, ey?), helping Linux gamers run a large swathe of Windows games through WINE based compatibility layer Proton^[2].

However one persistent thorn in every Linux gamer's side has been anti-cheat support. While vendors such as Easy Anti-Cheat (EAC) and BattleEye have native Linux builds, the Windows builds rely on kernel interactions which Proton does not support.

But now with the impending release of the Steam Deck, Valve has announced it intends to work with anti-cheat vendors (EAC and BattleEye have been named in particular) to remove this barrier BEFORE the Steam Deck ships. Not only this, but Valve aims to have EVERY Windows game working on the Steam Deck at release.^[3]

I'd be lying if I said I wasn't sceptical but as one of the 0.85%^[4] of Steam users playing games on Linux I'm excited to see closer parity with Windows gaming. I'm also interested to see what longer term impacts the Steam Deck's arrival on the scene will have to the Linux gaming market-share, and in a market of handhelds long dominated by Nintendo, with SteamOS free for other manufacturers to use, will we see any other contenders?

Extras

We saw NVIDIA add DLSS support for Proton, initial support for hardware accelerated OpenGL and Vulkan rendering on Xwayland^[1]; showcase RTX & DLSS support on Arm^[2] and finally announce native DLSS SKD support for Linux^[3]
Oh and last week on July 20th, Nvidia sent out a security bulletin over several CVEs affecting Linux (and Windows) GPU drivers 😬
AMD released FidelityFX^[4] (their version of DLSS) along with it's source code shortly after^[5]

exit(0);