Linux Archive

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.

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.

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.

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.

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.

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.

The Wine program for running Windows games/applications on Linux and other platforms can run on a number of different architectures, but Wine doesn’t handle the emulation of running Windows x86/x64 binaries on other architectures like 64-bit ARM or PowerPC. But that’s what the Wine-based Hangover is about with currently allowing those conventional Windows binaries to run on AArch64 (ARM64) and 64-bit POWER too. Hangover started out with a focus on Windows x64 binaries on ARM64 in looking at the possible use-case of running Windows software on ARM mobile devices and more. This year with the help of Raptor Computing Systems there has been Hangover support added for IBM POWER 64-bit. It would be really amazing if Linux on POWER could make use of WINE like regular x86 Linux users can. It’s a long way off, still, but progress is being made.

Linux 5.9 is out as the 2020 autumn kernel update. Linux 5.9 has a number of exciting improvements including initial support for upcoming Radeon RX 6000 “RDNA 2” graphics cards, initial Intel Rocket Lake graphics, NVMe zoned namespaces (ZNS) support, various storage improvements, IBM’s initial work on POWER10 CPU bring-up, the FSGSBASE instruction is now used, 32-bit x86 Clang build support, and more. It will make its way to your distribution eventually, to your separate kernel repository, or, for the brave ones, to your compile command.

This version of the book has undergone a major reorganization. It uses enhanced cross-compilation techniques and an environment isolated from the host system to build tools for the final system. This reduces both the chance for changing the the host system and the potential of the host system influencing the LFS build process. Major package updates include toolchain versions glibc-2.32, gccc-10.2.0, and binutils-2.35. In total, 37 packages were updated since the last release. The Linux kernel has also been updated to version 5.8.3. There’s a separate version for systemd – for those so inclined.