Re: [RFC PATCH 08/20] bpf: Add Landlock ruleset map type

[Mickaël Salaün]

On Fri, Apr 17, 2026 at 09:10:31AM -0700, Song Liu wrote:
> On Fri, Apr 17, 2026 at 8:18 AM Mickaël Salaün <mic@xxxxxxxxxxx> wrote:
> >
> > On Fri, Apr 17, 2026 at 10:09:13AM -0400, Justin Suess wrote:
> [...]
> > > > A new type of map for each FD referenced kernel type is non-starter.
> > > > It is impossible to add UAPI for a specific use case.
> >
> > This new map type is only about one file descriptor type, similarly to
> > socket FDs.  From a UAPI point of view, it looks clean and safe,
> > especially to deal with underlying object lifetime (e.g. reference
> > tracking).
> 
> We have changed the UAPI policy. New program type, new map type
> will not be added for a single use case.

Ok, I didn't know.

> 
> > > >
> > > You've convinced me. I could see a lot of problems if everyone wanting
> > > to add their specialized maps, it would be difficult to maintain.
> >
> > Is there another way to properly handle kernel object lifetime (not tied
> > to the caller) and pass them as file descriptor?
> 
> bpf_kptr gives same life time promise.

Ok, that could work if we can transform an FD to a kptr.

> 
> > >
> > > It's probably best to keep the specialized map types to core kernel
> > > interfaces only that are unlikely to change.
> >
> > File descriptors are a stable interface.
> 
> Maybe we can add a new map type that can handle file descriptor of
> any type.

Good idea, that would be much more generic indeed.  Maybe we could
add a new file_operations function specific to BPF so that each file
descriptor type can make their type supported by this new map type while
making sure only tested/reviewed FD type can be added to this map?
Something like file_operation.to_bpf_kptr(struct file *file)?

> I haven't thought about all the details. Maybe we don't need
> a new map type for this either. Instead, some new kfunc may be
> sufficient to make bpf_kptr work.
> 
> OTOH, adding a new map type just for landlock rulesets is not gonna
> happen.
> 
> Thanks,
> Song
>