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.
