Linux Archive

Examining btrfs, Linux’s perpetually half-finished filesystem

Btrfs—short for “B-Tree File System” and frequently pronounced “butter” or “butter eff ess”—is the most advanced filesystem present in the mainline Linux kernel. In some ways, btrfs simply seeks to supplant ext4, the default filesystem for most Linux distributions. But btrfs also aims to provide next-gen features that break the simple “filesystem” mold, combining the functionality of a RAID array manager, a volume manager, and more. We have good news and bad news about this. First, btrfs is a perfectly cromulent single-disk ext4 replacement. But if you’re hoping to replace ZFS—or a more complex stack built on discrete RAID management, volume management, and simple filesystem—the picture isn’t quite so rosy. Although the btrfs project has fixed many of the glaring problems it launched with in 2009, other problems remain essentially unchanged 12 years later. One of those projects we’ve been hearing about for years. I think most distributions still default to ext4 – except for Fedora.

Linux 5.14 released with new hardware support, core scheduling, MEMFD_SECRET

Version 5.14 of the most popular operating system kernel in the world has been released. See the Linux 5.14 feature list for a comprehensive list of the changes in this new kernel version. Some of the Linux 5.14 highlights include core scheduling support, secret memory areas support with MEMFD_SECRET, continued enablement around Intel Alder Lake, Yellow Carp and Beige Goby AMD graphics support, AMD SmartShift laptop support, Raspberry Pi 400 support, and more. Linux 5.14 has the usual mix of new hardware support, improving existing features, and adding in other new kernel innovations. Coming to a distribution near you.

Void Linux: excellent choice for more advanced Linux users

Void is a general purpose operating system, based on the monolithic Linux kernel. Its package system allows you to quickly install, update and remove software; software is provided in binary packages or can be built directly from sources with the help of the XBPS source packages collection. Void Linux is one of my favourite distributions, but since it employs a rolling release model, I never really get the opportunity to highlight it. So, I’m picking this random day to talk about it. If you’re fairly proficient in “install and go” Linux distributions like Ubuntu, Fedora, Manjaro, etc., and want to get a better insight into a Linux system without going overboard, Void is a great choice. It’s easy to install, easy to grasp and manage manually because it eschews systemd in favour of runit, it has an excellent community, and the package repository is far, far larger than you’d expect. Void also offers both GNU libc and musl versions. Void is a bit more hands-on than e.g. Ubuntu, but not over the top like some other distributions. Setting up a Void Linux system will teach you quite a bit about how a Linux system works, but the no-nonsense, logical layout of it all means you’re not going to be overwhelmed. It also happens to be one of the few distributions that take ppc64le seriously thanks to a dedicated community, so it’s my system of choice there. It’s not for everyone, and if you just want a no-nonsense desktop experience with minimal fuss, you’re better off with Linux Mint or Manjaro or similar systems, but if you want to get your hands a little bit dirty, you can do a lot worse than Void.

Asahi Linux August progress report

Asahi Linux, the effort to port Linux to Apple’s new M1 SoC, has posted its second progress report. It’s been a long time since the last update! In all honesty, the first Progress Report set the bar a little bit too high, and I found it difficult to sit down and put together monthly reports that would do it justice. So, going forward, we’re going to be providing shorter-form updates while striving to keep a monthly schedule. That said, a lot has happened in the past few months, so strap in for a bigger update this time! Quite a lot of detail in here, and lots of insights into the reverse engineering processes the developers are implementing.

AMD and Valve working on new Linux CPU performance scaling design

It’s no secret that the ACPI CPUFreq driver code has at times been less than ideal on recent AMD processors with delivering less than expected performance/behavior with being slow to ramp up to a higher performance state or otherwise coming up short of disabling the power management functionality outright. AMD hasn’t traditionally worked on the Linux CPU frequency scaling code as much as Intel does to their P-State scaling driver and other areas of power management at large. AMD and Valve have been working to improve the performance/power efficiency for modern AMD platforms running on Steam Play (Proton / Wine) and have spearheaded “ was not very performance/power efficiency for modern AMD platforms…a new CPU performance scaling design for AMD platform which has better performance per watt scaling on such as 3D game like Horizon Zero Dawn with VKD3D-Proton on Steam.” Valve has single-handedly made Linux a viable choice for people who play games, and with the Steam Deck on its way, their efforts are only going to ramp up. They’re doing this for their own bottom line, of course, but this is one of those cases where a corporate interest lines up perfectly with a consumer interest.

Linux 5.14 drops old DEC Alpha-specific binary loader used for x86 binary emulation

As a weekend blast from the past, the Linux 5.14 kernel saw some Alpha CPU architecture updates — including various fixes and the removal of an Alpha-specific binary loader for running a decades dated x86 software emulator. While past the merge window, the Linux 5.14 code this week has dropped “binfmt_em86” from the kernel. This is an Alpha binary loader for Linux focused on running i386/i486 binaries via the EM86 emulator in user-space. This was part of the effort for allowing Intel Linux x86 binaries back in the day to run on DEC Alpha hardware. How will I run x86 Linux binaries on my AlphaServer ES47 now? What a preposterous commit. Linux is definitely going down the drain.

A look into CBL-Mariner, Microsoft’s internal Linux distribution

First thing to understand about Mariner is that is not a general purpose Linux distribution like Ubuntu or Fedora, it was created by Microsoft’s Linux System Group which is the same team at Microsoft which created the Linux kernel used for Windows Subsystem for Linux version 2, or WSL2. The goal of Mariner is to be used as an internal Linux distribution for Microsoft’s engineering teams to build our cloud infrastructure and edge products and services. Of course Mariner is open source and it has its own repo under Microsoft’s GirHub organization. No ISOs or images of Mariner are provided, however the repo has instructions to build them on Ubuntu 18.04. There are a series of prerrequistes listed in this GitHub page that roughly include Docker, RPM tools, ISO build tools and Golang, amongst others. Not surprising, of course, but still quite interesting to poke around in.

PipeWire under the hood

In this post I’ll try to explain PipeWire in the most simple way possible, to make it accessible to others that want to start following this cool new project but that don’t know where to start. It’s especially important to do this to open the door for more people to join in and follow the current development, which is happening at a fast pace. PipeWire is making its way into the generic Linux desktop market, so now is as good a time as ever to gain a better understanding of what it is and how it works.

Google wants to see Rust code in the Linux kernel, contracts the main developer

Google wants to see Rust programming language support within the Linux kernel so much so that they have contracted the lead developer working on “Rust for Linux” as the work aims to get mainlined. Google is going public today with their formal support for Rust in the Linux kernel to enhance memory safety and that they have contracted developer Miguel Ojeda to further his work on Rust for the Linux kernel and related security efforts. This contract is going through at least the next year. Making any meaningful statements about programming languages is far above my pay grade, so I’ll leave this one to you people to discuss.

Linux 5.12 released

Linux 5.12 brings Intel Variable Rate Refresh (VRR/Adaptive-Sync), Radeon RX 6000 series overclocking support, mainline support for the Nintendo 64, the Sony PlayStation 5 DualSense controller driver, CXL 2.0 Type-3 memory device support, KFENCE, dynamic preemption capabilities, Clang link-time optimizations, laptop support improvements, and much more. A decently sized release. My favourite is definitely adding N64 support to the kernel.

University banned from contributing to Linux kernel after intentionally submitting vulnerable code

A statement from the University of Minnesota Department of Computer Science & Engineering: Leadership in the University of Minnesota Department of Computer Science & Engineering learned today about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel. The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel. We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues, if needed. We will report our findings back to the community as soon as practical. This story is crazy. It turns out researchers from the University of Minnesota were intentionally trying to introduce vulnerabilities into the Linux kernel as part of some research study. This was, of course, discovered, and kernel maintainer Greg Kroah-Hartman immediately banned the entire university from submitting any code to the Linux kernel. Replying to the researcher in question, Kroah-Hartman wrote: You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work. Now you submit a new series of obviously-incorrect patches again, so what am I supposed to think of such a thing? They obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns, and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches? Our community does not appreciate being experimented on, and being “tested” by submitting known patches that are either do nothing on purpose, or introduce bugs on purpose. If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here. Because of this, I will now have to ban all future contributions from your University and rip out your previous contributions, as they were obviously submitted in bad-faith with the intent to cause problems. This is obviously the only correct course of action, and the swift response by the university is the right one.

Linus Torvalds weighs in on Rust language in the Linux kernel

Although we don’t expect to see a full implementation of the Linux kernel in Rust anytime soon, this early work on integrating Rust code into the kernel’s C infrastructure is likely to be very important. Both Microsoft and the Linux community agree that two-thirds or more of security vulnerabilities stem from memory-safety issues. As software complexity continues to increase, making it safer to write in the first place will become more and more important. Torvalds’ pragmatism is one of the key reasons for Linux’ success, and I have no doubt his position and opinions on Rust in the Linux kernel will turn out to be the right ones.

Do you really want Linux phones?

The community around Linux phones is interesting. The phones do sell to a lot of people, but it seems a lot of those people come back to complain that Linux phones isn’t what they expected it is. For some reason all the distributions for the PinePhone are bending over backwards to provide an Android or iOS experience on the phone. The operating systems are judged on the amount of apps preinstalled and every tiny issue labels the distribution as completely unusable. Stability doesn’t matter at all, as long as there are features! more features! Doesn’t matter there are 20 patches on top of every package and things aren’t upstreamed. Doesn’t matter if the kernel is full of hacks with no upstream in sight for most things. The currently available ‘true’ Linux phones do not seem to be, well, any good. They’ve got a lot of work ahead of them, and anybody expecting a fully functioning smartphone experience from the PinePhone or Librem 5 will be disappointed. I have no clue about possible solutions to this problem.

The modern packager’s security nightmare

One of the most important tasks of the distribution packager is to ensure that the software shipped to our users is free of security vulnerabilities. While finding and fixing the vulnerable code is usually considered upstream’s responsibility, the packager needs to ensure that all these fixes reach the end users ASAP. With the aid of central package management and dynamic linking, the Linux distributions have pretty much perfected the deployment of security fixes. Ideally, fixing a vulnerable dependency is as simple as patching a single shared library via the distribution’s automated update system. Of course, this works only if the package in question is actually following good security practices. Over the years, many Linux distributions (at the very least, Debian, Fedora and Gentoo) have been fighting these bad practices with some success. However, today the times have changed. Today, for every 10 packages fixed, a completely new ecosystem emerges with the bad security practices at its central point. Go, Rust and to some extent Python are just a few examples of programming languages that have integrated the bad security practices into the very fabric of their existence, and recreated the same old problems in entirely new ways. This post explains the issue packagers run into very well – and it sure does look like these newer platforms are not very good citizens. I know this isn’t related, but this gives me the same feelings and reservations as Flatpak, Snap, and similar tools.

It’s 2021 and the Linux kernel’s floppy driver is still seeing the occasional patch

The Linux kernel’s floppy driver dates back to the original days of the kernel back in 1991 and is still being maintained thirty years later with the occasional fix. Somewhat surprisingly, a patch was sent in to the Linux kernel’s block subsystem ahead of the Linux 5.12 merge window around the floppy code. Floppies are awesome and I’m sure there’s tons of older machines out there – especially in corporate settings – that are still rocking a floppy drive for backwards compatibility reasons. Might as well keep the code up to snuff.

Bedrock Linux: a meta Linux distribution

Bedrock Linux is a meta Linux distribution which allows users to mix-and-match components from other, typically incompatible distributions. Bedrock integrates these components into one largely cohesive system. You think you’ve seen everything the Linux world has to offer and nothing can you surprise you anymore, and then you run into something like this. I wonder how well this works if a Bedrock Linux installation holds up over time.

Fast commits for ext4

The Linux 5.10 release included a change that is expected to significantly increase the performance of the ext4 filesystem; it goes by the name “fast commits” and introduces a new, lighter-weight journaling method. Let us look into how the feature works, who can benefit from it, and when its use may be appropriate. Better file system performance is always welcome, especially when it concerns what is probably the most common file system among desktop Linux users.

How we ported Linux to the M1

It also made Apple silicon rather distinct from all other 64-bit ARM hardware in terms of both CPU core and peripherals. Our Corellium virtualization platform has been providing security researchers with unparalleled insight into how operating systems and programs work on Apple ARM processors. But in the process of developing our virtualization system, we also gain knowledge about the hardware we are modeling, and this knowledge can be best refined by testing it against real hardware – which we have only been able to do with the emergence of checkm8, an exploit that let us load programs onto Apple smartphones. This led directly to the Sandcastle project, where we built a kernel port to the A10 processor in early 2020. So when Apple decided to allow installing custom kernels on the Macs with M1 processor, we were very happy to try building another Linux port to further our understanding of the hardware platform. As we were creating a model of the processor for our security research product, we were working on the Linux port in parallel. Excellent work by Corellium, and this materialised a lot faster than I anticipated. This makes M1-equipped Macs potentially more useful than if they could only run macOS, but of course, as with all these closed platforms and Linux support, the devil is in the details – bringing up a Linux kernel is only the first step – a big and crucial one, but only the first.

Wine 6.0 released

Among the many highlights for Wine 6.0 are core modules now being implemented in Portable Executable (PE) format, the initial (experimental) Vulkan back-end for WineD3D as an alternative to OpenGL, DirectShow and Media Foundation support, and a redesign of their text console implementation. Wine is such an integral part of my computing life now, due to Proton and Valve.