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.
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 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 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.
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.
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.
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.
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.
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 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.
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.
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.
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.
NVIDIA’s Wayland support is finally coming together albeit long overdue with DMA-BUF passing support and now patches pending against XWayland for supporting OpenGL and Vulkan hardware acceleration with their proprietary driver. Pending patches to the X.Org Server’s XWayland code paired with a yet-to-be-released proprietary driver update finally allow for hardware accelerated rendering with XWayland. NVIDIA is really holding Wayland back, so it’s good to see progress on this front.
Here’s a port for the Nintendo 64. At least two people have done such a port before, but didn’t submit. This is not based on either. RFC because I’m not sure if it’s useful to have this merged. Old, niche, and limited platform. “But why”, I hear from the back. Having Linux available makes it easier to port emulators and fb or console games. Yep. Linux on the Nintendo 64.
After several months of work, we are excited to announce a first proposal for a Wayland driver for Wine. At this point the proposal is in the form of an RFC (Request For Comment), in order to explore how to best move forward with the upstreaming and further development of the driver. The Wayland protocol is by design more constrained compared to more traditional display systems like X11 and win32, which brings a unique sets of challenges in the integration of Wayland with Wine. Since Wayland’s window model is not based on a single flat 2D co-ordinate space, as X11’s was, the Wayland protocol doesn’t allow apps to control their absolute position on the screen. Win32 applications heavily rely on this feature, so the Wayland driver uses a few tricks to accommodate many common cases, like transient windows (menus, tooltips etc). This is an important first step in ensuring Wine performs optimally on Wayland systems, and considering the importance of Wine for the Linux desktop due to projects like Proton, this really needs to be sorted before a full move to Wayland can be made.
As expected, Linus Torvalds today officially released Linux 5.10. Besides being the last kernel release of 2020, this is a significant milestone in that it’s also a Long Term Support (LTS) kernel to be maintained for at least the next five years and also is a huge kernel update in general with many new features. Linux 5.10 features new hardware support including early bring-up around Intel Rocket Lake and Alder Lake, continued work on Intel Gen12/Xe Graphics, a number of storage/file-system improvements, and more. It will either trickle down to your distribution, or to the mainline repository you use.
oasis is a small linux system. It is probably quite a bit different from other Linux-based operating systems you might be familiar with, and is probably better compared to a BSD. There are many features that distinguish it from other operating systems. It’s entirely statically linked, uses various smaller, more compact alternatives to components you’d normally find in a Linux system, and it’s entirely focused on simplicity. I find it quite attractive on paper.
In my previous post, I described running Arch on an OpenWRT router. Today, I’ll be taking it a step further and running Arch and a full LXDE installation natively on an Amazon Kindle, which can be interacted with directly using the touch screen. This is possible thanks to the Kindle’s operating system being Linux! Neat.
This is a project providing a Linux-like OS for systems based on the Intel IA16 architecture (16-bit processors: 8086, 8088, 80188, 80186, 80286, NEC V20, V30, and compatibles). Such systems are ancient computers (IBM-PC XT/AT and clones), or more recent SBC/SoC/FPGA that reuse the huge hardware & software legacy from that popular platform. Definitely an interesting and impressive project.