linux-kernel - Re: per st_ops kfunc allow/deny mask. Was: [PATCH bpf-next v6 4/5] bpf: Make fs kfuncs available for SYSCALL program type

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: <Z4GA2dhj1PZWTvSv@slm.duckdns.org>
Date: Fri, 10 Jan 2025 10:19:37 -1000
From: Tejun Heo <tj@...nel.org>
To: Song Liu <song@...nel.org>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>,
	Juntong Deng <juntong.deng@...look.com>,
	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>,
	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,
	Christian Brauner <brauner@...nel.org>, bpf <bpf@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: per st_ops kfunc allow/deny mask. Was: [PATCH bpf-next v6 4/5]
 bpf: Make fs kfuncs available for SYSCALL program type

Hello,

On Thu, Jan 09, 2025 at 12:49:39PM -0800, Song Liu wrote:
...
> Shall we move some of these logics from verifier core to
> btf_kfunc_id_set.filter()? IIUC, this would avoid using extra
> KF_* bits. To make the filter functions more capable, we
> probably need to pass bpf_verifier_env into the filter() function.

FWIW, doing this through callbacks (maybe with predefined helpers and
conventions) seems like the better approach to me given that this policy is
closely tied to specific subsystem (sched_ext here). e.g. If sched_ext want
to introduce new kfunc groups or rules, the changes being contained within
sched_ext implementation would be nicer.

Thanks.

-- 
tejun