https://bugs.winehq.org/show_bug.cgi?id=48291
--- Comment #44 from qsniyg qsniyg@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?