From: Paul Gofman Subject: Re: [PATCH 0/4] Update USER_SHARED_DATA timestamps more often. Message-Id: <14bf0491-ad7b-8790-60bb-d200f9fbf92f@gmail.com> Date: Fri, 29 Nov 2019 13:59:39 +0300 In-Reply-To: References: <20191129092401.8943-1-rbernon@codeweavers.com> <7af9d490-4bd3-b1e4-9a83-9b64aba29382@gmail.com> 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?