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-WRITE...
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:
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.
Thanks, Piotr