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

[Paul Gofman]

On 11/29/19 13:40, Rémi Bernon wrote:
>
>> 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.

It is extremely hard to test. I've got SWTOR for testing purposes, but I
can't test this aspect really as you have to be a hardcore gamer to do
that. The impact might be some game characters ability working a bit
slower (which is critical for those playing the game), or maybe some
more apparent issue but revealing in group contents only. That sort of
problems would be very hard to debug.

>
>> 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.
>>
>
>
> * 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.
>
I am not sure I quite understand this argument. There are other ways how
copy-protection schemes can measure time. Do we want to effectively
reduce the update frequency for, e. g., GetTickCount() to workaround
this potential issue? Or even if some protection schemes are known to
depend on precise timing and use user shared data for that measurements,
is it an acceptable workaround to tweak update frequency to help that?
IMO the better solution would be to look first if the system calls in
question can be optimized.

I am not sure if it is a real problem. I. e., copy protectors can of
course measure the time for system calls, but if they are going to do
that with the accuracy enough to distinguish between Wine and Winodws
call times, that should be extremely fragile on Windows too, I doubt it
can work. I suppose the protectors should check that with threshold big
enough, it looks like anti debugging trick rather than a way to detect
API spoofing. I've read the comment about Safedisk. Is it broken in Wine
Staging now which does a sort of continuous update?