The console's lockdown and bpf-restrict-fs lines are said in the kernel's README, and the lockdown boot check runs in a workflow #231

The guest's console shows two lines a reader takes for missing protection:

bpf-restrict-fs: Failed to load BPF object: Invalid argument
Lockdown: init: use of bpf to read kernel RAM is restricted; see man kernel_lockdown.7

What they are

Lockdown is on, at confidentiality from the first instruction (kernel/config-7.3-x86_64: CONFIG_SECURITY_LOCKDOWN_LSM_EARLY, CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY, CONFIG_LSM="lockdown,bpf"). The second line is lockdown refusing something. What it refuses is the workspace's own systemd: its RestrictFileSystems= program (src/bpf/restrict-fs.bpf.c) reads the filesystem type with bpf_probe_read_kernel, which lockdown withholds, so the verifier rejects it (the first line). systemd then skips RestrictFileSystems= silently. Spinbox's own BPF LSM programs (vminitd's guard and seal) read no kernel memory, load before the handoff, are fatal if they fail, and are tested end to end (spin/internal/e2e/guard_test.go, seal_test.go).

So nothing Spinbox relies on is missing; a tenant's systemd cannot use RestrictFileSystems= under confidentiality lockdown, by choice (decided: keep confidentiality; lowering to integrity would let guest root read kernel memory again).

What it does

• kernel/README.md says both lines, what they mean, and that RestrictFileSystems= is unavailable to a workspace's units under lockdown.
• The boot check that lockdown is [confidentiality] and root cannot lower it (boot/lockdown_test.go, task boot:lockdown) runs today only by hand: it runs in a workflow (compat.yml), and spin's e2e asserts /sys/kernel/security/lockdown reads [confidentiality] on a running workspace.