[Bug 48291] Detroit: Become Human crashes on launch

WineHQ Bugzilla wine-bugs at winehq.org
Tue Dec 31 15:56:10 CST 2019


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

--- Comment #44 from qsniyg <qsniyg at mail.com> ---
After doing a little more thinking and investigation, here are my thoughts:

 * A seccomp-based solution could indeed work, if no linux syscalls are sent.
   * The implementation of ntdll would have to be moved to wineserver, shell32
would have to be partly rewritten to use windows functions, etc.
   * From what I've read, the overhead is pretty small. Although I haven't
tried this yet, in theory a big BPF tree (where apparently most of the
performance overhead currently lies) shouldn't be needed if all syscalls are
trapped.
 * Differences in syscall numbers could be handled through a LUT present in
both wineserver and userspace, based on the Windows version selected.
 * Since seccomp can be turned off in userspace, support for it cannot be
hardcoded through #ifdefs, it has to instead be able to detect support at
runtime.
 * Obviously IPC has to be supported as well, but the current solution will
have to be rewritten if duplication of code is to be avoided. For most cases,
this shouldn't be much of an issue, but how about cases where memory has to be
written (e.g. NtOpenFile returning a handle)? Would write_process_memory be a
valid option? It would be a pretty terrible option performance-wise (and
possibly compatibility-wise as well) if the ptrace path has to be used. The
alternative would be to write a custom struct for every syscall, which would
quite obviously be a chore.

Any thoughts on this?

-- 
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.



More information about the wine-bugs mailing list