[PATCH 0/4] Update USER_SHARED_DATA timestamps more often.

[Rémi Bernon]

On 11/29/19 11:03 AM, Paul Gofman wrote:
> On 11/29/19 12:23, Rémi Bernon wrote:
>> This is a rewrite of the ntdll-User_Shared_Data staging patch series,
>> with a simpler approach that still solves the issue. Although it is less
>> correct in term of timestamp update than the original series, it should
>> also have less impact and may be more acceptable. We already update the
>> timestamps from time to time in ntoskrnl before accessing the memory,
>> and this adds another update after each sleep.
> 
> While this might allow the games to start, won't such approach break
> (some of) game mechanics or sync with servers? The games might be using
> this instead of GetTickCount(), having the time updated at some rare and
> irregular intervals looks scary.

AFAICS it's working fine although I didn't test it really deep to be honest.

> I thought that somewhat potentially better approach than that currently
> in Staging would be to map user shared area to wineserver and always
> create a single thread in server to update the shared area. That would
> be somewhat similar to what Windows does if wineserver stands for
> kernel. I also heard that sharing memory with server is considered a no
> go, but I could not find any discussion why is it so.
> 

Yes, that was one of the approaches discussed in the original thread [1]
and probably a more accurate way to do it. It has however some 
drawbacks, in addition to being much more complicated and probably 
having some unforeseen implications:

* Creating a thread in wineserver is probably not going to be OK, as it 
is single threaded and should stay as such whatever the purpose is.

* Regarding memory sharing, I understood from a WineConf discussion that 
sharing read-only memory from the server to applications would be OK 
generally speaking. But in this case, KUSER_SHARED_MEMORY contains some 
information about the emulated OS from an application perspective, and 
that can vary from on application to another. This would require sharing 
different memory regions depending on the application and updating all 
of them, complicating the whole thing. There are also some other fields 
currently written by applications and that would need to be updated by 
the server to keep the shared memory read-only.

* Then according to [1], updating the timestamps continuously could 
apparently break some copy-protection schemes (SecuROM for instance) 
that measures the time taken by some syscalls. As Wine is not exactly 
doing as Windows, the syscall timings could be larger and having the 
timestamps not increase in this particular case allows us to pass these 
checks.

[1] https://www.winehq.org/pipermail/wine-devel/2012-March/094788.html
-- 
Rémi Bernon <rbernon at codeweavers.com>