[PATCH v8 0/9] MR6: Avoid performance degradation due to vDSO unmapping (BZ#52313)

Kevin Puetz (@puetzk) wine at gitlab.winehq.org
Mon Jun 27 10:07:37 CDT 2022

Another interesting case in this same area is qemu-user emulation. As you say, right now wine-preloader just uses MAP_FIXED and removes anything in its way (potentially including the vdso of ASLR put it in the way).

When running under qemu-user CPU emulation, this can mean we not only remove the vdso from the process being launched (a performance degradation), but also clobber it out from under the qemu-user emulator hosting the wine-preloader process - which is in fact in the midst of a call to mmap that is *using* the vdso, so the emulator then segfaults before returning (intermittently, since ASLR doesn't always put the vdso in the way, but often enough I have seen it hit the in[0x7ffffe000000, +0x01ff0000 range](https://gitlab.winehq.org/wine/wine/-/blob/master/loader/preloader.c#L116)

I'm just remapping it won't fix that problem (having it move mid-call is going to be just as fatal as unmapping it), but it potentially makes it more tractable. qemu is already holding some separation/tagging of host vs guest, so maybe it could special case mremap to move it for us but retain it for its own purposes.


More information about the wine-devel mailing list