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
>
> > [...]