This post publishes on 1 May 2026

Come back at midnight, England time. The packet is written. It just hasn’t been sent yet.

--hours
--minutes
--seconds

Midnight BST — that’s UTC+1, for the pedants (and the researchers).

The open source that made this possible

Apple publishes XNU — the kernel at the heart of every Mac — as open source. They are not obliged to. They have been doing it for over twenty years. Every piece of macOS research on this blog depends on that decision, and it deserves to be said plainly: thank you.


There is a URL I visit more than almost any other in the course of this work: opensource.apple.com. It is not much to look at. It is a list of software packages, versioned and archived, going back to the early 2000s. It is, for a macOS security researcher, one of the most useful pages on the internet.

Apple publishes XNU there — the kernel that runs on every Mac, every iPhone, every Apple Watch. XNU is where the Mach microkernel meets the BSD layer, where system calls are handled, where the security framework lives, where proc_check_settid is, where unveil equivalents are implemented, where the thing that actually runs your computer does its work. Apple could keep it closed. Many large technology companies keep their kernels entirely proprietary. Apple has been publishing XNU source with each macOS release for over two decades.

This post is about why that matters, and why it is worth saying so explicitly.

What open source actually enables

When I describe the BSD cross-reference technique in an earlier post on this blog — the practice of using FreeBSD and OpenBSD security advisories as an annotated changelog for Darwin — I am describing something that only works because XNU is public. You cannot cross-reference source code you cannot read. You cannot verify that a fix from the BSD world was applied to the Darwin equivalent without being able to look at both. The entire methodology depends on Apple having made the source available.

The same is true of every responsible vulnerability report I have filed with Apple. Before submitting anything, I verify the code path in the current XNU source. I check that the behaviour I observed matches what the source suggests should happen. I confirm the affected function is where I think it is. I read the comments left by the engineers who wrote it — sometimes those comments explain exactly why a particular choice was made, which is invaluable context for understanding whether something is a bug or a design decision.

None of that is possible on a closed kernel. You are guessing at the implementation from observed behaviour, which produces worse reports, more false positives, and more friction for the vendor. Apple publishing XNU makes the research better and makes the disclosure process better. Both parties benefit.

The FreeBSD attribution comments

Something I notice repeatedly when reading XNU source is the attribution. Scattered throughout the BSD layer of the kernel are comments like:

/* $FreeBSD: src/sys/kern/kern_proc.c,v 1.55 ... $ */

These are not just archival footnotes. They are a map. They tell you which file in FreeBSD this code descends from, which makes cross-referencing BSD security advisories against XNU source tractable rather than guesswork. Apple left those comments in. They did not have to.

It is a small thing. It is also, from a researcher's perspective, quite a significant one. Those comments are what make the BSD cross-reference technique reliable. Without them you are comparing code by eye and hoping the lineage is what you think it is. With them you have a documented trail back to the upstream source.

The Platform Security Guide

The open source kernel is not the only example of this. Apple also publishes the Apple Platform Security guide: a detailed, publicly available technical document explaining how the security architecture of macOS and iOS actually works. The Secure Enclave. The Secure Boot chain. Pointer authentication. The codesigning infrastructure. TCC. AMFI. How keys are derived, stored, and used. How the kernel integrity checks work.

This document is genuinely unusual. Most large technology companies treat the internal workings of their security architecture as proprietary information to be protected, not explained. Apple treats it as something the research community, the enterprise security teams, and the informed public should be able to read and understand. The Platform Security guide is updated with each major release. It is honest about how things work. It is not a marketing document.

I have read it cover to cover more than once. I have used it to orient myself before starting research on a new subsystem. I have referred security engineers at other organisations to it when they needed to understand what macOS was actually doing. It is, straightforwardly, a good thing that it exists.

Trusting the research community

There is an implicit act of trust in publishing your kernel source. It means accepting that security researchers will read it, find things in it, and report them — or, occasionally, write about them. Apple has been accepting that for over twenty years. The Apple Security Bounty programme formalises the relationship, but the open source decision predates the bounty programme by a long way.

That trust is not unlimited or unconditional. Apple has its own disclosure expectations, its own timeline, its own sense of what constitutes a genuine security issue. Researchers and the company do not always agree on those things. But the baseline — here is the source, you can read it, good research depends on that — is something that a great many users and researchers benefit from without necessarily noticing it.

I notice it. Every time I open a XNU source file on the Mac Mini in Whitby, sitting next to the same kind of cup of tea that was going cold when I filed my first research notes, I am reading something Apple chose to make readable. That choice is not trivial. It is worth acknowledging.


A PING only works if the other end is reachable. Asking careful questions about a system requires being able to see, at least partially, how it is built. Apple has been making their kernel visible for over twenty years, which means researchers can ask better questions, file better reports, and understand better answers.

The packet can only find what it can reach. Thank you for leaving the light on.