Re: [PATCH bpf-next] bpf: add BPF_F_SEALED flag to seal BPF links at creation

On Sun, Aug 2, 2026 at 8:26 PM David Windsor <[email protected]> wrote:
>
> 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 had to skim the articles to recall that it was me proposing
something like this :)

Anyways, as Kumar mentioned, a) link has to be crated as sealed before
FD is exposed, it's straightforward, and b) I do think that it would
be too easy to have syzbots of the world to accidentally or not create
tons of sealed links, so I'd require CAP_SYS_ADMIN for this, which I
assume won't be a problem for intended use cases?

But also, yeah, I wonder what Christian and other BPF LSM users think
about this.

pw-bot: cr


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