[PATCH 2/2 v2] ntdll: Track copy-on-write memory state on i386 and x86_64 architectures.
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>
> - 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(-)
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?
More information about the wine-devel