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

[Justin Suess <utilityemal77@gmail.com>]

On Thu, Apr 16, 2026 at 02:12:11PM -0700, Song Liu wrote:
> On Tue, Apr 7, 2026 at 1:02 PM Justin Suess <utilityemal77@gmail.com> wrote:
> >
> > Expose the new BPF_MAP_TYPE_LANDLOCK_RULESET via headers, allowing
> > programs to utilize the map.
> >
> > Signed-off-by: Justin Suess <utilityemal77@gmail.com>
> 
> I don't think we can introduce a new map type for this. Instead, we should use
> existing map with __kptr values.
>
> Thanks,
> Song

Thanks Song,

That was one initially considered approach.

I initially decided in favor of the dedicated map type in this RFC after
seeing the other FD maps for cgroups and sockets. 

The main complication is rulesets in Landlock are created as file
descriptors backed by a kernel object. In the intended model of this
series, creation of rulesets is is done in userspace to avoid
redefining the entire landlock ruleset creation API in BPF.

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?

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

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.

I appreciate the feedback from both of you.

Justin