Re: Crash when attaching uretprobes to processes running in Docker

[Oleg Nesterov <oleg@redhat.com>]

On 01/15, Shmulik Ladkani wrote:
>
> IMO There are 2 problematic aspects with ff474a78cef5
> ("uprobe: Add uretprobe syscall to speed up return probe").
>
> The first, as Eyal mentioned, is the kernel regression: There are
> endless systems out there (iaas and paas) that have both
> telementry/instrumentation/tracing software (utilizing uprobes) and
> container environments (duch as docker) that enforce syscall
> restrictions on their workloads.
> These systems worked so far, and with kernels having ff474a78cef5 the
> workloads processes fault.

Again, I have to agree. The kernel should not break userspace.

But,

> The second, is the fact that ff474a78cef5 (which adds a new syscall
> invocation to the uretprobe trampoline) *exposes an internal kernel
> implementation* to the userspace system:

I disagree...

> There are millions of binaries/libraries out there that *never issue*
> the new syscall: they simply do not have that call in their
> instructions. Take for example hello-world.

And they should never use this syscall,

> However, once hello-world is traced (with software utilizing
> uprobes) hello-world *unknowingly* DO issue the new syscall, just
> because the kernel decided to implement its uretprobe trampoline using
> a new syscall - a mechanism that should be completely transparent and
> seamless to the user program.

IMO, sys_uretprobe() doesn't really differ from sys_sigreturn() in this
respect.

> This is totally unexpected, and to ask a system admin to "guess" whether
> hello-world is "going to issue the syscall despite the fact that
> such invocation does not exist in its own code at all" (and set seccomp
> permissions accordingly) is asking for the admin to know the exact
> *internal mechanisms* that the kernel use for implemeting the
> trampolines.

Well, man 2 uretprobe can help ;)

> we
> shoudn't add any instruction (such as a syscall) that isn't *completely
> transparent* to the userspace program.

We can't make it *completely transparent*, but it is easy to hide this
syscall from seccomp (and/or ptrace).

And this will fix the problem. But I don't feel this is the right solution.

Oleg.