Turning The PS4 Into A Useful Linux Machine

February 10, 2022 by Bryan Cockfield 22 Comments

When the PlayStation 3 first launched, one of its most lauded features was its ability to officially run full Linux distributions. This was of course famously and permanently borked by Sony with a software update after a few years, presumably since the console was priced too low to make a profit and Sony didn’t want to indirectly fund server farms made out of relatively inexpensive hardware. Of course a decision like this to keep Linux off a computer system is only going to embolden Linux users to put it on those same systems, and in that same vein this project turns a more modern Playstation 4 into a Kubernetes cluster with the help of the infamous OS.

The Playstation 4’s hardware is a little dated by modern desktop standards but it is still quite capable as a general-purpose computer provided you know the unofficial, unsupported methods of installing Psxitarch Linux on one. This is a distribution based on Arch and built specifically for the PS4, but to get it to run the docker images that [Zhekun Hu] wanted to use some tinkering with the kernel needed to be done. With some help from the Gentoo community a custom kernel was eventually compiled, and after spending some time in what [Zhekun Hu] describes as “Linux Kernel Options Hell” eventually a working configuration was found.

The current cluster is composed of two PS4s running this custom software and runs a number of services including Nginx, Calico, Prometheus, and Grafana. For those with unused PlayStation 4s laying around this might be an option to put them back to work, but it should also be a cautionary tale about the hassles of configuring a Linux kernel from scratch. It can still be done on almost any machine, though, as we saw recently using a 386 and a floppy disk.

Yo Dawg, We Heard You Like Retrocomputers

August 14, 2021 by Bryan Cockfield 20 Comments

The idea of having software translation programs around to do things like emulate a Super Nintendo on your $3000 gaming computer or, more practically, run x86 software on a new M1 Mac, seems pretty modern since it is so prevalent in the computer world today. The idea of using software like this is in fact much older and easily traces back into the 80s during the era of Commodore and Atari personal computers. Their hardware was actually not too dissimilar, and with a little bit of patience and know-how it’s possible to compile the Commodore 64 kernel on an Atari, with some limitations.

This project comes to us from [unbibium] and was inspired by a recent video he saw where the original Apple computer was emulated on Commodore 64. He took it in a different direction for this build though. The first step was to reformat the C64 code so it would compile on the Atari, which was largely accomplished with a Python script and some manual tweaking. From there he started working on making sure the ROMs would actually run. The memory setups of these two machines are remarkably similar which made this slightly easier, but he needed a few workarounds for a few speed bumps. Finally the cursor and HMIs were configured, and once a few other things were straightened out he has a working system running C64 software on an 8-bit Atari.

Unsurprisingly, there are a few things that aren’t working. There’s no IO besides the keyboard and mouse, and saving and loading programs is not yet possible. However, [unbibium] has made all of his code available on his GitHub page if anyone wants to expand on his work and may also improve upon this project in future builds. If you’re looking for a much easier point-of-entry for emulating Commodore software in the modern era, though, there is a project available to run a C64 from a Raspberry Pi.

Thanks to [Cprossu] for the tip!

Why Blobs Are Important, And Why You Should Care

January 29, 2021 by Jenny List 53 Comments

We are extraordinarily fortunate to live at a time in which hardware with astounding capabilities can be had for only a few dollars. Systems that would once have taken an expensive pile of chips and discretes along with months of development time to assemble are now integrated onto commodity silicon. Whether it is a Linux-capable system-on-chip or a microcontroller, such peripherals as WiFi, GPUs, Bluetooth, or USB stacks now come as part of the chip, just another software library rather than a ton of extra hardware.

Beware The Blob!

An ESP-01 module — The cheapest of chips still comes with a blob.

If there is a price to be paid for this convenience, it comes in the form of the blob. A piece of pre-compiled binary software that does the hard work of talking to the hardware and which presents a unified API to the software. Whether you’re talking to the ESP32 WiFi through an Arduino library or booting a Raspberry Pi with a Linux distribution, while your code may be available or even maybe open source, the blob it relies upon to work is closed source and proprietary. This presents a challenge not only to Software Libre enthusiasts in search of a truly open source computer, but also to the rest of us because we are left reliant upon the willingness of the hardware manufacturer to update and patch their blobs.

An open-source advocate would say that the solution is easy, the manufacturers should simply make their blobs open-source. And it’s true, were all blobs open-source then the Software Libre crowd would be happy and their open-source nature would ease the generation of those updates and patches. So why don’t manufacturers release their blobs as open-source? In some cases that may well be due to a closed-source mindset of never releasing anything to the world to protect company intellectual property, but to leave it at that is not a full answer. To fully understand why that is the case it’s worth looking at how our multifunctional chips are made.

Continue reading “Why Blobs Are Important, And Why You Should Care” →

Hackaday Links: August 2, 2020

August 2, 2020 by Dan Maloney 14 Comments

If you somehow manage to mentally separate yourself from the human tragedy of the COVID-19 pandemic, it really has provided a fascinating glimpse into how our planet operates, and how much impact seven billion people have on it. Latest among these revelations is that the shutdowns had a salubrious effect in at least one unexpected area: solar power. Researchers found that after the Indian government instituted mandatory lockdowns in March, output from solar power installations in Delhi increased by more than eight percent. The cause: the much-diminished smog, which let more sunlight reach solar panels. We’ve seen similar shutdown-related Earth-impact stories, from decreased anthropogenic seismicity to actually being able to see Los Angeles, and find them all delightfully revealing.

Remember Google Glass? It’s hard to forget, what with all the hype leading up to launch and the bitter disappointment of realizing that actually wearing the device wouldn’t go over well in, say, a locker room. That said, the idea of smart glasses had promise, and several startups tried to make a go of combining functionality with less out-there styling that wouldn’t instantly be seen as probable cause for being a creep. One such outfit was North, who made the more-or-less regular looking (if a bit hipsterish) Focals smart glasses. But alas, North was bought out by Google back in June, and as with so many things Google acquires, Focals smart glasses are being turned off. Anyone who bought the $600 specs will reportedly get their money back, but the features of the smart glasses will no longer function. Except, you know, you’ll still be able to look through them.

It looks like someone has finally come up with a pretty good use case for the adorably terrifying robot mini-dogs from Boston Dynamics. Ford Motors has put two of the yellow robots to work in their sprawling Van Dyke Transmission Plant in Michigan. Dubbed Fluffy and Spot (aww), the dogs wander around the plant with a suite of cameras and sensors, digitally mapping the space to prepare for possible future modifications and expansions. The robots can cover a lot of ground during the two hours that their batteries last, and are even said to be able to hitch a ride on the backs of other robots when they’re tuckered out. Scanning projects like these can keep highly trained — and expensive — engineers busy for weeks, so the investment in robots makes sense. And we’re sure there’s totally no way that Ford is using the disarmingly cute robo-pets to keep track of its employees.

We all know that the Linux kernel has some interesting cruft in it, but did you know that it can actually alert you to the fact that your printer is aflame? We didn’t either until Editor-in-Chief Mike Szczys shared this reddit post that details the kernel function lp_check_status and how it assumes the worst if it detects the printer is online but also in “check mode.” The Wikipedia entry on the “lp0 on fire” error message has some interesting history that details how it’s not as implausible as it might seem for a printer, especially one in the early 1970s, to burst into flames under the right conditions. A toner fuser bar running amok on a modern laser printer is one thing, but imagine a printer with a fusing oven running out of control.

And finally, because 2020 is apparently the gift that can’t stop giving, at least in the weirdness department, the US Department of Defense let it slip that the office charged with investigating unidentified aerial phenomena is not quite as disbanded as they once said it was. Reported to have been defunded in 2017, the Advanced Aerospace Threat Identification Program actually appears to live on, as the Unidentified Aerial Phenomena Task Force, operating out of the Office of Naval Intelligence. Their purpose is ostensibly to study things like the Navy videos of high-speed craft out-maneuvering fighter jets, but there are whispers from former members of the task force that “objects of undetermined origin have crashed on earth with materials retrieved for study.” All this could just be a strategic misdirection, of course, but given everything else that has happened this year, we’re prepared to believe just about anything.

Bringing PalmOS Back To Life

May 21, 2019 by Bryan Cockfield 33 Comments

Ten years is almost ancient history in the computing world. Going back twelve years is almost unheard of, but that’s about the time that Palm released the last version of their famed PalmOS, an operating system for small, handheld devices that predated Apple’s first smartphone by yet another ten years. As with all pieces of good software there remain devotees, but with something that hasn’t been updated in a decade there’s a lot of work to be done. [Dmitry.GR] set about doing that work, and making a workable Palm device for the modern times.

He goes into incredible detail on this build, but there are some broad takeaways from the project. First, Palm never really released all of the tools that developers would need to build software easily, including documentation of the API system. Since a new device is being constructed, a lot of this needs to be sorted out. Even a kernel was built from scratch for this project, since using a prebuilt one such as Linux was not possible. There were many other pieces of software needed in order to get a working operating system together running on an ARM processor, which he calls rePalm.

There are many other facets of this project that we aren’t able to get into in this limited space, but if you’re at all interested in operating systems or if you fondly remember the pre-smartphone era devices such the various Palm PDAs that were available in the late ’90s and early ’00s, it’s worth taking a look at this one. And if you’d like to see [Dmitry.GR]’s expertise with ARM, he is well-versed.

Thanks to [furre] for the tip!

Apple Kernel Code Vulnerability Affected All Devices

November 1, 2018 by Jonathan Bennett 81 Comments

Another day, another vulnerability. Discovered by [Kevin Backhouse], CVE-2018-4407 is a particularly serious problem because it is present all throughout Apple’s product line, from the Macbook to the Apple Watch. The flaw is in the XNU kernel shared by all of these products.

This is a buffer overflow issue in the error handling for network packets. The kernel is expecting a fixed length of those packets but doesn’t check to prevent writing past the end of the buffer. The fact Apple’s XNU kernel powers all their products is remarkable, but issues like this are a reminder of the potential downside to that approach. Thanks to responsible disclosure, a patch was pushed out in September.

Anatomy of a Buffer Overflow

Buffer overflows aren’t new, but a reminder on what exactly is going on might be in order. In low level languages like C, the software designer is responsible for managing computer memory manually. They allocate memory, tagging a certain number of bytes for a given use. A buffer overflow is when the program writes more bytes into the memory location than are allocated, writing past the intended limit into parts of memory that are likely being used for a different purpose. In short, this overflow is written into memory that can contain other data or even executable code.

With a buffer overflow vulnerability, an attacker can write whatever code they wish to that out-of-bounds memory space, then manipulate the program to jump into that newly written code. This is referred to as arbitrary code execution. [Computerphile] has a great walk-through on buffer overflows and how they lead to code execution.

This Overflow Vulnerabilty Strikes Apple’s XNU Kernel

[Kevin] took the time to explain the issue he found in further depth. The vulnerability stems from the kernel code making an assumption about incoming packets. ICMP error messages are sent automatically in response to various network events. We’re probably most familiar with the “connection refused’ message, indicating a port closed by the firewall. These ICMP packets include the IP header of the packet that triggered the error. The XNU implementation of this process makes the assumption that the incoming packet will always have a header of the correct length, and copies that header into a buffer without first checking the length. A specially crafted packet can have a longer header, and this is the data that overflows the buffer.

Because of the role ICMP plays in communicating network status, a closed firewall isn’t enough to mitigate the attack. Even when sent to a closed port, the vulnerability can still trigger. Aside from updating to a patched OS release, the only mitigation is to run the macOS firewall in what it calls “stealth mode”. This mode doesn’t respond to pings, and more importantly, silently drops packets rather than sending ICMP error responses. This mitigation isn’t possible for watchOS and iOS devices.

The good news about the vulnerability is that a packet, malformed in this way, has little chance of being passed through a router at all. An attacker must be on the same physical network in order to send the malicious packet. The most likely attack vector, then, is the public WiFi at the local coffee shop.

Come back after the break for a demonstration of this attack in action.

Continue reading “Apple Kernel Code Vulnerability Affected All Devices” →

Linux, Without The Git Factor

September 17, 2018 by Jenny List 82 Comments

Linux started as a student project in the 1990s, the creation of Linus Torvalds. He has attained celebrity status while steering his creation through the decades, but along the way he has also attracted a different reputation within the Linux and software community. He is famous for his outbursts and rants, some of which become rather personal, and it is not difficult at all to find kernel developers or would-be kernel developers who have turned their backs on the project as a result.

It’s very refreshing indeed then to read an update from [Linus] as part of his regular communications, in which he admits that he has an issue, and says that he is taking the time to seek help for it. There is an accompanying update to the kernel maintenance code of conduct, which suggests that this is likely to mark a sea-change in that environment, as well as we hope salvage that aspect of [Linus]’ reputation.

“My flippant attacks in emails have been both unprofessional and uncalled for. Especially at times when I made it personal. In my quest for a better patch, this made sense to me. I know now this was not OK and I am truly sorry.”

The Hackaday community has a much greater than average proportion of Linux users among its readership. Even those readers who use a desktop OS with BSD, Windows, or other kernels will almost certainly have a Linux kernel somewhere, whether it’s in their phone, their set-top-box, their children’s toys, or even their domestic appliances. And of course a large swath of the Internet runs on Linux. It is in the best interest of us all that we continually attract and retain brilliant people to contribute to the effort put into developing and maintaining the Linux kernel.

Without wishing to lionise [Linus] above the many others whose work has also contributed to Linux and its success, his contribution to our community has been beyond measure and it has been uncomfortable to see his other side. It’s a step in the right direction to apologize for personal attacks and behavior that drives a wedge into the kernel developer community, and seek to change that behavior. We’d urge others to follow his example, we’re sure every grouping has at times had its personality problems, and it’s never too late to enact some repairs.

While Linus steps away to work on his self improvement, veteran kernel developer Greg Kroah-Hartman will take the reigns among the kernel maintainers.