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.
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.
This article is targeted at embedded engineers who are familiar with microcontrollers but not with microprocessors or Linux, so I wanted to put together something with a quick primer on why you’d want to run embedded Linux, a broad overview of what’s involved in designing around application processors, and then a dive into some specific parts you should check out — and others you should avoid — for entry-level embedded Linux systems. This is some seriously detailed writing, and an amazing starting point for people interested in developing for embedded Linux.
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.
Automotive Grade Linux is a collaborative open source project that is bringing together automakers, suppliers and technology companies to accelerate the development and adoption of a fully open software stack for the connected car. With Linux at its core, AGL is developing an open platform from the ground up that can serve as the de facto industry standard to enable rapid development of new features and technologies. It’s got some big names backing it.
As Phoronix notes: See our Linux 5.8 feature overview for all the exciting changes from an AMD Energy Driver for Zen/Zen2 CPUs to new F2FS compression capabilities, POWER10 CPUs starting to boot with the mainline kernel code, power management improvements, and much more. This is also the first major kernel release featuring the new inclusive terminology guidelines. You can build it yourself, or just wait until it trickles down into your distribution of choice.
Since I wanted to see how Linux would detect the drive that meant I needed to find a way to boot Linux. After a bit of googling I discovered the make tinyconfig option which makes a very small (but useless) kernel, small enough to fit on a floppy. I enabled a couple of other options, found a small enough initramfs, and was able to get it to boot on the 486. And as expected Linux has no problem with seeing that the drive is connected and the drive’s full capacity. Next step is to actually get Linux installed to the hard drive. I’d rather not roll my own distro but maybe I’ll have to. Another possibility is to boot Linux from floppy and then download a kernel and initrd from a current distro and kexec over to it. But that feels to me like reinventing iPXE. That’s version 5.8 of the Linux kernel running on a 486. I shouldn’t be surprised that this is possible, yet I’m still surprised this is possible.