The Landlock ABI matrix

PRD §20 says Landlock coverage is kernel-dependent. This page is the table that sentence is checkable against: what this build requires of a kernel’s Landlock, and what each rung of the ABI buys the ruleset on the way.

This build’s two numbers, both read out of the source that declares them rather than typed here:

• floor — build.landlock_min_abi = 6. A kernel reporting a lower Landlock ABI is refused at startup. It is not confined at a weaker rung.
• ceiling — build.landlock_max_rung = 9. A kernel reporting a higher ABI gets a rung-9 ruleset, journaled as isolation.landlock.clamped_by_build.

Both are printed by vitrind --print-floor.

The ladder below has 9 rung numbers naming 6 distinct enforced domains — that count is computed from the parsed ladder, not asserted, and the rungs that collapse into one domain are named in the domain table.

What this page is a fact about

This build, not your kernel. Nothing here probes anything. The generator runs on a laptop and on a CI runner and must emit the same bytes on both, so it reads the repository and never the machine — and the two machines this repository has actually run report different Landlock ABIs (the development box 9, the CI runner 7), which a probing generator could not have reconciled into one checked-in page.

The machine half is a command you run:

$ vitrind --print-isolation | grep landlock
$ vitrind --print-floor | grep landlock

The first prints what your kernel answers; the second prints the two build numbers above. The next table says what this build does with each possible answer. Which kernel releases produce which answer is not stated anywhere on this page, because it was not measured here — that mapping is a fact about mainline and about distributions, and this page probes neither. It is measured on a page of its own: which kernels this build starts on, from boot rows checked in under tests/kernel-matrix/rows/.

Read your own kernel against it

Every cell below is a property of this build’s own code — spawn::isolation’s Report::mechanism for the verdict and landlock::apply_with for the second refusal — with the floor at 6 and the ceiling at 9.

The ladder, one row per ABI rung

what it buys is the right or facility the rung adds. axis is which field of the request it moves, and it decides whether --landlock=abi:N can simulate a kernel without the rung: the cap sets handled_access_fs and scoped, so it can; it does not set the landlock_restrict_self flags word or handled_access_net, so for those rungs there is nothing for a cap to take away.

The handled_access_fs column is the cumulative mask this build asks a kernel at that rung for. It is parsed out of handled_access_fs in crates/vitrin-realm-init/src/landlock.rs and cross-checked against the measured table pinned in that crate’s the_rung_masks_pin_a_measured_table; the two readings disagreeing stops this page being emitted at all. The rights arrive in this order: rung 2 → REFER, rung 3 → TRUNCATE, rung 5 → IOCTL_DEV, rung 6 → the scoped field, rung 9 → RESOLVE_UNIX.

Which rungs are exercised is counted from this table, not asserted. A rung is counted here when a test in crates/vitrin-realm-init/src/main.rs enters a Landlock domain at it and asserts the kernel’s own answer — a syscall’s outcome inside the domain, or the kernel’s verdict on the request. Building a ruleset at a rung and never entering it does not count.

• rung 1 — a_realm_can_write_where_it_was_granted_and_nowhere_else, rung_one_forbids_reparenting_that_the_rung_above_permits
• rung 2 — rung_one_forbids_reparenting_that_the_rung_above_permits, the_truncate_rung_is_measured_and_its_absence_is_measured_with_it
• rung 3 — the_truncate_rung_is_measured_and_its_absence_is_measured_with_it
• rung 7 — the_audit_log_flag_is_off_unless_asked_for_and_the_kernel_takes_it

That is 4 of the 9 rungs this build can ask for. The one further row on this page (ABI 10) is above this build’s ceiling of 9 — a clamp, not a rung it requests — so it is not in that denominator. Below the floor the tally is the one docs/book/src/limits.md has to carry word for word:

below the floor of 6, rungs 1, 2 and 3 are exercised and rungs 4 and 5 are not.

Every cell on an unexercised row is derived from this build’s own source and measured against nothing — keeping the sub-floor tests that exist and adding none for the rest is decision D-044, not an oversight. Neither the name nor the rung is remembered. Each name above is resolved against BEHAVIOURAL_RUNGS in that same file, which declares the rungs that test enters a domain at; a name listed on a rung it does not enter refuses to render, a rung it does enter and this page omits refuses to render, and the tests cannot enter a domain without declaring it: the function that issues landlock_restrict_self demands a token only a recording ledger can mint, and the mint itself refuses a rung the test’s row does not declare — before the token exists, so that direction rests on no destructor. What the ledger still checks when it drops is the converse — a row declaring a rung the run never entered — and Drop is skippable in Rust by construction, which docs/book/src/limits.md publishes rather than argues away. The generator also refuses to emit when the limits page does not carry the tally above.

A test that asks the shipped helper for a rung enters a domain in another process, where no Rust type can reach it. That route is held separately: the core’s own confinement suite refuses a spawn reporting a rung this page publishes as entered by nothing, and tests/integration/ is scanned for a literal abi:N naming one. Both lists are computed from this corpus, so they move when it does rather than after it.

What each rung does not buy

The column this table exists for. A ladder printed without it reads as though every rung is pure gain, and the rows below say otherwise on the kernel’s own terms: rungs 4, 7 and 8 add nothing to the enforced domain of the rung beneath, counted from the parsed ladder rather than typed here. Rung 1’s row is sharper still — the absence of REFER makes its domain stricter, not weaker.

The enforced domains

Two rungs enforce the same domain when this build’s request is byte-identical at both — handled_access_fs, scoped and the landlock_restrict_self flags word together. The grouping below is computed from the parsed ladder. applied_profile still spells every rung differently, so read that string as which rung was obtained, never as how much confinement.

Each statement is published verbatim on the limits page, so the two can be compared without anyone adjudicating a paraphrase.

The flags column is zero at every rung because a shipped session passes zero. The one thing that moves it is VITRIN_LANDLOCK_AUDIT=1 in vitrind’s own environment, which sets rung 7’s LOG_NEW_EXEC_ON so the kernel keeps logging a realm’s denials past the shim’s execve. It changes what the kernel writes down, never what it permits, and it cannot be reached from realm.toml or a command line — so under it rungs 6 and 7 stop being one domain in the log flags only.

What the ruleset denies that the realm’s mount table does not

A realm is confined by a mount table and a Landlock domain, and most of what the domain refuses the mount table refuses too. Publishing the overlap as though the ruleset earned it would be the flattering direction, so this table is only the difference — and it is short.

Every claim this table carries, and where it is published

A row with a right and no claim, or a claim with no row, stops the generator. Each needle below is checked against the surface it names on every run, so a published sentence cannot be deleted or reworded while this table still cites it.

What is NOT on this page

• A per-kernel measurement. docs/plan/02-phase-2-semantic-epochs.md’s restated criteria for P2.6.3 ask for a table generated “from vitrind --print-isolation output on each kernel in the CI matrix, one row per ABI actually reported”. That is not what this is, and it is not a step towards it that was left half-taken: a table carrying the ABI of the machine that generated it cannot be byte-stable across two machines, so it cannot be the thing CI holds. The plan carries that as Correction 5.
• Which kernels clear the floor — measured elsewhere, not here. This page still probes nothing. Since 2026-08-16 the per-kernel measurement exists as its own artefact: the kernel page, generated from boot logs checked in under tests/kernel-matrix/rows/. Read the two together and do not confuse them — this page says what the build requires, that one says what five kernels answered and which of them the floor of 6 admits. Two live machines are also on record: this repository’s development box at Landlock ABI 9 on 2026-08-15, and the runner its CI uses at ABI 7 on 2026-08-14. The runner’s number was read out of a CI job log that archives nothing, and it is corroborated but not replaced by the kernel page: booting the runner’s own 6.17.0-1020-azure in a bare initramfs answers ABI 7 too, which is a fact about that kernel and not about that runner.
• Any statement that P2.6.3’s criteria were all met as written. The task (issue #187) was ACCEPTED on 2026-08-19, on its corrected criteria and on decision D-044 — not on the row the plan first wrote. That date is the plan’s acceptance record and the owner’s decision; the issue’s own closure timestamp is whatever GitHub writes when the merge lands, and this page asserts no value for it. What landed with this page is a generated ladder of what this build requires, held by CI. A per-kernel row set landed separately on 2026-08-16 — five kernels, on the kernel page — and it is a row per kernel, not the “one row per ABI actually reported” the criteria ask for, a clause no byte-stable checked-in page can satisfy (the plan carries that as Correction 5). Four things did not become true on acceptance: five kernels answered five ABIs, and four of the nine rungs are reported by none of them; every row on that page is a kernel reading taken in a bare initramfs rather than a distribution; the behavioural per-rung tests this page’s numbers rest on still live in vitrin-realm-init’s own suite, running on this repository’s development box and on the CI runner and on no third machine, with the values they pin recorded on one box on one date; and the sub-floor half of those tests is evidence about the --landlock=abi:N dial rather than about any state a stock session reaches.
• The realm’s grant table. Which hierarchies get which rights is the limits page’s two-tier grant list, not a per-rung fact. The only grant-table row here is the one denial the mount table does not carry.

Runbook

To change what this page says, change the code or the published prose — never this file.

$ cargo xtask isolation-matrix          # regenerate in place, then review `git diff`
$ cargo xtask isolation-matrix --check  # what CI runs; reads only, writes nothing

The generator refuses to emit anything when:

1. a pinned line of crates/vitrin-realm-init/ or crates/vitrin-core/ source is gone, so a cell here would describe code that no longer exists;
2. LANDLOCK_MIN_ABI or LANDLOCK_BUILD_MAX_RUNG cannot be read, or the ladder in landlock.rs cannot be parsed — a shape the parser does not recognise is an error, never a rung silently dropped;
3. the parsed ladder disagrees with the measured mask table pinned in the_rung_masks_pin_a_measured_table;
4. a rung row names no published claim, or a published claim is named by no row;
5. a claim’s needle is no longer on the surface it cites;
6. a domain has no tier statement, or a tier statement is not on the limits page verbatim.

Adding a rung is therefore not an edit to this page: move the right in landlock.rs, publish what the rung is worth, add the row and its claim to crates/xtask/src/isolation_matrix.rs, and regenerate.