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] [day] [month] [year] [list]

Message-ID:
 <AM6PR03MB50808451138F84235B45190199042@AM6PR03MB5080.eurprd03.prod.outlook.com>
Date: Tue, 17 Dec 2024 14:11:47 +0000
From: Juntong Deng <juntong.deng@...look.com>
To: Christian Brauner <brauner@...nel.org>,
 Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: 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/17 12:30, Christian Brauner wrote:
> On Tue, Dec 10, 2024 at 10:58:52AM -0800, 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.
> 
> Hm? Was that directed at my question? I don't have the background to
> judge this and this whole api looks like a giant footgun so far for
> questionable purposes.
> 
> I have a hard time seeing parts of CRIU moved into bpf especially
> because all of the userspace stuff exists.
> 

All these kfuncs I want to add are not CRIB specific but generic.

Although these kfuncs are to be added because of CRIB, these kfuncs
are essentially to give BPF the ability to access process-related
information.

Obtaining process-related information is not a requirement specific to
checkpoint/restore scenarios, but is also required in other scenarios.

Access to process-related information is a generic ability that would
be useful for scenarios other than checkpoint/restore.

Therefore these generic kfuncs will be valuable to all BPF users
in the long run.

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