On Tue, Jan 21, 2025 at 2:46 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Tue, 21 Jan 2025 14:38:09 -0800 > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > You said yourself that sys_uretprobe is no different from rt_sigreturn > > and restart_syscall, so why would we rollback sys_uretprobe if we > > wouldn't rollback rt_sigreturn/restart_syscall? Given it's impossible, > > generally speaking, to know if userspace is blocking the syscall (and > > that can change dynamically and very frequently), any improvement or > > optimization that kernel would do with the help of special syscall is > > now prohibited, effectively. That doesn't seem wise to restrict the > > kernel development so much just because libseccomp blocks any unknown > > syscall by default. > > What happens if the system call is hit when there was no uprobe attached to > it? Perhaps it should segfault? That is, this system call is only used when > the kernel attaches it, if the kernel did not attach it, perhaps there's > some malicious code that is trying to use it for some CVE corner case. But > if it always crashes when added, the only thing the malicious code can do > by adding this system call is to crash the application. That shouldn't be a > problem, as if malicious code can add a system call, it can also change the > code to crash as well. > > Perhaps the security folks would feel better if there were other > protections against this system call when not used as expected? Isn't that the case already, or maybe I misunderstood what Jiri wrote [1]: > On Sun, Jan 19, 2025 at 2:44 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > that's correct, uretprobe syscall is installed by kernel to special user > memory map and it can be executed only from there and if process calls it > from another place it receives sigill Eyal. [1] https://lore.kernel.org/lkml/Z4zXlaEMPbiYYlQ8@krava/
