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

[Sebastian Lackner]

Am Mi., 27. Feb. 2019 um 14:44 Uhr schrieb Piotr Caban <piotr.caban at gmail.com>:
>
> Hi Sebastian,
>
> On 2/22/19 8:24 PM, Sebastian Lackner wrote:
> > When check_write_access() is called everything should be fine, but it
> > doesn't look like it is used everywhere. What about all the NtQuery*()
> > functions that pass through user-provided pointers? See for example
> > NtQueryInformationAtom or RtlQueryAtomInAtomTable - both directly pass
> > an untrusted pointer to wine_server_set_reply() and both use
> > wine_server_call() instead of any of the locked variants. Also, there
> > still seems to be at least one plain read() call in advapi32:
> >
> > https://github.com/wine-staging/wine-staging/blob/master/patches/ntdll-WRITECOPY/0002-advapi-Trigger-write-watches-before-passing-userdata.patch
> In all of these cases it will behave in the same way as if memory with
> write watch is passed. I guess that the idea was to fix it when we find
> an application that depends on that. In case of server calls it's easy
> to debug the problem. If it's preferred to change this calls before
> adding copy-on-write code I can start with that.

What I consider the main difference here is that write watches are
only rarely used (only very few apps come to my mind), but write-copy
protection is the default for many sections in PE applications - see
map_image() in ntdll/virtual.c. In my opinion, there is a high chance
that this change causes regressions (in particular, when there are
still so many wineserver calls that don't handle write watches /
write-copy protection), but my intention is not to block your changes.
I only wanted to make you aware of the possible issues we experienced
back then.

Best regards,
Sebastian