[PATCH 2/2 v2] ntdll: Track copy-on-write memory state on i386 and x86_64 architectures.

Sebastian Lackner sebastian at fds-team.de
Fri Feb 22 10:08:58 CST 2019

Am Fr., 22. Feb. 2019 um 16:48 Uhr schrieb Piotr Caban <piotr at codeweavers.com>:
> Based on patch by Michael Müller.
> Signed-off-by: Piotr Caban <piotr at codeweavers.com>
> ---
> v2:
>   - added credit for Michael
>   dlls/kernel32/tests/virtual.c | 12 +++-----
>   dlls/ntdll/ntdll_misc.h       |  1 +
>   dlls/ntdll/signal_arm.c       |  8 +++++
>   dlls/ntdll/signal_arm64.c     |  8 +++++
>   dlls/ntdll/signal_i386.c      | 51 +++++++++++++++++++++++++++++++
>   dlls/ntdll/signal_powerpc.c   |  8 +++++
>   dlls/ntdll/signal_x86_64.c    | 45 +++++++++++++++++++++++++++
>   dlls/ntdll/thread.c           |  1 +
>   dlls/ntdll/virtual.c          | 57 +++++++++++++++++++++++++++--------
>   9 files changed, 170 insertions(+), 21 deletions(-)

Hello Piotr,

I didn't fully review your patch, but note that we had this feature
basically disabled in Staging (hidden behind an environment variable)
because it caused a lot of trouble.

The main issues were:

* Syscalls will just fail with EFAULT when they encounter a page
without sufficient protections. It will not trigger a signal! This
means it would be necessary to add code to handle EFAULT whenever
there is a chance that the memory passed by the user might have the
copy-on-write flag. In particular, this affects all wineserver calls
which directly write to user-provided buffers. See:


* For third party libraries you always have to ensure that faults are
handled before passing any pointer. This even affects the OpenGL libs:
They pass memory addresses directly to the kernel, and thus don't
trigger the write patches. We noticed weird rendering errors in
several games with the copy-on-write logic enabled.

Just to make sure, can those issues still happen in your version of the patch?

Best regards,

More information about the wine-devel mailing list