https://bugs.winehq.org/show_bug.cgi?id=48291
--- Comment #37 from Paul Gofman gofmanp@gmail.com --- (In reply to David Torok from comment #36)
idea. I see you incremented the syscall numbers in the nt syscall thunks and subtracted accordingly before the dispatcher. My understanding is that this will not work in cases where the application looks up the NT build (from the PEB for instance) and uses a syscall number based on the build information.
Yes, my patch won't work in that case.
I've been thinking about ways to go about this, and thought we could rewrite the seccomp filter to trap only on virtual addresses outside of glibc. (see the attachment)
What are your thoughts, would that work well for us?
Please note the following:
- Linux programs and libraries are doing syscalls directly whenever they want often bypassing glibc wrappers. Some syscalls don't even have such wrappers. Wine does a number of syscalls directly, so do a lot of native libraries. So the address range from where you can get a native syscall is absolutely not limited by glibc code segments.
- glibc (and other libraries) can be loaded at different addresses, and you can't ever change seccomp filters: once set, they are inherited by the child processes and can't be removed or replaced, only new filters can be added. Maybe there is an exception for process having admin caps (CAP_SYS_ADMIN), but that's not something I would mess with in Wine.
So the generic solution in this direction would probably imply intercepting every syscall and doing some address checks in the handler, which can probably work somehow but is going to have a terrible performance impact.
So I suppose you can make an app specific patch which will work for RDR2 (e. g., by using specific syscall numbers in seccomp filter and the address range which is correct for RDR2), but I don't yet see any acceptable generic solution.