[PATCH 2/2 v2] ntdll: Track copy-on-write memory state on i386 and x86_64 architectures.
piotr.caban at gmail.com
Wed Feb 27 07:44:20 CST 2019
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:
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.
>>> * 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.
>> Do you remember any of the games that were affected? I'm expecting it
>> to still be a problem.
> Unfortunately I am not sure anymore which game showed the graphic
> issues, but I would suspect that even a simple OpenGL sample code to
> download a texture into WRITECOPY memory would be affected. There were
> at least two bug reports related to WRITECOPY regressions though:
> * https://bugs.winehq.org/show_bug.cgi?id=39349
> * https://bugs.winehq.org/show_bug.cgi?id=39350
> For the second one the app has probably changed in the meantime, but
> maybe the first one can still be used to reproduce one of the issues.
I've done some testing regarding it. The opengl calls I've tested are
not passing the memory to kernel. I've checked it only on following
functions: glGenTextures and glGetTexImage. I guess it may depend on the
driver or a better test needs to be written.
I've also looked on the 2 bugs you wrote about. In case of Talisman game
it works for me. I didn't check what fixed it or if I can reproduce the
problem with older wine. In case of Alone in the Dark there's a race in
old version of game. The patches are just making the race much more visible.
If it turns out that there's a game that passes copy-on-write memory to
opengl->kernel we will need to add e.g. IsBadWritePtr calls before the
buffer is passed to opengl. I don't know if we want to do it before we
find an application/graphics driver that depends on that.
More information about the wine-devel