Windows Under the Hood: malloc, BitLocker & OS

Your laptop runs Windows. Windows runs on malloc. Malloc runs on a kernel allocator you've never heard of. And somewhere in that stack is a BitLocker vulnerability that means if you left your laptop on a bus and didn't set a PIN, whoever found it can read your drive. Welcome to Shop Talk #82, where Dave and Glenn spend 47 minutes peeling back the abstraction layers most of us never think about — and a few we probably should have been worried about all along.

malloc is not magic (but it's also not simple)

Dave opens with the question every junior engineer has wondered: when do you actually write your own memory allocator instead of just calling malloc? His answer: almost never, and if you feel the urge, sit with that feeling for a while before acting on it.

The exception he describes is specific — you're writing a database, you know upfront that you'll have exactly 1,000 records at 1,000 bytes each, so you carve out a 1MB arena and hand out chunks sequentially. No bookkeeping, no fragmentation, no surprises. "Test it, time it, find out for sure" is the actual advice, which is refreshingly undramatic. The custom allocator case is real, but it's narrower than the internet would have you believe.

On the terminology question (arena vs. pool vs. heap — people in the comments were genuinely confused): Dave describes pool as the total available memory, heaps as organized piles within it, and arenas as sections you carve off a heap for private use. He's upfront that industry usage isn't perfectly consistent. That kind of epistemic honesty — "I'm not 100% on this" from someone who literally wrote Windows allocator code — is more useful than false certainty.

The mechanics of what malloc actually does deserve their own treatment, but the short version from this episode: malloc isn't touching physical memory directly. It's calling down through layers — RTL heap allocators, NT virtual memory managers — and carving up blocks from whatever the OS already mapped in. Double-freeing a pointer doesn't just "do nothing because it's already free." It either triggers a detectable failure if the allocator catches it, or it corrupts the heap metadata and crashes your application later in a way that looks completely unrelated. "Passing nonsense to free is a sure recipe for crashing," Dave says. The sneaky part is it won't necessarily crash immediately.

The BitLocker thing is actually a big deal

This is where the episode earns its runtime.

A viewer asks how a TPM exploit can release a BitLocker decryption key without a valid password. Dave's answer is, essentially: there's an intentional recovery path baked into the design, and this exploit escalates through that path. If you don't have a TPM PIN set, someone who physically has your machine can boot it with a USB key and read the drive. Full stop.

"I can come to your office which has a drive which is protected by BitLocker. And if you guys have a PIN on it, you're fine. But if you don't, I can just boot that machine, stick my USB key in, and read your drive."

The attack surface here matters: this isn't a remote code execution vulnerability. It requires physical access. The attack complexity differs significantly depending on the variant — a pre-boot bypass via bootable USB is accessible to almost anyone, while other approaches like sniffing the TPM bus with a logic analyzer require actual hardware and expertise. But the pre-boot bypass is the one that applies to your laptop on the airport seat. The threat model for "laptop left on a bus" is real enough that this should change behavior.

Dave's honest about the limits of his knowledge here — he doesn't know exactly how the key is being extracted at the cryptographic level, whether it's a hardware mechanism or a trusted-OS API call being abused. A viewer suggests it's more of a boot recovery environment escape than a BitLocker defeat proper. Dave's response: "It is, but it defeats BitLocker." The semantic distinction doesn't matter to your data.

The practical upshot: set a TPM PIN. If you have sensitive data and genuinely can't verify your setup, consider VeraCrypt or similar tools with password-based encryption that doesn't depend on an unlockable recovery path. Dave mentions he used TrueCrypt heavily before it was deprecated — and that he didn't know about this BitLocker behavior until recently. If an ex-Windows engineer didn't know, most users definitely don't.

Handles: the analogy that actually worked on me

The handles discussion is one of those explanations where I had the concept basically right and still found myself recalibrating. Dave's framing: a handle is an opaque number that points into a table, which then points to the actual memory address of the thing you care about. You don't get the raw address because the OS might need to move the object, and if you'd cached the address directly, you'd be pointing at garbage.

The analogy he uses is postal. Instead of giving you Glenn's home address (123 Main Street), he assigns Glenn the letter Q. Q maps to whatever Glenn's current address is. The object can move; the handle doesn't. Everyone just uses Q.

What got me about this wasn't the concept — it was the reason for the indirection. It's not just about hiding information from the caller (though it does that). It's about the OS needing the freedom to manage its own memory without contracts it can't honor. The handle is a promise that survives relocation. The raw address is a promise that breaks the moment anything moves. The design decision is about which promises are sustainable, not which ones are more convenient. Once I heard it that way, a lot of weird OS behavior snapped into place — why file descriptors work the way they do, why you don't just get a pointer back from CreateFile, why "treat handles as opaque" is such insistent advice in systems documentation.

Backwards compatibility: flex or haunting?

Someone asks why Microsoft doesn't just ship a compatibility-free version of Windows with a clean kernel, keeping a separate legacy version for old hardware and apps. Dave's response sidesteps the emotional weight of the question: would it actually be better?

He doesn't know that it would. "It's more work for Microsoft to keep things working backwards compatible, but I don't think the user pays much of a tax on that one." Then he issues an open challenge: name a specific situation where backwards compatibility actually burned you as a user.

I find that challenge genuinely interesting, and I'm not sure I fully buy the framing — but I also can't easily knock it down. The anti-compatibility intuition is that old cruft creates security surface area, architectural debt, obscure interaction bugs. The pro-compatibility reality is that someone else's 1999 Delphi app still runs on Windows 11, which is either a remarkable feat of engineering or a haunting reminder that we never actually throw anything away. Probably both, depending on whether you're the person who needs that app or the person who has to maintain the OS that supports it.

When a viewer makes the point that NetBSD also runs code from that era, Dave concedes it immediately: "BSD. There's your answer." So Windows doesn't have a monopoly on longevity. But it does have a monopoly on the specific ecosystem — enterprise software stacks, proprietary drivers, line-of-business applications — that makes the backwards compatibility promise actually matter to large numbers of people. The question isn't can you compile 25-year-old code on a modern OS. It's which 25-year-old code, and for whom.

The case sensitivity thing that gets tagged onto this section is where I feel the maddening-vs.-poetic question most acutely. NTFS actually tracks case — it knows the difference between Foo and foo — but defaults to case-insensitive matching. Linux is case-sensitive. Both choices were reasonable at the time; both got baked in; now moving files between systems occasionally produces silent failures that look like bugs and are actually just two systems with different defaults that both got ossified. It's the kind of thing that's too mundane to be poetic and too structural to be annoying at an individual. It's just... the terrain.

printf and the liberation that bites back

Never pass user data directly to printf. That's the one. Dave says it, the audience in the comments already knows it, and it's still the source of actual vulnerabilities in production code. The %n specifier — which writes the current byte count into memory — is the particularly sharp edge: hand an attacker control of a format string, and you've handed them an arbitrary write primitive.

Dave's broader point about printf is worth sitting with. The function was designed for an era when the programmer was the customer — if you passed the wrong arguments, you took the pain. That's a different social contract than shipping code that will run on millions of machines where the bugs happen to someone else. Dave's careful: printf is foundational, probably the first function in C to implement variadic arguments (though he flags that as off-the-cuff speculation, not documented fact). And yes, at some layer of the stack, a huge amount of text formatting in modern software runs through printf-family functions. But "the world runs on printf" — Dave's own line — is doing a lot of work. Many modern runtimes and JSON serializers use custom formatting code that doesn't touch printf at all. The family is foundational; it's not universal.

397 questions with question marks

At the end of the episode, Glenn mentions he's working through 397 comments that contain question marks — the signal that viewers want something addressed on the show — trying to pull out 50 worth covering.

397 is a specific number, and it tells you something particular: this is an audience that doesn't just watch, it interrogates. The questions Dave and Glenn are fielding aren't "how do I center a div" softballs. They're "why does double-freeing corrupt the heap when the memory is still technically mapped to my process" and "is the TPM PIN protecting me or not." These are people who have hit something confusing in the actual machinery of computing and want to understand the mechanism, not just the workaround.

That density of genuine curiosity is rarer than it should be. And Dave's willingness to say "I don't know, that's a kernel problem" or "I didn't know that either" — instead of papering over the gaps — is exactly why the questions keep coming.

Zara Chen covers tech and politics for Buzzrag.