On Sun, Jan 19, 2025 at 01:40:22PM +0100, Oleg Nesterov wrote:
On 01/18, Kees Cook wrote:
On Thu, Jan 16, 2025 at 04:55:39PM -0800, Eyal Birger wrote:
Since uretprobe is a "kernel implementation detail" system call which is not used by userspace application code directly, it is impractical and there's very little point in forcing all userspace applications to explicitly allow it in order to avoid crashing tracked processes.
How is this any different from sigreturn, rt_sigreturn, or restart_syscall? These are all handled explicitly by userspace filters already, and I don't see why uretprobe should be any different.
The only difference is that sys_uretprobe() is new and existing setups doesn't know about it. Suppose you have
int func(void) { return 123; }
int main(void) { seccomp(SECCOMP_SET_MODE_STRICT, 0,0); for (;;) func(); }
and it runs with func() uretprobed.
If you install the new kernel, this application will crash immediately.
I understand your objections, but what do you think we can do instead? I don't think a new "try_to_speedup_uretprobes_at_your_own_risk" sysctl makes sense, it will be almost never enabled...
This seems like a uretprobes design problem. If it's going to use syscalls, it must take things like seccomp into account. SECCOMP_SET_MODE_STRICT will also crash in the face of syscall_restart...