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

[Piotr Caban]

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.

>>> * 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.

Thanks,
Piotr