On Tue, 21 Jan 2025 14:38:09 -0800 Andrii Nakryiko andrii.nakryiko@gmail.com 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?
-- Steve