linux-kernel - Re: [PATCH bpf-next v5 4/5] bpf: Make fs kfuncs available for SYSCALL and TRACING program types

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <DB7PR03MB508153EF2FECDC66FC5325BF99382@DB7PR03MB5081.eurprd03.prod.outlook.com>
Date: Fri, 13 Dec 2024 18:51:35 +0000
From: Juntong Deng <juntong.deng@...look.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Christian Brauner <brauner@...nel.org>,
 Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 John Fastabend <john.fastabend@...il.com>,
 Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau
 <martin.lau@...ux.dev>, Eddy Z <eddyz87@...il.com>,
 Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
 KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>,
 Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
 Kumar Kartikeya Dwivedi <memxor@...il.com>, snorcht@...il.com,
 bpf <bpf@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
 Linux-Fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH bpf-next v5 4/5] bpf: Make fs kfuncs available for SYSCALL
 and TRACING program types

On 2024/12/12 00:53, Alexei Starovoitov wrote:
> On Wed, Dec 11, 2024 at 1:29 PM Juntong Deng <juntong.deng@...look.com> wrote:
>>
>> On 2024/12/10 18:58, Alexei Starovoitov wrote:
>>> On Tue, Dec 10, 2024 at 6:43 AM Christian Brauner <brauner@...nel.org> wrote:
>>>>
>>>> On Tue, Dec 10, 2024 at 02:03:53PM +0000, Juntong Deng wrote:
>>>>> Currently fs kfuncs are only available for LSM program type, but fs
>>>>> kfuncs are generic and useful for scenarios other than LSM.
>>>>>
>>>>> This patch makes fs kfuncs available for SYSCALL and TRACING
>>>>> program types.
>>>>
>>>> I would like a detailed explanation from the maintainers what it means
>>>> to make this available to SYSCALL program types, please.
>>>
>>> Sigh.
>>> This is obviously not safe from tracing progs.
>>>
>>>   From BPF_PROG_TYPE_SYSCALL these kfuncs should be safe to use,
>>> since those progs are not attached to anything.
>>> Such progs can only be executed via sys_bpf syscall prog_run command.
>>> They're sleepable, preemptable, faultable, in task ctx.
>>>
>>> But I'm not sure what's the value of enabling these kfuncs for
>>> BPF_PROG_TYPE_SYSCALL.
>>
>> Thanks for your reply.
>>
>> Song said here that we need some of these kfuncs to be available for
>> tracing functions [0].
>>
>> If Song saw this email, could you please join the discussion?
>>
>> [0]:
>> https://lore.kernel.org/bpf/CAPhsuW6ud21v2xz8iSXf=CiDL+R_zpQ+p8isSTMTw=EiJQtRSw@mail.gmail.com/
>>
>> For BPF_PROG_TYPE_SYSCALL, I think BPF_PROG_TYPE_SYSCALL has now
>> exceeded its original designed purpose and has become a more general
>> program type.
>>
>> Currently BPF_PROG_TYPE_SYSCALL is widely used in HID drivers, and there
>> are some use cases in sched-ext (CRIB is also a use case, although still
>> in infancy).
> 
> hid switched to use struct_ops prog type.
> I believe syscall prog type in hid is a legacy code.
> Those still present might be leftovers for older kernels.
> 
> sched-ext is struct_ops only. No syscall progs there.
> 

I saw some on Github [0], sorry, yes they are not in the Linux tree.

[0]: 
https://github.com/search?q=repo%3Asched-ext%2Fscx%20SEC(%22syscall%22)&type=code

>> As BPF_PROG_TYPE_SYSCALL becomes more general, it would be valuable to
>> make more kfuncs available for BPF_PROG_TYPE_SYSCALL.
> 
> Maybe. I still don't understand how it helps CRIB goal.

For CRIB goals, the program type is not important. What is important is
that CRIB bpf programs are able to call the required kfuncs, and that
CRIB ebpf programs can be executed from userspace.

In our previous discussion, the conclusion was that we do not need a
separate CRIB program type [1].

BPF_PROG_TYPE_SYSCALL can be executed from userspace via prog_run, which
fits the CRIB use case of calling the ebpf program from userspace to get
process information.

So BPF_PROG_TYPE_SYSCALL becomes an option.

[1]: 
https://lore.kernel.org/bpf/etzm4h5qm2jhgi6d4pevooy2sebrvgb3lsa67ym4x7zbh5bgnj@feoli4hj22so/

In fs/bpf_fs_kfuncs.c, CRIB currently needs bpf_fget_task (dump files
opened by the process), bpf_put_file, and bpf_get_task_exe_file.

So I would like these kfuncs to be available for BPF_PROG_TYPE_SYSCALL.

bpf_get_dentry_xattr, bpf_get_file_xattr, and bpf_path_d_path have
nothing to do with CRIB, but they are all in bpf_fs_kfunc_set_ids.

Should we make bpf_fs_kfunc_set_ids available to BPF_PROG_TYPE_SYSCALL
as a whole? Or create a separate set? Maybe we can discuss.