Re: [PATCH bpf-next] bpf: add BPF_F_SEALED flag to seal BPF links at creation
David Windsor <[email protected]> Sun, 2 Aug 2026 23:26:30 -0400
| Newsgroups | org.kernel.vger.bpf |
|---|---|
| Message-ID | <CAEXv5_iKZnDvitaURzcAJDdHHB6H-YwP5MApMeCR64KqXQVRSQ@mail.gmail.com> |
On Sun, Aug 2, 2026 at 10:44 PM Leon Hwang <[email protected]> wrote: > > On 3/8/26 10:16, David Windsor wrote: > > Introduce a new BPF_F_SEALED flag for BPF_LINK_CREATE that creates the > > link permanently sealed. A sealed link can never have its program > > replaced via BPF_LINK_UPDATE, can never be detached via BPF_LINK_DETACH, > > and holds an extra self-reference that is never released, so the link and > > its program attachment persist until the machine reboots, even after user > > space closes every fd referring to it. There is no way to unseal a link. > > > > The sealed state is tracked by a new bool field on struct bpf_link. > > > Why do you want BPF_F_SEALED? What's your case for it? > For the BPF LSM use case, mainly. There is some language in the commitmsg about programs not being able to be unloaded until reboot, but I will be more explicit in v2. There was a presentation ("Securing BPF LSMs against tampering") [1] at LSFMM+BPF about it. [1]: https://lwn.net/Articles/1082111/ > I think 'sealed' should be set before allocating the FD to avoid the > race issues reported by Sashiko. > Will do this in v2. > Thanks, > Leon > > > [...]