DooM Retrospective: 25 Years of Metal

Metal is many things. A material hard and coarse in nature that by forging it in fire becomes sharp enough to cut through anything in its path. The music that bares its namesake is equally cutting and exudes an unyielding attitude that seeks to separate the posers from the true acolytes. Metal is the sentiment of not blindly following the rules, a path less taken to the darker side of the street. In videogame form, there is nothing more metal than Doom.

The creators of Doom, id Software, were always hellbent on changing the perception of PC gaming in the 1990s. Games of the time were rigid and slow in comparison to their console counterparts. The graphical fidelity was technically superior on PC, but no other developer could nail movement in a game like id. The team had made a name for themselves with their Commander Keen series (which came about after a failed Super Mario Bros. 3 PC demo) along with the genre defining Wolfenstein 3D, but nothing topped Doom. In an era that was already soaking with “tude”, Doom established an identity all its own. The moody lighting, the grotesque monster designs, the signature push forward combat, and all the MIDI guitars a Soundblaster could handle; Doom looked and felt a cut above everything else in 1993.

In December of that year, Senators Joe Lieberman and Herb Kohl held a hearing to publicly condemn the inclusion of violence in videogames sold in America. The bulk of the arguments sought to portray the videogame industry and its developers as deviants seeking to corrupt the nation’s youth. Id Software responded as if to raise the largest middle finger imaginable, by releasing Doom to the world the very next day. A quarter of a century later people are still talking about it.

Continue reading “DooM Retrospective: 25 Years of Metal”

Peering Into a Running Brain: SDRAM Refresh Analyzed from Userspace

Over on the Cloudflare blog, [Marek] found himself wondering about computer memory, as we all sometimes do. Specifically, he pondered if he could detect the refresh of his SDRAM from within a running program. We’re probably not ruining the surprise by telling you that the answer is yes — with a little more than 100 lines of C and help from our old friend the Fast Fourier Transform (FFT), [Marek] was able to detect SDRAM refresh cycles every 7818.6 ns, lining right up with the expected result.

The “D” in SDRAM stands for dynamic, meaning that unless periodically refreshed by reading and writing, data in the memory will decay. In this kind of memory, each bit is stored as a charge on a tiny capacitor. Given enough time (which varies with ambient temperature), this charge can leak away to neighboring silicon, turning all the 1s to 0s, and destroying the data. To combat this process, the memory controller periodically issues a refresh command which reads the data before it decays, then writes the data back to fully charge the capacitors again. Done often enough, this will preserve the memory contents indefinitely. SDRAM is relatively inexpensive and available in large capacity compared to the alternatives, but the drawback is that the CPU can’t access the portion of memory being refreshed, so execution gets delayed a little whenever a memory access and refresh cycle collide.

Chasing the Correct Hiccup

[Marek] figured that he could detect this “hiccup,” as he calls it, by running some memory accesses and recording the current time in a tight loop. Of course, the cache on modern CPUs would mean that for a small amount of data, the SDRAM would never be accessed, so he flushes the cache each time. The source code, which is available on GitHub, outputs the time taken by each iteration of the inner loop. In his case, the loop typically takes around 140 ns.

Hurray! The first frequency spike is indeed what we were looking for, and indeed does correlate with the refresh times.

The other spikes at 256kHz, 384kHz, 512kHz and so on, are multiplies of our base frequency of 128kHz called harmonics. These are a side effect of performing FFT on something like a square wave and totally expected.

As [Marek] notes, the raw data doesn’t reveal too much. After all, there are a lot of things that can cause little delays in a modern multitasking operating system, resulting in very noisy data. Even thresholding and resampling the data doesn’t bring refresh hiccups to the fore. To detect the SDRAM refresh cycles, he turned to the FFT, an efficient algorithm for computing the discrete Fourier transform, which excels at revealing periodicity. A few lines of python produced the desired result: a plot of the frequency spectrum of the lengthened loop iterations. Zooming in, he found the first frequency spike at 127.9 kHz, corresponding to the SDRAMs refresh period of 7.81 us, along with a number of other spikes representing harmonics of this fundamental frequency. To facilitate others’ experiments, [Marek] has created a command line version of the tool you can run on your own machine.

If this technique seems familiar, it may be because it’s similar the the Rowhammer attack we covered back in 2015, which can actually change data in SDRAM on vulnerable machines by rapidly accessing adjacent rows. As [Marek] points out, the fact that you can make these kinds of measurements from a userspace program can have profound security implications, as we saw with the meltdown and spectre attacks. We have to wonder what other vulnerabilities are lying inside our machines waiting to be discovered.

Thanks to [anfractuosity] for the tip!

High-Speed Camera Plus Lawnmower Equals Destructive Fun

I hate gratuitous destruction videos. You know, the ones that ask “what happens if we drop a red-hot ball of Plutonium onto a bag of Cheetos?” There’s a lot of smoke, flames and a big pile of ad revenue for the idiots behind it.

This destruction video is a little different, though. [Tesla 500] wanted to mount his high-speed camera onto a rotating blade, but without destroying the camera. In this video, he documents the somewhat nerve-wracking process of building a rig that spins a $3000 camera at several thousand revolutions per second minute. It’s all about the balance, about building a rig that balances the weight of the camera and the blade properly at high speed.

It took several attempts to get it right, and [Tesla 500] shows how he tested and refined each version, including shifting weights to account for the different densities of the camera itself, which has the heavy batteries at one side. And then he drops things onto the blade to see what they look like when sliced. Naturally.

Continue reading “High-Speed Camera Plus Lawnmower Equals Destructive Fun”