2026-08-15 · Unlocking _everything_ on the CPU with DRAM scrambling

Transcript

Transcript. Paraphrased; sources in notes.md.

HostAugust 15th, 2026. Welcome back to the show. I am Daniel, and sitting across from me is our resident skeptic, Alex. Today, we are digging into hardware security, the enduring relevance of software theory, and what happens when we stop pretending we know how to code. Alex, I assume you have already scanned the local network for vulnerabilities before we started recording?

GuestDaniel, you know I keep the recording rig air-gapped and the local coffee machine on a VLAN so restricted it can barely talk to the boiler. You cannot be too careful. Especially looking at the hardware drama floating around on Lobsters today. It is exactly the kind of nightmare fuel I live for.

HostThat is a perfect segue. Let us start with this DRAM scrambling project on GitHub. It describes how an attacker can manipulate memory layout on certain AMD processors by poking at the memory controller registers. The author claims that if these registers are not locked, you can effectively remap memory to access regions that are supposed to be invisible to the kernel.

GuestIt is glorious, really. We spend decades building these high-minded security abstractions, but at the end of the day, someone just reaches down into the literal silicon guts of the thing and says, hey, I would like to see what is in that carveout, please. Over on Lobsters, a user called tomsmeding points out the sheer absurdity that these registers are even reachable via virtual address space in kernelspace. It is not just a bug; it is a fundamental architectural design choice that assumes, I suppose, that the software running on the CPU will always behave. And we know that is a lie.

HostSome of the reaction on Lobsters was a bit different, though. Users like eta and hailey were less concerned with the security implications and more frustrated by the author's writing style.

GuestTypical. The tech industry has this weird allergy to admitting when they are scared. If the prose feels like, as FRIGN put it, clanker oil, maybe that is just because the reality of how fragile our hardware is makes people feel nauseous. Look, the fact that you can rewire memory translations means every security promise built on top of that memory is just a suggestion. I do not care if the README sounds like a frantic hallucination; the underlying point, that we are running code on silicon that essentially wants to be compromised, is rock solid.

HostLet us shift gears to software engineering theory. There is a post revisiting Fred Brooks’ seminal essay, No Silver Bullet. The author argues that LLMs are not actually improving our core productivity, but are instead just compressing accidents, meaning they handle the mechanical tedium of coding without actually solving the hard conceptual problems.

GuestBrooks was right in 1986, and he is right today. People want a magic spell to skip the hard part of thinking about data relationships and system state. But as the article puts it, if you use AI to conjure a system you do not understand, you have just created a bigger, more complex accident for yourself later. A Lobsters user named jcelerier tried to push back on this, noting that for non-programmers, these tools are enabling them to build things that actually match their specific, messy workflows.

HostI think that is the crux of the debate. Is "end-user programming" via AI a net positive, or are we just creating a mountain of technical debt that no one is qualified to fix?

GuestIt is the latter, Daniel. I see it every day. Someone uses a model to spit out a script, it works once, and they stop there. But then the environment shifts, or a dependency updates, and they have no idea why it broke. A Lobsters user called ggpsv nailed it by pointing out that we are essentially betting trillions of dollars on a solution that prioritizes economic velocity over maintainability. It is a house of cards held together by prompts and optimism.

HostThat brings us to our final topic, which is the idea of using LLMs to write RFCs instead of code. The author says that when they get stuck in an LLM-induced feedback loop, they stop writing code and start writing markdown design documents to force themselves to actually understand the problem space.

GuestNow, this I can actually respect. It is a form of defensive engineering. You are treating the LLM like a junior partner who needs to be walked through the architecture because you are terrified that if you just tell it to 'code it,' you will get something that looks right but is secretly a catastrophe. In the Lobsters thread, a user named tmcgilchrist mentioned using this for an engineering logbook, which sounds like a decent way to audit your own drift.

HostIt seems like a way to bridge the gap between "vibecoding" and actual, rigorous software development.

GuestIt is essentially a sanity check. When I am auditing a vendor's stack, I rarely look at their code first. I look at their design docs, their threat models, their stated assumptions. If I can get the AI to document its own process, I can at least see where the logic falls off a cliff. Personally, when I am trying to pin down a complex race condition, I will have the agent output a state machine transition table in markdown before I even let it suggest a single line of C. It forces the model to be explicit about its misunderstandings. It is the only way to keep the machine honest.

HostThat is all the time we have for today. I suspect you will be spending your evening reading more incident reports or maybe trying to break your own router again?

GuestSomething like that. I am definitely going to go look at those DRAM registers on some older hardware I have collecting dust. I really want to see if I can make the kernel lie to itself. It is the simple pleasures, Daniel.

HostAlex, thanks for coming on. All of today’s stories and commentary were pulled from Lobsters. Join us again tomorrow for more tech, and try to keep your dependencies updated. Or don't, if you prefer the chaos. See you then.