[PATCH v2 bpf-next 2/5] bpf: Introduce bpf_cgroup_read_xattr to read xattr of cgroup's node
Song Liu
songliubraving at meta.com
Sat Jun 21 03:50:04 UTC 2025
> On Jun 20, 2025, at 7:44 PM, Tejun Heo <tj at kernel.org> wrote:
>
> On Thu, Jun 19, 2025 at 03:01:11PM -0700, Song Liu wrote:
>> BPF programs, such as LSM and sched_ext, would benefit from tags on
>> cgroups. One common practice to apply such tags is to set xattrs on
>> cgroupfs folders.
>>
>> Introduce kfunc bpf_cgroup_read_xattr, which allows reading cgroup's
>> xattr.
>>
>> Note that, we already have bpf_get_[file|dentry]_xattr. However, these
>> two APIs are not ideal for reading cgroupfs xattrs, because:
>>
>> 1) These two APIs only works in sleepable contexts;
>> 2) There is no kfunc that matches current cgroup to cgroupfs dentry.
>>
>> Signed-off-by: Song Liu <song at kernel.org>
> ...
>> +__bpf_kfunc int bpf_cgroup_read_xattr(struct cgroup *cgroup, const char *name__str,
>> + struct bpf_dynptr *value_p)
>> +{
>> + struct bpf_dynptr_kern *value_ptr = (struct bpf_dynptr_kern *)value_p;
>> + u32 value_len;
>> + void *value;
>> +
>> + /* Only allow reading "user.*" xattrs */
>> + if (strncmp(name__str, XATTR_USER_PREFIX, XATTR_USER_PREFIX_LEN))
>> + return -EPERM;
>
> Just out of curiosity, what security holes are there if we allow BPF
> programs to read other xattrs? Given how priviledged BPF programs already
> are, does this make meaningful difference?
There are some xatters that we shouldn’t read, for example, other
security.* xattrs (security.selinux etc.).
We can probably allow BPF LSM programs to read security.bpf.* xattrs,
on cgroup nodes, just like bpf_get_[file|dentry]_xattr. But that
requires some extra logic.
Thanks,
Song
More information about the Linux-security-module-archive
mailing list