I leave this to you and Masami, but... On 04/03, Jiri Olsa wrote: > > On Wed, Apr 03, 2024 at 10:07:08AM +0900, Masami Hiramatsu wrote: > > > > This is interesting approach. But I doubt we need to add additional > > syscall just for this purpose. Can't we use another syscall or ioctl? > > so the plan is to optimize entry uprobe in a similar way and given > the syscall is not a scarce resource I wanted to add another syscall > for that one as well > > tbh I'm not sure sure which syscall or ioctl to reuse for this, it's > possible to do that, the trampoline will just have to save one or > more additional registers, but adding new syscall seems cleaner to me Agreed. > > Also, we should run syzkaller on this syscall. And if uretprobe is > > right, I'll check on syzkaller I don't understand this concern... > > set in the user function, what happen if the user function directly > > calls this syscall? (maybe it consumes shadow stack?) > > the process should receive SIGILL if there's no pending uretprobe for > the current task, Yes, > or it will trigger uretprobe if there's one pending ... and corrupt the caller. So what? > but we could limit the syscall to be executed just from the trampoline, > that should prevent all the user space use cases, I'll do that in next > version and add more tests for that Yes, we can... well, ignoring the race with mremap() from another thread. But why should we care? Userspace should not call sys_uretprobe(). Likewise, it should not call sys_restart_syscall(). Likewise, it should not jump to xol_area. Of course, userspace (especially syzkaller) _can_ do this. So what? I think the only thing we need to ensure is that the "malicious" task which calls sys_uretprobe() can only harm itself, nothing more. No? Oleg.
