Linux And C In The Browser

There was a time when trying to learn to write low-level driver or kernel code was hard. You really needed two machines: one to work with, and one to screw up over and over again until you got it right. These days you can just spin up a virtual machine and roll it back every time you totally screw up. Much easier! We don’t think it is all that practical, but [nsommer] has an interesting post about loading up a C compiler and compiling Linux for a virtual machine. What’s different? Oh, the virtual machine is in your browser.

The v86 CPU emulator runs in the browser and looks like a Pentium III computer with the usual hardware. You might think it is slow and it certainly isn’t going to be fast as a rocket, but it does translate machine code into WebAssembly, so performance isn’t as bad as you might think.

The post goes into detail about how to build and create a simple machine web page that hosts v86. Once you cross-compile the kernel you can boot the machine up virtually. The other interesting part is the addition of tcc which is a pretty capable C compiler and much smaller and faster than the very traditional gcc.

The tcc build is tricky because the normal build process compiles the compiler and then uses the same compiler to build the default libraries. When cross-compiling, this doesn’t work well because the library you want for the host compile is different from the library you want to target for the second pass. You’ll see how to work around that in the post. The post continues to show how to do remote debugging and even gets QEMU into the mix. Debugging inside v86 doesn’t seem to work so far. There are more posts on this topic promised.

Honestly, this is one of those things like teaching a chicken to play checkers. It can be done, there’s little practical value, but it is still something to see. On the other hand, if you spend the weekend working through this, your next Linux porting project ought to seem easy by comparison.

Amazing what you can pull off with WebAssembly. If you need a quick introduction, check this one out from [Ben James].

Lotus 123 For Linux Is Like A Digital Treasure Hunt

Ever hear of Lotus 123? It is an old spreadsheet program that dominated the early PC market, taking the crown from incumbent Visicalc. [Tavis Ormandy] has managed to get the old software running natively under Linux — quite a feat for software that is around 40 years old and was meant for a different operating system. You can see the results in glorious green text on a black screen in the video below.

If you are a recent convert to Linux, you might not remember what a pain it was “in the old days” to install software. But in this case, it is even worse since the software isn’t even for Linux. The whole adventure started with [Tavis] wanting to find the API kit used to add plugins to Lotus. In theory, you could use it to add modern features to the venerable spreadsheet program.

The $395 software development kit wasn’t very common and there was also a Unix version of Lotus 123, but no one seemed to have a copy of that. [Tavis] eventually found someone who ran a circa-1990 BBS and had the data on tape. Turned out there was a hot copy of the SDK that he was able to use. But he noticed something else in the BBS’s list of files: the long-lost Unix version of Lotus!

An investigation found the installer used TD0 files which took some research. Luckily, a utility exists that can convert these to raw disk images. Inside was a very large object file. Apparently, in the days without dynamic loading, that object would be linked with plug in modules to install them.

The object file had all of its debugging information intact which shed a lot of light on the program’s internal operations. The old executables used COFF format but it is possible to relink it to an ELF file. Of course, it isn’t just that easy. [Tavis] wrote a small program to remove the old-style Unix system calls so they could be rerouted to Linux system calls. Some calls just pass through, but others need some translation due to differences in things like structure layout, sizes, and alignment.

In the end, it all worked but didn’t have a valid license. However, [Tavis] felt like since he did have a license and the software is abandoned, he was within his rights to crack the license check.

We are well-known abusers of spreadsheets around here. Of course, we aren’t the only ones.

Continue reading Lotus 123 For Linux Is Like A Digital Treasure Hunt”

Things Are Getting Rusty In Kernel Land

There is gathering momentum around the idea of adding Rust to the Linux kernel. Why exactly is that a big deal, and what does this mean for the rest of us? The Linux kernel has been just C and assembly for its entire lifetime. A big project like the kernel has a great deal of shared tooling around making its languages work, so adding another one is quite an undertaking. There’s also the project culture developed around the language choice. So why exactly are the grey-beards of kernel development even entertaining the idea of adding Rust? To answer in a single line, it’s because C was designed in 1971, to run on the minicomputers at Bell Labs. If you want to shoot yourself in the foot, C will hand you the loaded firearm.

On the other hand, if you want to write a kernel, C is a great language for doing low-level coding. Direct memory access? Yep. Inline assembly? Sure. Runs directly on the metal, with no garbage collection or virtual machines in the way? Absolutely. But all the things that make C great for kernel programming also make C dangerous for kernel programming.

Now I hear your collective keyboards clacking in consternation: “It’s possible to write safe C code!” Yes, yes it is possible. It’s just very easy to mess up, and when you mess up in a kernel, you have security vulnerabilities. There’s also some things that are objectively terrible about C, like undefined behavior. C compilers do their best to do the right thing with cursed code like i++ + i++; or a[i] = i++;. But that’s almost certainly not going to do what you want it to, and even worse, it may sometimes do the right thing.

Rust seems to be gaining popularity. There are some ambitious projects out there, like rewriting coreutils in Rust. Many other standard applications are getting a Rust rewrite. It’s fairly inevitable that the collection of Rust developers started to ask, could we invade the kernel next? This was pitched for a Linux Plumbers Conference, and the mailing list response was cautiously optimistic. If Rust could be added without breaking things, and without losing the very things that makes Rust useful, then yes it would be interesting. Continue reading “Things Are Getting Rusty In Kernel Land”

Gaming Mouse Becomes Digital Camera

Ever since the world decided to transition from mechanical ball mice to optical mice, we have been blessed with computer pointing devices that don’t need regular cleaning and have much better performance than their ancestors. They do this by using what is essentially a tiny digital camera to monitor changes in motion. As we’ve seen before, it is possible to convert this mechanism into an actual camera, but until now we haven’t seen something like this on a high-performance mouse designed for FPS gaming.

For this project [Ankit] is disassembling the Logitech G402, a popular gaming mouse with up to 4000 dpi. Normally this is processed internally in the mouse to translate movement into cursor motion, but this mouse conveniently has a familiar STM32 processor with an SPI interface already broken out on the PCB that could be quickly connected to in order to gather image data. [Ankit] created a custom USB vendor-specific endpoint and wrote a Linux kernel module to parse the data into a custom GUI program that can display the image captured by the mouse sensor on-screen.

It’s probably best to not attempt this project if you plan to re-use the mouse, as the custom firmware appears to render the mouse useless as an actual mouse. But as a proof-of-concept project this high-performance mouse does work fairly well as a camera, albeit with a very low resolution by modern digital camera standards. It is much improved on older mouse-camera builds we’ve seen, though, thanks to the high performance sensors in gaming mice.

Linux Fu: The Infinite Serial Port

Ok, the title is a bit misleading. Like most things in life, it really isn’t infinite. But I’m going to show you how you can use a very interesting Linux feature to turn one serial port from a microcontroller into a bunch of virtual ports. In theory, you could create over 200 ports, but the reality is you will probably want to stick with fewer.

The feature in question is what’s known as pseudoterminal or sometimes a pty or pts. These special files were made to feed data to programs that expect to accept data from a terminal. The files provide two faces. To the client, it looks like any other terminal device. To the creator, though, it is just another file. What you write to that file goes to the fake terminal and you can read anything that is sent from the program connected to the terminal. You use these all the time, probably, without realizing it since running a shell under X Windows, for example, doesn’t attach to a real terminal, after all.

You could, of course, do the same trick with a composite USB device, assuming you have one. Also assuming you can find a working driver and get it working. However, many microcontrollers have a serial port — even one with a USB converter built-in — but fewer have full-blown USB hardware. Even the ones that do are often at odds with strange drivers on the PC side. Serial ports work and work well even on the simplest microcontrollers.

The Plan

The plan is simple enough. A Linux program listens to a real serial port and watches for special character sequences in the data stream. Those sequences will allow you to switch data so that the data stream will go to a particular terminal. Data coming back from the terminals will go to the real serial port after sending a sequence that identifies its source.

Continue reading “Linux Fu: The Infinite Serial Port”

This Week In Security: Android And Linux, VirusTotal, More Psychic Signatures

To start our week of vulnerabilities in everything, there’s a potentially big vulnerability in Android handsets, but it’s Apple’s fault. OK, maybe that’s a little harsh — Apple released the code to their Apple Lossless Audio Codec (ALAC) back in 2011 under the Apache License. This code was picked up and shipped as part of the driver stack for multiple devices by various vendors, including Qualcomm and MediaTek. The problem is that the Apple code was terrible, one researcher calling it a “walking colander” of security problems.

Apple has fixed their code internally over the years, but never pushed those updates to the public code-base. It’s a fire-and-forget source release, and that can cause problems like this. The fact that ALAC was released under a permissive license may contribute to the problem. Someone (in addition to Apple) likely found and fixed the security problems, but the permissive license doesn’t require sharing those fixes with a broader community. It’s worth pondering whether a Copyleft license like the GPL would have gotten a fix distributed years ago.

Regardless, CVE-2021-0674 and CVE-2021-0675 were fixed in both Qualcomm and MediaTek’s December 2021 security updates. These vulnerabilities are triggered by malicious audio files, and can result in RCE. An app could use this trick to escape the sandbox and escalate privileges. This sort of flaw has been used by actors like the NSO group to compromise devices via messaging apps. Continue reading “This Week In Security: Android And Linux, VirusTotal, More Psychic Signatures”

A Real GPU On The Raspberry Pi — Barely.

[Jeff Geerling] saw the Raspberry Pi Compute Module 4 and its exposed PCI-Express 1x connection, and just naturally wondered whether he could plug a GPU into that slot and get it to work. It didn’t. There were a few reasons why, such as the limited Base Address Register space, and drivers that just weren’t written for ARM hardware. A bit of help from the Raspberry Pi software engineers and other Linux kernel hackers and those issues were fixed, albeit with a big hurdle in the CPU. The Broadcom chip in the Pi 4, the BCM2711, has a broken PCIe implementation.

There has finally been a breakthrough — Thanks to the dedicated community that has sprung up around this topic, a set of kernel patches manage to work around the hardware issues. It’s now possible to run a Radeon HD 5000/6000/7000 card on the Raspberry Pi 4 Compute Module. There are still glitches, and the Kernel patches to make this work will likely never land upstream. That said, It’s possible to run a desktop environment on the Radeon GPU on a Pi, and even a few simple benchmarks. The results… aren’t particularly inspiring, but that wasn’t really ever the point. You may be asking what real-world use is for a full-size GPU on the Pi. Sure, maybe crypto-mining or emulation, or being able to run more monitors for digital signage. More than that, it might help ensure the next Pi has a working PCIe implementation. But like many things we cover here, the real reason is that it’s a challenge that a group of enthusiasts couldn’t leave alone.

Continue reading “A Real GPU On The Raspberry Pi — Barely.”