Re: Crash when attaching uretprobes to processes running in Docker

On Tue, Jan 14, 2025 at 10:22:20AM +0100, Jiri Olsa wrote:

On Sat, Jan 11, 2025 at 07:40:15PM +0100, Jiri Olsa wrote:

quoted

On Sat, Jan 11, 2025 at 02:25:37AM +1100, Aleksa Sarai wrote:

quoted

On 2025-01-10, Eyal Birger [off-list ref] wrote:

quoted

Hi,

When attaching uretprobes to processes running inside docker, the attached
process is segfaulted when encountering the retprobe. The offending commit
is:

ff474a78cef5 ("uprobe: Add uretprobe syscall to speed up return probe")

To my understanding, the reason is that now that uretprobe is a system call,
the default seccomp filters in docker block it as they only allow a specific
set of known syscalls.

FWIW, the default seccomp profile of Docker _should_ return -ENOSYS for
uretprobe (runc has a bunch of ugly logic to try to guarantee this if
Docker hasn't updated their profile to include it). Though I guess that
isn't sufficient for the magic that uretprobe(2) does...

quoted

This behavior can be reproduced by the below bash script, which works before
this commit.

Reported-by: Rafael Buchbinder <redacted>

hi,
nice ;-) thanks for the report, the problem seems to be that uretprobe syscall
is blocked and uretprobe trampoline does not expect that

I think we could add code to the uretprobe trampoline to detect this and
execute standard int3 as fallback to process uretprobe, I'm checking on that

hack below seems to fix the issue, it's using rbx to signal that uretprobe
syscall got executed, if not, trampoline does int3 and executes uretprobe
handler in the old way

unfortunately now the uretprobe trampoline size crosses the xol slot limit so
will need to come up with some generic/arch code solution for that, code below
is neglecting that for now

Can't you detect the filter earlier and simply not install the
trampoline?