[Bug 48291] Detroit: Become Human crashes on launch

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48291

--- Comment #37 from Paul Gofman <gofmanp at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.