Messages in this thread | | | Date | Wed, 3 Apr 2024 15:56:51 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCHv2 1/3] uprobe: Add uretprobe syscall to speed up return probe |
| |
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.
| |