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

Date:   Sun, 31 Jan 2021 12:14:02 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>, andrii@...nel.org,
        Martin KaFai Lau <kafai@...com>,
        David Miller <davem@...emloft.net>, kpsingh@...nel.org,
        John Fastabend <john.fastabend@...il.com>,
        netdev <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: extended bpf_send_signal_thread with argument

Hi,

I would like to send a signal from a bpf program invoked from a
perf_event. There is:

// kernel/trace/bpf_trace.c
BPF_CALL_1(bpf_send_signal_thread, u32, sig)

which is nice, but it does not allow me to pass any arguments.
I can use a bpf map indexed by pid to "pass" some additional info, but
it's messy and slow (and may cause some synchronization issues, I am
not sure yet).

Signals allow to pass additional arguments, it would be nice to expose
this to bpf programs as well. Any objections? Do you see any potential
issues with this? On the implementation side it seems to be almost
trivial to add something like this:

BPF_CALL_2(bpf_send_signal_thread_ex, u32, sig, uintptr_t sival)

However, siginfo_t is way larger and allows to pass a whole lot of
info, and the latest user-space APIs pidfd_send_signal just directly
accepts siginfo_t (and rt_tgsigqueueinfo as well). But I am not sure
how to expose it according to bpf rules. Could we do something like
(pass whatever you want, it's your business)?

BPF_CALL_2(bpf_send_signal_thread_ex, u32, sig, char siginfo[sizeof(siginfo_t)])

Does it make sense? If yes, what would be the best way to expose this?

Thanks