On 8/13/21 2:57 AM, Kevin Sheldrake wrote:
Hello
I have a requirement to catch a specific signal hitting a specific process and to send it a SIGSTOP before that signal arrives. This is so that the process can then be attached with ptrace(), but without the necessity of ptrace()ing the process continuously beforehand (due to performance and stability reasons). I thought this might be possible with an eBPF program attached to a tracepoint.
I attached a program to the signal/signal_deliver tracepoint and used bpf_send_signal() to send the SIGSTOP but it didn't stop the process. If I sent SIGTERM or SIGHUP instead it worked as expected, just not SIGSTOP or SIGTSTP.
Sending a SIGSTOP prior to another signal (eg SIGSEGV) works from userland - the process stops and the other signal is queued.
I'm guessing that the reason is that bpf_send_signal() adds the (non-state transitioning) signal to the process signal queue, ignoring SIGSTOP, SIGTSTP, SIGKILL, SIGCONT, but doesn't change the state of processes. Can anyone confirm if that is correct or if there's another possible reason that bpf_send_signal seems to fail to send a SIGSTOP? If so, is this documented anywhere? Is there another way to do this with eBPF?
Kernel has SIG_KERNEL_IGNORE_MASK like below
#define SIG_KERNEL_IGNORE_MASK (\
rt_sigmask(SIGCONT) | rt_sigmask(SIGCHLD) | \
rt_sigmask(SIGWINCH) | rt_sigmask(SIGURG) )
So SIGCONT will be ignored for bpf_send_signal() helper.
For other signals e.g., SIGSTOP/SIGKILL, there are some comments saying
special processing might be needed. But I think they may still get
delivered. If you use signal/signal_deliver when SIGSEGV is delivered,
is it already too late to do bpf_send_signal() SIGSTOP since that
will be processed after SIGSEGV? Note that SIGSEGV is already delivered?
Many thanks
Kev
--
Kevin Sheldrake
Microsoft Threat Intelligence Centre
