> We cannot reliably detect presence of QEMU
When I said "it should at least refuse a MAP_FIXED mmap that would overwrite things the JIT is using", the "it" I had in mind was that qemu-user should do that, not wine-preloader. As you say, wine-preloader doesn't have a good way to know it's running inside qemu. qemu could see that executing this MAP_FIXED would trample on the host proces in ways that compromise the interpreter, and it could choose to make the mmap syscall return MAP_FAILED.
> I don't know if there is a significant portion of Wine user base that uses QEMU to run x86 apps on other architectures.
I'm actually doing the opposite, which has to be even more niche. We're using qemu-user and binfmt_misc to run unit tests of an aarch64 executable (built with wineg++) on our x86_64 CI server, as part of cross-compiling. This kind of usage has to be vanishingly rare (winelib seems quite rare period).
Sorry to have started a somewhat offtopic thread with my comment here. I don't directly think there's much for wine-preloader to do about this. I just stumbled on this merge request in the course of debugging my crash, and was in the same area, and made me think of more alternatives. I had forgotten that using mremap to move `[vdso]` out of the way might even be an option. The main connection is that if this MR makes wine ask to move the vdso out of the way (rather than just having MAP_FIXED clobber it), that seems like something qemu-user might be able to implement and carry on. Just clobbering it seems much harder to tolerate.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6#note_2890
Required by Cyberpunk 2077 for 4.0 audio setups (`PKEY_AudioEndpoint_PhysicalSpeakers` is `SPEAKER_FRONT_LEFT | SPEAKER_FRONT_RIGHT | SPEAKER_BACK_LEFT | SPEAKER_BACK_RIGHT`) as it then dereferences the device path property (`{b3f8fa53-0004-438e-9003-51a46e139bfc},2`) without checking if is is non-NULL.
The patches use `{1}.ROOT\MEDIA\%04u` which is used on Windows for virtual audio devices (e.g. the ones created Voicemeeter Banana).
--
v2: winealsa.drv: Set device path for all devices.
winepulse.drv: Set device path for all devices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/325
--
v2: user32: Merge rawinput.c into input.c.
win32u: Move raw input device list management from user32.
win32u: Move NtUserGetRegisteredRawInputDevices from user32.
win32u: Move NtUserRegisterRawInputDevices from user32.
https://gitlab.winehq.org/wine/wine/-/merge_requests/313
> at least that it should at least refuse a MAP_FIXED mmap that would overwrite things the JIT is using.
Unfortunately, there are a few problems in this approach of refusing to overwrite memory mappings used by the QEMU Linux user-mode emulator:
1. **Emulator detection**. We cannot reliably detect presence of QEMU in a way that is guaranteed to work in past and current *as well as* future QEMU versions. Any method of qemu-user detection would rely on the fact that the environment provided by QEMU is different in some way from a native one. As QEMU gets closer and closer to perfectly emulating the real thing, the discrepancies used to detect QEMU will become fewer and fewer, possibly rendering our detection method unusuable.
2. **Bug detection**. In the event that the bug is eventually fixed in a future QEMU version, it's not certain that there will be a way to detect this. For example, the SIGSEGV signal due to vDSO unmapping is not currently forwarded to the guest, so there's no way for the preloader to detect presence of the bug, or absence thereof.
I don't know if there is a significant portion of Wine user base that uses QEMU to run x86 apps on other architectures. If this is the case, though, we could implement a (possibly hacky) way to warn the user of such occasion, in a separate patch set.
> But changing from a strategy where wine wants to clobber it to one where wine just wants to move it might give qemu-user some better options. I haven't put enough thought into it yet to have a specific idea, just that this PR seemed like it would be helpful.
Now, here's the good news: with this patch set, you can elect to avoid unmapping or remapping the vDSO *entirely*. Simply specify the `WINEPRELOADREMAPVDSO=never` environment variable.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6#note_2875