Your Computer Memory Is A Lie

When you first learn to program, memory seems pretty straightforward. You have a bunch of bytes, each with an address. If you want to read or write something, you specify the address, and the computer goes to that place and does your bidding. Sure, some addresses might be reserved for hardware or the operating system, but the general idea is simple: memory is a big array of bytes.

Just like we pretend that a wire is a perfect conductor, the big array of memory model used to be a slight twisting of the truth. On a modern computer, however, it is almost entirely a lie. The address you use probably isn’t a physical address. The data you read might not come from RAM at all. Even if it does, it might be sitting in one of several caches. And if you follow the rabbit hole far enough, you discover that your SSD is arguably just another level in the memory hierarchy.

The Need For Speed

The fundamental problem is that processors have gotten much faster than memory. A modern processor can execute several instructions per clock cycle, but accessing ordinary DRAM can take hundreds of cycles. If the processor had to wait for RAM every time it needed data, much of that impressive computing power would go to waste.

The solution is caching. Keep copies of frequently used data in smaller, faster memories closer to the processor. Most modern desktop processors have at least three levels of cache. The L1 cache is tiny but extremely fast, and often split between instructions and data. L2 is larger and somewhat slower, while L3 is even larger and usually slower as well.

Continue reading “Your Computer Memory Is A Lie” →

The Weirdest Video Games Were Hacks

We were looking into the marvelous recent project by [Throaty Mumbo] to recreate and reimagine the forgotten world of VHS-tape-based video games. Wait, what? Yes, back in the day, when computer graphics were more primitive, there were attempts to mix the gameplay of video games with the graphics from a video cassette. Take the Action Max system. It worked with a light-gun that pointed at the screen while the video played, and you tried to shoot at things as they flew by. Think Duck Hunt, but in glorious VHS video quality with cheesy acting, and the same gameplay loop every time, because it’s on the tape.

The unreleased Control-Vision VHS gaming system, co-developed with none other than Steve Wozniak, took the idea a little further and ran simultaneous sub-videos, and your actions would choose which of the sub-tracks would play at any given time. This let them do things like switch between videos depending on whether you caught the bad guys or missed them entirely, for instance.

These games came in the late 1980s, though, and they were all derivatives of the seminal Dragon’s Lair, which is probably the least fun video game I’ve ever had the chance to play, but among the most entertaining in a weird way. Instead of a linear VHS tape, Dragon’s Lair, and the later but equally unplayable Space Ace, were based on the then-new video disc technology that could swap between entirely different tracks almost seamlessly.

“Almost” is the key word here, though. Although the animations were absolutely marvelously cartoony, and looked stunning in an arcade up against video games of the time, there was a significant fraction of a second of delay between commanding an action with the joystick and the machine swapping up to the correct track. There were a couple of sections where back-to-back actions were necessary, and the challenge was to work around the game’s exact track-swapping-glitch time. As good as they looked, the gameplay was no fun.

But the game was influential, as evidenced by its VHS-based clones. If you’d like to give it a try, you’ll not be surprised to hear that there’s an emulator for Dragon’s Lair and its spin-off games.

What do all of these have to do with each other? We love how these games took a current technology – in this case video discs or video tapes – and tried to make it do something else: These games were all hacks. If you look at them in that light, maybe you can look past the horrible acting in Night Trap or the frustrating glitches in Dragon’s Lair. (Or maybe not. Give me Robotron: 2084 any day.)

Hackaday Podcast Episode 390: DOOM, Cranium Stuff, And Odd OpenSCAD Opportunities

This week, Elliot Williams and Kristina Panos met a few minutes later than usual, and somehow defeated a buzz together with the power of will before settling into the news, rifling through the Mailbag, and otherwise creating the attached podcast.

So, the news. Amazon, in their infinite wisdom, have chosen to not only remove Alexa’s aux port on future models, but also disable the input on extant ones. Is this really bad news? Maybe just because it seems like taking a choice away for the sake of exerting power over the people.

Anyway. In Hackaday news, the Retrocomputing Contest is currently on fire, and runs through 10AM PDT on Tuesday, October 27th. That means you have about 2.5 weeks left.

Supercon Ten ticket sales are similarly aflame, and per Elliot, it’s about time to release the next round of speakers. So, watch for that.

After digging deep in the Mailbag and eventually just dumping the thing out on the table, we found our brand new Hackaday Podcast Mailbag Audio Bumper! This jingle comes courtesy of [Dakota Winslow], who also advises that there are Easter eggs to be found.

Then, it was on to the hacks, including Elliot’s record-tying number of Quick Hacks, and plenty of in-linkage.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download in lovely MP3.

Continue reading “Hackaday Podcast Episode 390: DOOM, Cranium Stuff, And Odd OpenSCAD Opportunities” →

This Week In Security: New Spectre Attacks, Crushing Quantity Of Linux Vulns, Google Gets Too Much AI, And Hacking Lawnmowers

Just-in-time, or JIT, compilation could be considered a fundamental backbone of modern computing.  JIT compilation turns scripting languages like JavaScript or intermediary binary forms like Web Assembly into native code on the fly, giving web apps, and things that are web apps under the covers like Electron-based tools, near native speed.  A new paper explores leveraging JIT systems to revive Spectre-v2 attacks against processors.

Most modern processors gain performance by using a trick called “speculative execution”.  The processor guesses the likely result of a compare, and begins executing some of the next instructions before the results are actually known.  If the processor guessed right, things continue and there is a speed gain because it can jump ahead, but if the processor guessed wrong, any instructions that were run and any side effects of running them are discarded and execution resumes on the actual path.  In theory, anyhow.

In practice, the Spectre class of attacks targets branch prediction. It was discovered that when the wrong branch was chosen, not all of the results were truly hidden; Patterns of failures in guessing branches can be used to leak behavior processing encryption keys and other activities. The attacks evolved with the research dubbed Spectre-V2, which showed that non-privileged contexts, like non-root users and virtual machines, could poison the instruction prediction and use it to read arbitrary memory.  Fixes to the Linux kernel and other platforms were required to mitigate the worst of the effects.

The paper shows that by using self-modifying code in the JIT, the processor can be tricked into loading cached versions of the instructions.  The fixes to the kernel to prevent Spectre attacks include identifying malicious code patterns that attack the branch prediction, and stopping or changing them:  By causing the CPU to execute the cached copy of instructions instead of the live copy, the attack ignores the fixed instructions entirely and can attack the branch prediction algorithm.

To prove the attack is feasible in the real world, the researchers targeted several JIT compilers, including the SpiderMonkey JavaScript engine used by Firefox, the eBPF JIT found in the Linux kernel, and GraalVM, the JIT used in Python.  They found success with each, demonstrating that the attack is at least plausible.

Research like this is unlikely to be an instant world-melter, and will help find possible mitigations in the future to prevent these sorts of attacks.  Operating systems that support a high-security “lock-down” mode, like macOS and iOS, often disable JIT entirely, out of concern about these sorts of attacks.  There’s probably no need to start disabling JIT on every system, but attacks like these have a tendency to evolve.

Continue reading “This Week In Security: New Spectre Attacks, Crushing Quantity Of Linux Vulns, Google Gets Too Much AI, And Hacking Lawnmowers” →

Lead A Discord Exodus With A Matrix Server

The Internet, and large groups of people in general, tend to have a remarkably short collective memory. Whether it’s the nature of algorithms or the people themselves to always be chasing the next novelty, maintaining long-term engagement for even relatively small changes can be challenging. Distractions abound, and motivation tends to fade over time. This past spring, Discord’s unpopular decision to force age verification resulted in a brief flash-in-the-pan of outrage that dissipated when they promised to delay its roll-out. Rather than backtrack on unpopular policies, they’ve been slowly boiling the frog with incremental changes towards this same goal in the meantime. One of the options to deal with this is to migrate over to something like a Matrix server, which has a number of benefits over Discord including being open-source and self-hostable.

Unlike Discord, a closed platform subject to the whims of a private company, Matrix is a communications protocol and open standard. Its major server and client implementations are open source, so anyone can build tools around it and integrate it with other systems that also use this protocol. This protocol-vs-platform comparison mirrors email, which is another protocol that isn’t locked down by any one company, and which can easily be used to send messages across various providers. The most commonly used server-side software for Matrix is called Synapse and the most prominent general-purpose clients are the various implementations of Element, and my exploration uses these defaults.

Continue reading “Lead A Discord Exodus With A Matrix Server” →

ESP32 As Your Raspberry Pi’s Linux Wireless Co-processor

A laptop with no wireless connectivity feels like a rarity – but when you shop for powerful Linux single-board computers (SBCs), it is pretty common to see one skimp on WiFi. At the same time, current wireless cards can leave much to be desired. A mess of proprietary firmware, ephemeral or even binary blob drivers, weird glitches never resolved, and sometimes entirely source-less blobs with an expiration date. Maybe the SBC doesn’t have a free USB port for a plug-and-play WiFi chip, or you don’t want to design for an obscure hard-to-source castellated module.

What if I told you there’s a unique solution to the problem, as long as the SBC has an SDIO or SPI to spare? There’s a wireless card we can all try to get behind, and it’s certainly not flawless but gives us way more room to grow – it’s got somewhat open-source firmware, it comes from a respectable company, and it’s nigh-guaranteed to be easy to source. I am, of course, talking about esp-hosted – using ESP32 modules as your WiFi/BT card, over SDIO or SPI.

I’ve recently added an ESP32-C6 into my project, and setting up esp-hosted wasn’t ultra straightforward – so here’s a guide, and a discussion on what makes esp-hosted so cool and so incredibly promising. Spoilers: it works with privacy switches that cut out power, it could be hacked into a coprocessor for mesh protocols, and it could potentially help us build a fully open-source SDIO WiFi card.

Continue reading “ESP32 As Your Raspberry Pi’s Linux Wireless Co-processor” →

A Headset Fit For A Hackaday Writer

I started writing this from a commuter train passing at speed through the outskirts of London, and my headset had just broken. The flexible joint that attaches one earpiece to the headband has snapped, leaving the earpiece dangling on its cable. This is annoying on its own, but what is annoying me enough to write about it is that this isn’t the first time. This is only the latest in a succession of headsets I’ve taken on the road with me has broken, not because of rough treatment, but simply due to flimsy or bad design. What on earth can I do about this?

Failure Built-In

The earpiece of an EPOS headset, detached from its band.
Failure inevitable: the whole headset relied on a tiny piece of plastic in the centre.

The most recent three have been a JVC whose rotating joint allowing the earpiece to lie at a slight angle with my ear has failed, a quite expensive Logitech whose ear sponges failed closely followed by its USB cable, and now an EPOS whose ball joint has failed.

I repaired the JVC and got a bit more life out of it and I’ll have a go at repairing this EPOS, but that’s hardly the point. I’m paying not inconsequential money and I’m getting good sound quality and electronics, but I’m not getting anywhere near the mechanical quality I need. I could buy a set of tough DJ headphones such as the Sennheiser HD25, but they don’t come with a microphone, they’re not a headset.

So if I can’t buy a decent headset without spending military grade money on one from an F16 fighter, what can I do to make my own? I’m an engineer, damnit!

At its most basic, a headset is a springy band that goes over the head, with an earpiece at its end. But a human head is not a cube with vertical parallel sides, it’s a complex shape and every one is different. So those earpieces have to have some “give” in them in order to fit comfortably against the ear. In the simplest case this is achieved by giving the earpiece a soft surround that moulds itself to the ear, but most headsets incorporate some articulation. The earpiece must rotate a little around a vertical line parallel with the ear, and also with a horizontal line at right angles to the axis of the ear. The EPOS managed both axes by means of a ball joint, while the JVC had a stirrup with pins to achieve the horizontal motion, and a circular joint — the part which broke — for the vertical. In both case the weak point was a thin part of the plastic moulding which broke, on the EPOS a short stalk for the ball in the ball joint, and in the JVC a similar stalk for the circular joint. Any design I come up with must avoid this type of weak point, and spread the load of an earpiece over considerably more material than my broken headset. Continue reading “A Headset Fit For A Hackaday Writer” →