linux kernel

10 Articles

What Does Linux Need? A Dial!

May 30, 2025 by 9 Comments

It’s fair to say that there can’t be many developers who have found the need for a rotary telephone dial as a peripheral for their Linux computer, but in case you are among them you might find [Stefan Wiehler]’s kernel driver for rotary dials to be of use.

It’s aimed at platforms such as systems-on-chip that have ready access to extra GPIOs, of which it will need a couple to service the BUSY and PULSE lines. There are full set-up instructions, and once it’s in place and configured it presents the dial as though it were a number pad.

We like this project, in fact we like it a lot. Interfacing with a dial is always something we’ve done with a microcontroller though, so it will be interesting to see whether it finds a use beyond merely curiosity. We can already see a generation of old-school dial IP phones using Linux-capable dev boards. He leaves us with a brief not as to whether Linus Torvalds would see it as worthy of mainline inclusion, and sadly however much we want things to be different, we agree that it might be wishful thinking.

If you’d like to use a dial phone, there can be simpler ways to do it.

Header: Billy Brown, CC BY 2.0 .

Tracing The #!: How The Linux Kernel Handles The Shebang

April 11, 2025 by 9 Comments

One of the delights in Bash, zsh, or whichever shell tickles your fancy in your OSS distribution of choice, is the ease of which you can use scripts. These can be shell scripts, or use the Perl, Python or another interpreter, as defined by the shebang (#!) at the beginning of the script. This signature is followed by the path to the interpreter, which can be /bin/sh for maximum compatibility across OSes, but how does this actually work? As [Bruno Croci] found while digging into this question, it is not the shell that interprets the shebang, but the kernel.

It’s easy enough to find out the basic execution sequence using strace after you run an executable shell script with said shebang in place. The first point is in execve, a syscall that gets one straight into the Linux kernel (fs/exec.c). Here the ‘binary program’ is analyzed for its executable format, which for the shell script gets us to binfmt_script.c. Incidentally the binfmt_misc.c source file provides an interesting detour as it concerns magic byte sequences to do something similar as a shebang.

As a bonus [Bruno] also digs into the difference between executing a script with shebang or running it in a shell (e.g. sh script.sh), before wrapping up with a look at where the execute permission on a shebang-ed shell script is checked.

This Week In Security: The Geopolitical Kernel, Roundcube, And The Archive

October 25, 2024 by 13 Comments

Leading off the week is the controversy around the Linux kernel and an unexpected change in maintainership. The exact change was that over a dozen developers with ties to or employment by Russian entities were removed as maintainers. The unfortunate thing about this patch was that it was merged without any discussion or real explanation, other than being “due to various compliance requirements”. We eventually got more answers, that this was due to US sanctions against certain Russian businesses, and that the Linux Foundation lawyers gave guidance that:

If your company is on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company on the list, our ability to collaborate with you will be subject to restrictions, and you cannot be in the MAINTAINERS file.

So that’s that. One might observe that it’s unfortunate that a single government has that much control over the kernel’s development process. There were some questions about why Russian entities were targeted and not sanctioned Chinese companies like Huawei. [Ted Ts’o] spoke to that, explaining that in the US there are exemptions and different rules for each country and business. This was all fairly standard compliance stuff, up until a very surprising statement from [James Bottomley], a very core Kernel maintainer:

We are hoping that this action alone will be sufficient to satisfy the US Treasury department in charge of sanctions and we won’t also have to remove any existing patches.

Continue reading “This Week In Security: The Geopolitical Kernel, Roundcube, And The Archive” →

The Usage Of Embedded Linux In Spacecraft

February 10, 2024 by 46 Comments

As the first part of a series, [George Emad] takes us through a few examples of the Linux operating system being used in spacecraft. These range from SpaceX’s Dragon capsule to everyone’s favorite Martian helicopter. An interesting aspect is that the freshest Linux kernel isn’t necessarily onboard, as stability is far more important than having the latest whizzbang features. This is why SpaceX uses Linux kernel 3.2 (with real-time patches) on the primary flight computers of both Dragon and its rockets (Falcon 9 and Starship).

SpaceX’s flight computers use the typical triple redundancy setup, with three independent dual-core processors running the exact same calculations and a different Linux instance on each of its cores, and the result being compared afterwards. If any result doesn’t match that of the others, it is dropped. This approach also allows SpaceX to use fairly off-the-shelf (OTS) x86 computing hardware, with the flight software written in C++.

NASA’s efforts are similar, with Ingenuity in particular heavily using OTS parts, along with NASA’s open source, C++-based F’ (F Prime) framework. The chopper also uses some version of the Linux kernel on a Snapdragon 801 SoC, which as we have seen over the past 72 flights works very well.

Which is not to say using Linux is a no-brainer when it comes to use in avionics and similar critical applications. There is a lot of code in the monolithic Linux kernel that requires you to customize it for a specific task, especially if it’s on a resource-constrained platform. Linux isn’t particularly good at hard real-time applications either, but using it does provide access to a wealth of software and documentation — something that needs to be weighed up against the project’s needs.

A colorful diagram representing the inner structure of the Linux kernel.

Find That Obscure Function With This Interactive Map Of The Linux Kernel

September 14, 2023 by 12 Comments

Linux has become one of the largest operating systems on the servers that run large websites, and hopefully, one day, it will be big in the desktop market too. Some of you may know how Linux as an operating system is structured, but have you ever wondered how the kernel itself is structured? Maybe you’ll find this colorful interactive map of the Linux kernel by [Costa Shulyupin] useful.

The interactive map depicts the major levels of abstraction and functionalities, dotted with over 400 prominent functions from the Linux kernel, which are also links to a cross-reference site so you can see all the definitions and usages. It divides the kernel into 7 rows and 7 columns containing domains with well-known terms like security and debugging, but also more obscure things like block devices and address families. These are also links, this time to the definition of the term in question. Finally, there are arrows flying everywhere, to show the relationships between all the many functions in the kernel.
Continue reading “Find That Obscure Function With This Interactive Map Of The Linux Kernel” →

A Power Button For Raspberry Pi, Courtesy Of Device Tree Overlays

April 4, 2022 by 11 Comments

As a standard feature of the Linux kernel, device tree overlays (DTOs) allow for easy enabling and configuration of features and drivers, such as those contained within the standard firmware of a Raspberry Pi system. Using these DTOs it’s trivial to set up features like as a soft power-off button, triggering an external power supply and enable drivers for everything from an external real-time clock (RTC) to various displays, sensors and audio devices, all without modifying the operating system or using custom scripts.

It’s also possible to add your own DTOs to create a custom overlay that combines multiple DTO commands into a single one, or create a custom device tree binary (DTB) for the target hardware. Essentially this DTB is loaded by the Linux kernel on boot to let it know which devices are connected and their configuration settings, very similar to what the BIOS component with x86-based architectures handles automatically.

Ultimately, the DTB concept and the use of overlays allow for easy configuration of such optional devices and GPIO pin settings, especially when made configurable through a simple text file as on the Raspberry Pi SBC platform.

Continue reading “A Power Button For Raspberry Pi, Courtesy Of Device Tree Overlays” →

This Week In Security: Insecure Chargers, Request Forgeries, And Kernel Security

August 6, 2021 by 13 Comments

The folks at Pen Test Partners decided to take a look at electric vehicle chargers. Many of these chargers are WiFi-connected, and let you check your vehicle’s charge state via the cloud. How well are they secured? Predictably, not as well as they could be.

The worst of the devices tested, Project EV, didn’t actually have any user authentication on the server side API. Knowing the serial number was enough to access the account and control the device. The serial numbers are predictable, so taking over every Project EV charger connected to the internet would have been trivial. On top of that, arbitrary firmware could be loaded remotely onto the hardware was possible, representing a real potential problem.

The EVBox platform had a different problem, where an authenticated user could simply specify a security role. The tenantadmin role was of particular interest here, working as a superadmin that could see and manage multiple accounts. This flaw was patched within an impressive 24 hours. The EVBox charger, as well as several other devices they checked had fundamental security weaknesses due to their use of Raspberry Pi hardware in the product. Edit: The EVBox was *not* one of the devices using the Pi in the end product.

Wait, What About the Raspberry Pi?

Apparently the opinion that a Raspberry Pi didn’t belong in IoT hardware caught Pen Test Partners some flack, because a few days later they published a follow-up post explaining their rationale. To put it simply, the Pi can’t do secure boot, and it can’t do encrypted storage. Several of the flaws they found in the chargers mentioned above were discovered because the device filesystems were wide open for inspection. A processor that can handle device encryption, ideally better than the TPM and Windows Bitlocker combination we covered last week, gives some real security against such an attack. Continue reading “This Week In Security: Insecure Chargers, Request Forgeries, And Kernel Security” →