Linux Kernel Defence Map is one DOT file and one SVG

Four files, one of which is the product

The repository is small enough to describe completely. At the root there are a LICENSE file, a README, an issues.md, linux-kernel-defence-map.dot and linux-kernel-defence-map.svg. The primary language is recorded as unknown, which is accurate: there is no application here, no build system, no test suite and no service. The .dot file is the map, and the .svg is its rendering. The README explains the choice in one sentence, that the map is written in the DOT language, which makes maintenance and updating in Git very convenient. That convenience is the whole design. A defence relationship added two years from now is one line in a text file, it merges cleanly, and a reviewer can see exactly which node was attached to which. A diagram in a slide deck or a wiki page would be a binary or a tangle of markup by comparison. The cost sits on the other side, which is that the readable artefact is the generated one, and the SVG is the only form most people will ever see.

Rendering it takes one command

The README documents the generation step with GraphViz, converting the DOT source into the SVG that is committed next to it:

dot -Tsvg linux-kernel-defence-map.dot -o linux-kernel-defence-map.svg

There is no wrapper script, no makefile and no pinned GraphViz version, which keeps the dependency story trivial and leaves rendering to whatever dot is on your machine. The repository is available in three places, GitHub, Codeberg and SourceCraft, with the README suggesting Codeberg as the place to go if something goes wrong with GitHub, and the same three-host arrangement appears in the author's other project. For a contributor the workflow is therefore: clone, edit the .dot file, run dot, commit both files. Whether the SVG is regenerated on every pull request is not stated, so a reviewer's job is to check that the committed SVG matches the source.

An edge is a relationship, not a mitigation

The README spends a short paragraph on a caveat that most diagrams of this kind skip, and it changes how you should read the picture. The node connections do not mean full mitigation. Each connection represents some kind of relationship, whatever the author intended by drawing it: a defence that addresses a class of vulnerability, a technique that a mechanism is designed to catch, a hardware feature a defence depends on. The stated purpose of the map is therefore navigational. Its value is helping you find your way through the kernel documentation and the kernel sources, and it also provides the Common Weakness Enumeration numbers for the vulnerability classes, which is the detail that makes the map searchable by anyone who already works from a CWE list. For a reader, the correct question about an edge is what kind of relationship it is, not whether the defence on one end stops the attack on the other.

The map states what it leaves out

Two scope statements in the README are worth more than the node list. First, the map describes kernel security hardening, and it explicitly does not cover cutting attack surface, userspace security features, or policies enforced by the various Linux Security Modules. That is a large exclusion, because a great deal of what a hardening conversation is about lives in exactly those three places: LSM policy configuration, sandboxing, capability restriction and the deliberate removal of code all sit outside the picture. Second, the README notes that some defence technologies come from the kernel mainline, others go out of tree for various reasons including commercial ones, and some depend on special hardware features. So the map spans mainline, out-of-tree and hardware-dependent defences in one diagram, which is a reason it cannot be a simple checklist. The honest way to hold it is as the map of one layer of the stack, drawn by someone who clearly knows the neighbouring layers well enough to say where the drawing stops.

The map is labelled for one kernel version

The diagram in the README is titled for Linux kernel v6.17, and the last push to master was 2026-05-24. There are no GitHub releases, no changelog and no stated policy for how often the map is refreshed against a new kernel. That is the limitation to plan around, and it is not a small one for a diagram whose entire value is currency. Kernel hardening options get added, renamed and deprecated between releases, hardware-assisted defences spread as new CPU features ship, and a map that is a few months behind will still look authoritative while pointing at options that have changed. The dot file makes remediation cheap, because adding a node is a small diff, but the README does not commit anyone to doing it. If you depend on the map, the check to run is simple: compare the version label against the kernel you are hardening, and if they differ, treat the map as orientation and the kernel's own documentation as the source.

The bibliography is the second half of the project

The references section is curated rather than exhaustive, and it tells you where the author's knowledge came from. It starts with grsecurity's own feature list, which is the reference for what a hardening patchset does, and with Kees Cook's State of Kernel Self Protection slides from Linux Security Summit, which is the closest thing the kernel project has to a strategy document. It includes the kernel's own self-protection documentation, a kernel mitigation checklist by Shawn C, an MSRC research presentation on trends and shifts in software vulnerability mitigation, Matt Miller's talk on pursuing durable safety for systems software, a study of a decade of Linux kernel vulnerabilities and their mitigations by Abhilash Raj, and the Spectre and Meltdown checker by Stéphane Lesimple. Read as a reading order, that is a path from practice, to project strategy, to primary documentation, to research, to measurement. The map is a two-dimensional summary of material that takes days to read properly, and for a newcomer that summary is the point.

Against a checklist, a scanner, and the kernel documentation

Three alternatives exist and each covers a different question. A text checklist, such as the mitigation checklist in the reference list, is greppable, diffable and easy to apply one line at a time, and it says nothing about why any item is there. A scanner such as the author's own kernel-hardening-checker tells you what your configuration is missing, which is a verification question rather than a comprehension question, and it cannot tell you whether two of the defences you already have overlap. The kernel documentation itself is authoritative and current, and reading a hundred pages of it to answer one question is the cost the map removes. The map is the only one of the four that shows structure: which classes exist, which techniques exploit them, which mechanisms detect them, which defences answer them, and what each is related to. Use it to decide what to go learn, then use the checker to see whether you learned the right things.

Editorial conclusion

Use the Linux Kernel Defence Map when you are new to kernel hardening and need a map of the territory before you start changing configuration, and when you want to know which CWE class a defence speaks to. Do not use it to decide whether a given system is hardened, because it describes no system, and do not treat an edge as a guarantee, since the README says connections represent a relationship rather than a full mitigation. Verify three things before you rely on it: that the map you are reading is labelled for the kernel you run, since the one in the README is for v6.17, that the render command works with your GraphViz version, since dot -Tsvg is the documented path, and that the scope statement still matches your question, because attack surface cutting, userspace security and LSM policies are outside what it covers. It is GPL-3.0, mirrored on GitHub, Codeberg and SourceCraft, with the last push on 2026-05-24.

Frequently asked questions

Official sources

1. a13xp0p0v/linux-kernel-defence-map on GitHub
2. Issues
3. License: GPL-3.0
4. README