https://bugs.winehq.org/show_bug.cgi?id=48291
--- Comment #50 from qsniyg qsniyg@mail.com --- (In reply to Zebediah Figura from comment #49)
Okay, now I'm even more confused. As I described, this approach means we trap on every syscall, which isn't performant.
This is why I wrote that it would be an experiment to see the performance impact. However seccomp - unlike ptrace - does not stop the process when it traps a syscall (it will pause the thread calling it obviously, but that's to be expected). Seccomp's performance overhead per-syscall is also apparently quite minimal according to various sources, so I'm not sure if the performance impact would be very significant. There's actually also the possibility that it will be faster, as it doesn't encode/decode anything, neither does it use sockets.
...so what do we do about the syscalls that the application makes, if we're not trapping them?
If seccomp is disabled, I'm not sure if there's anything that can be done (other than ptrace, which is probably out of the question for performance reasons).
That being said, I've been investigating this further, and I don't think it's possible for the moment, because of a few syscalls that must be performed in the client application, such as memory allocation. One possible solution would be to have a ptrace-like extension for seccomp, where the response would include a syscall to execute on the tracee.