linux-kernel - Re: [PATCH bpf-next 1/2] bpf: implement bpf_send_signal

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: <CAADnVQKXY5E11gpng=0P_YFLJZh+nmiJDLOrtv2hftvxinukFQ@mail.gmail.com>
Date: Wed, 24 Jul 2024 16:23:02 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Puranjay Mohan <puranjay@...nel.org>
Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>, 
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, 
	Jiri Olsa <jolsa@...nel.org>, Matt Bobrowski <mattbobrowski@...gle.com>, 
	Steven Rostedt <rostedt@...dmis.org>, Masami Hiramatsu <mhiramat@...nel.org>, 
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Puranjay Mohan <puranjay12@...il.com>, 
	Abhishek Chauhan <quic_abchauha@...cinc.com>, bpf <bpf@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, 
	linux-trace-kernel <linux-trace-kernel@...r.kernel.org>
Subject: Re: [PATCH bpf-next 1/2] bpf: implement bpf_send_signal_pid/tgid() helpers

On Wed, Jul 24, 2024 at 4:40 AM Puranjay Mohan <puranjay@...nel.org> wrote:
>
> Implement bpf_send_signal_pid and bpf_send_signal_tgid helpers which are
> similar to bpf_send_signal_thread and bpf_send_signal helpers
> respectively but can be used to send signals to other threads and
> processes.

Thanks for working on this!
But it needs more homework.

>  #define ___BPF_FUNC_MAPPER(FN, ctx...)                 \
>         FN(unspec, 0, ##ctx)                            \
> @@ -6006,6 +6041,8 @@ union bpf_attr {
>         FN(user_ringbuf_drain, 209, ##ctx)              \
>         FN(cgrp_storage_get, 210, ##ctx)                \
>         FN(cgrp_storage_delete, 211, ##ctx)             \
> +       FN(send_signal_pid, 212, ##ctx)         \
> +       FN(send_signal_tgid, 213, ##ctx)                \

We stopped adding helpers long ago.
They need to be kfuncs.

>         /* */
>
>  /* backwards-compatibility macros for users of __BPF_FUNC_MAPPER that don't
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index cd098846e251..f1e58122600d 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -839,21 +839,30 @@ static void do_bpf_send_signal(struct irq_work *entry)
>         put_task_struct(work->task);
>  }
>
> -static int bpf_send_signal_common(u32 sig, enum pid_type type)
> +static int bpf_send_signal_common(u32 sig, enum pid_type type, u32 pid)
>  {
>         struct send_signal_irq_work *work = NULL;
> +       struct task_struct *tsk;
> +
> +       if (pid) {
> +               tsk = find_task_by_vpid(pid);

by vpid ?

tracing bpf prog will have "random" current and "random" pidns.

Should it be find_get_task vs find_task too ?

Should kfunc take 'task' parameter instead
received from bpf_task_from_pid() ?

two kfuncs for pid/tgid is overkill. Combine into one?

> +               if (!tsk)
> +                       return -ESRCH;
> +       } else {
> +               tsk = current;
> +       }

pw-bot: cr