From 8c1bd446f45479e67cf75f97e5fa8b58d2825bea Mon Sep 17 00:00:00 2001 From: Manuel de Brito Fontes Date: Mon, 5 Oct 2026 01:40:46 -0300 Subject: [PATCH] kernel: strike the BPF_LSM note the guard replaced The lockdown commit enabled CONFIG_SECURITY and CONFIG_BPF_LSM and guarded both above the BPF section, with the reason beside the guard. The note here still says BPF_LSM is off and why somebody would switch it on: the decision it records has been made, by the guard, and the two now disagree in one file. A build cannot read either; the build reads the guard. --- kernel/Dockerfile | 7 ------- 1 file changed, 7 deletions(-) diff --git a/kernel/Dockerfile b/kernel/Dockerfile index ed06a69..c2c5b03 100644 --- a/kernel/Dockerfile +++ b/kernel/Dockerfile @@ -298,13 +298,6 @@ RUN < 78.5 ms; with # patches/0004 (PCI configuration through ECAM, one trap an access), 73.7. - # BPF_LSM is deliberately NOT enabled, and this is where the decision is written down - # so it is not made again by accident. It depends on CONFIG_SECURITY, which is off here - # and would put LSM hooks on paths this kernel is tuned for boot time on — and what it - # buys is the ability to enforce access policy *inside* a VM that holds one workload, - # which is a boundary drawn inside the boundary this machine already is. Somebody who - # needs to develop BPF LSM programs turns on CONFIG_SECURITY and this, deliberately, - # with a measurement, and accepts that it is a different machine. # Boot performance: the RAID6 PQ benchmark probes all SIMD implementations at boot to # pick the fastest. It must stay disabled. (RAID6_PQ itself is not selected today, so