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

["Mickaël Salaün" <mic@digikod.net>]

On Fri, Apr 17, 2026 at 10:09:13AM -0400, Justin Suess wrote:
> On Thu, Apr 16, 2026 at 04:47:40PM -0700, Song Liu wrote:
> > On Thu, Apr 16, 2026 at 2:53 PM Justin Suess <utilityemal77@gmail.com> wrote:
> > [...]
> > > I don't think we can pass the FD number via a map, since the FD is
> > > process specific. And it needs to be done in a way where we can lookup
> > > the specific ruleset the FD points to safely.
> > >
> > > So we'd need some other way to load the ruleset from a file descriptor,
> > > either through a new userspace side BPF call or similar mechanism.
> > >
> > > Is there some other common pattern for FDs --> kptr I can follow?
> > 
> > I didn't find an exact example like this. There must be a way to achieve
> > this. In the worst case, we can add a kfunc for this.
> >
> 
> I think new kfunc is a doable approach. I could make a kfunc taking a struct
> *task_struct and an FD that looks up a landlock ruleset within a given
> task that returns a trusted kptr.
> 
> Something like:
> 
> struct bpf_landlock_ruleset* bpf_landlock_get_ruleset_from_fd(struct
> task_struct* task, int fd)

That looks like a hack that would not handle FD's (object) lifetime
(e.g. what happen when the task is gone?).

Why not using proper typing with a dedicated map?

> 
> And tagging it with KF_ACQUIRE + KF_RET_NULL.
> 
> Then keep the existing kfunc for putting the ruleset and enforcing it on
> a struct linux_binprm.
> 
> The BPF program would need to get a reference to a task struct
> of the program creating the rulesets with bpf_task_from_pid for
> instance. Then they could use the task_struct with another plain integer
> map to store FD numbers and then use the rulesets or store them in a map
> of __kptr objects for later usage.
> 
> Would this be more acceptable?
> > > Basically the pattern I need is userspace must create the file
> > > descriptor, BPF converts that FD into a refcounted kernel object, and
> > > even if userspace closes the FD BPF needs to hold a reference on the
> > > underlying ruleset structure.
> > >
> > > (In this patch this was accomplished through the map_ops)
> > >
> > > Let me know what you think Song. I do understand the benefit of having a
> > > __kptr instead, the refcounting is all there, and it would allow storing
> > > rulesets in multiple map types. (and one less map type to maintain).
> > 
> > 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).

> >
> 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?

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

> 
> > Thanks,
> > Song
> > 
> > > Mickaël, do you have any thoughts on this? I have v2 basically ready,
> > > although it uses the BPF_MAP_TYPE_LANDLOCK_RULESET it changes a lot on
> > > the Landlock side.
>