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...
Oleg.