Remotely Unlocking An Encrypted Hard Disk

Can you remotely unlock an encrypted hard disk? [Jyn] needed to unlock their home server after it rebooted even if they weren’t home. Normally, they used Tailscale to remote in, but you can’t use tailscale to connect to the machine before the hard drive decrypts, right? Well, you can, sort of, and [Jyn] explains how.

The entertaining post points out something you probably knew, but never thought much about. When your Linux box boots, it starts a very tiny compressed Linux in RAM. On [Jyn’s] machine using Arch, this is the initramfs.

That’s not news, but because it is an actual limited Linux system (including systemd), you can add tools to it. In this case, adding dropbear (an ssh server) and Tailscale to the limited boot-time Linux.

Continue reading “Remotely Unlocking An Encrypted Hard Disk”

Linux Hotplug Events Explained

There was a time when Linux was much simpler. You’d load a driver, it would find your device at boot up, or it wouldn’t. That was it. Now, though, people plug and unplug USB devices all the time and expect the system to react appropriately. [Arcanenibble] explains all “the gory details” about what really happens when you plug or unplug a device.

You might think, “Oh, libusb handles that.” But, of course, it doesn’t do the actual work. In fact, there are two possible backends: netlink or udev. However, the libusb developers strongly recommend udev. Turns out, udev also depends on netlink underneath, so if you use udev, you are sort of using netlink anyway.

If netlink sounds familiar, it is a generic BSD-socket-like API the kernel can use to send notifications to userspace. The post shows example code for listening to kernel event messages via netlink, just like udev does.

When udev sees a device add message from netlink, it resends a related udev message using… netlink! Turns out, netlink can send messages between two userspace programs, not just between the kernel and userspace. That means that the code to read udev events isn’t much different from the netlink example.

The next hoop is the udev event format. It uses a version number, but it seems stable at version 0xfeedcafe. Part of the structure contains a hash code that allows a bloom filter to quickly weed out uninteresting events, at least most of the time.

The post documents much of the obscure inner workings of USB hotplug events. However, there are some security nuances that aren’t clear. If you can explain them, we bet [Arcanenibble] would like to hear from you.

If you like digging into the Linux kernel and its friends, you might want to try creating kernel modules. If you get overwhelmed trying to read the kernel source, maybe go back a few versions.

Linux Fu: The USB WiFi Dongle Exercise

The TX50U isn’t very Linux-friendly

If you’ve used Linux for a long time, you know that we are spoiled these days. Getting a new piece of hardware back in the day was often a horrible affair, requiring custom kernels and lots of work. Today, it should be easier. The default drivers on most distros cover a lot of ground, kernel modules make adding drivers easier, and dkms can automate the building of modules for specific kernels, even if it isn’t perfect.

So ordering a cheap WiFi dongle to improve your old laptop’s network connection should be easy, right? Obviously, the answer is no or this would be a very short post.

Plug and Pray

The USB dongle in question is a newish TP-Link Archer TX50U. It is probably perfectly serviceable for a Windows computer, and I got a “deal” on it. Plugging it in caused it to show up in the list of USB devices, but no driver attached to it, nor were any lights on the device blinking. Bad sign. Pro tip: lsusb -t will show you what drivers are attached to which devices. If you see a device with no driver, you know you have a problem. Use -tv if you want a little more detail.

The lsusb output shows the devices as a Realtek, so that tells you a little about the chipset inside. Unfortunately, it doesn’t tell you exactly which chip is in use.

Continue reading “Linux Fu: The USB WiFi Dongle Exercise”

Full-Blown Cross-Assembler…in A Bash Script

Have you ever dreamed of making a bash script that assembles Intel 8080 machine code? [Chris Smith] did exactly that when he created xa.sh, a cross-assembler written entirely in Bourne shell script.

Assembly language (like the above) goes in, a binary comes out.

The script exists in part as a celebration of the power inherent in a standard Unix shell with quite ordinary POSIX-compliant command line tools like awk, sed, and printf. But [Chris] admits that mostly he found the whole project amusing.

It’s designed in a way that adding support for 6502 and 6809 machine code would be easy, assuming 8080 support isn’t already funny enough on its own.

It’s not particularly efficient and it’s got some quirks, most of which involve syntax handling (hexadecimal notation should stick to 0 or 0x prefixes instead of $ to avoid shell misinterpretations) but it works.

Want to give it a try? It’s a shell script, so pull a copy and and just make it executable. As long as the usual command-line tools exist (meaning your system is from sometime in the last thirty-odd years), it should run just fine as-is.

An ambitious bash script like this one recalls how our own Al Williams shared ways to make better bash scripts by treating it just a bit more like the full-blown programming language it qualifies as.

KDE’s Default Login Manager Binds Itself To Systemd

The KDE desktop’s new login manager (PLM) in the upcoming Plasma 6.6 will re. This has especially the FreeBSD community upset, but will also affect Linux distros that do not use systemd. The focus of the KDE team is clear, as stated in the referenced Reddit thread, where a KDE developer replies that the goal is to rely on systemd for more tasks in the future.

Systemd skeptics fear this means that PLM is just the first step.  To them, it seems that OSes that do not use systemd are ‘niche’ and not worth supporting, with said niche Linux distros that would be cut out including everything from Gentoo to Alpine Linux and Slackware.

It also raises the question of in how far this is related to the push towards a distroless and similarly more integrated, singular version of Linux as an operating system. Although there are still many other DEs that will happily run for the foreseeable future on your flavor of GNU/Linux or BSD – regardless of whether you’re more about about a System V or OpenRC init-style environment – this might be one of the most controversial divides since systemd was first introduced.

(Editor’s note: [Paul Brown] from KDE contacted us to reinforce that KDE will continue to support the BSDs and smaller Linux flavors, but they’ll just have to use a different login manager.)

Top image: KDE Plasma 6.4.5. (Credit: Michio.kawaii, Wikimedia)

CPU Scheduler Divines The Will Of The Heavens

Horoscopes are a great way to pass a boring lunchbreak, and an excellent excuse for ending a ill-considered relationship. They’re also a hilarious way to handle CPU scheduling under Linux, thanks to the work of [Lucas Zampieri].

The project is called scx_horoscope, and it’s a sched_Ext scheduler that makes its CPU scheduling choices based on what the heavens are doing in real time. Different tasks are handled based on different astronomical objects. For example, the Sun represents life force, and thus grants boons to key system processes. The Moon, an emotive influence, rules over interactive processes like shells and terminals. Mercury, as the god of communication, handles network and IO tasks, and so it goes from there. It’s not just a surface level thing, either—[Lucas] has implemented the influences of the elements of fire, air, earth, and water, and there are negative timeslice penalties on associated tasks when a given planet lands in retrograde.

You can argue whether or not the broader motions of the heavens have any impact on our lives based on the time and circumstances of our birth. But you can’t argue that scx_horoscope really will influence how your computer runs based on the dance of the planets in the sky. Mostly, though, we concern ourselves with astronomy rather than astrology around these parts!

[Thanks to Benjamin for the tip!]

Swissbit 2GB PC2-5300U-555

Surviving The RAM Price Squeeze With Linux In-Kernel Memory Compression

You’ve probably heard — we’re currently experiencing very high RAM prices due mostly to increased demand from AI data centers.

RAM prices gone up four times

If you’ve been priced out of new RAM you are going to want to get as much value out of the RAM you already have as possible, and that’s where today’s hack comes in: if you’re on a Debian system read about ZRam for how to install and configure zram-tools to enable and manage the Linux kernel facilities that enable compressed RAM by integrating with the swap-enabled virtual memory system. We’ve seen it done with the Raspberry Pi, and the concept is the same.

Ubuntu users should check out systemd-zram-generator instead, and be aware that zram might already be installed and configured by default on your Ubuntu Desktop system.

If you’re interested in the history of in-kernel memory compression LWN.net has an old article covering the technology as it was gestating back in 2013: In-kernel Memory Compression. For those trying to get a grip on what has happened with RAM prices in recent history, a good place to track memory prices is memory.net and if you swing by you can see that a lot of RAM has gone up as much as four times in the last three or four months.

If you have any tips or hacks for memory compression on other platforms we would love to hear from you in the comments section!