A New Kernel Patch Is Being Discussed That's Needed For Newer Windows Games On Wine

[horstderheld]

What happened to fsync patches? Are the close to being accepted upstream?

It's still in the making
https://gitlab.collabora.com/tonyk/l...futex-refactor

[Aryma]

Most people I know already do this. For example I use an "online cesspit" Jail to create effectively a soft "airgap" between my OS and the rest of the world. Other solutions are LXC, Docker or (if you don't need GPU or hardware devices) VMs like KVM or Bhyve.

For machines that really don't need to go online (i.e if you justifiably use cracked software with license compliance), then a physically disconnected machine is the best solution.

you need to disable all this patch and maybe we need to make some unsafe change to boost performance

[ryao]

Why are they doing that?

Denuvo DRM is known to do it. I am not aware of anything else that does. It is mentioned in the documentation for PROTON_USE_SECCOMP:

https://github.com/ValveSoftware/Proton/

It is only enabled for Doom Eternal and Resident Evil 3 right now:

https://steamdb.info/app/891390/

[ryao]

Some executable packers do this in attempt to thwart attempts to unpack protected executables.
Some anticheats do this in attempt to perform tasks in a way that it would be hard to detect/debug.

Which ones? I have only heard of Denuvo DRM doing it. Anticheat isn't said to do this.

[ryao]

Phoronix: A New Kernel Patch Is Being Discussed That's Needed For Newer Windows Games On Wine

Newer Windows games/applications are making use of system call instructions from the application code without resorting to the WinAPI and that is breaking Wine emulation support. A Linux kernel patch is now being worked on for addressing this issue in the form of system call isolation based on memory areas while having a smaller performance hit than alternatives...

http://www.phoronix.com/scan.php?pag...Isolate-Memory

Michael It would be nice if you told us which "Windows games/applications are making use of system call instructions from the application code without resorting to the WinAPI" and why. As far as I know, only games using Denuvo DRM are doing this. It is mentioned in the documentation for PROTON_USE_SECCOMP:

https://github.com/ValveSoftware/Proton/

It is only enabled for Doom Eternal and Resident Evil 3 right now:

https://steamdb.info/app/891390/

The performance benefit should only apply to people running these games on older CPUs. Some people who read the discussion linked by your article are speculating that this will improve anti-cheat compatibility, but this will not give us anything we don't already have. It is just a small tweak to reduce the overhead of PROTON_USE_SECCOMP. The only reason anti-cheat is discussed at all is because it prevents alternatives to a kernel patch from being used.

Also, it is fairly rare that changes to the syscall ABI are merged into the Linux kernel after the first proposed patch or at all. It is premature to talk about when this would be merged. It might never be merged. Quite frankly, it would be best if Denuvo DRM did syscalls through ntdll and friends just like everything else instead of forcing Wine to implement this workaround. The NT kernel syscall table is not a stable interface, so explicitly hard coding syscalls like this is likely to break compatibility with future versions of Windows.

[rene]

Why are they doing that?

performance and laziness? Same on Linux with Rust binaries, or even some other stuff, e.g. gnu lib used in many gnu projects, tar, gzip et al. rename2 and all. You will be surprised what you find on Linux if you look a bit closer, ... ;-) https://www.youtube.com/watch?v=6EI3n6ipqUc

[Dark-Show]

Why would any future company put up funds to port a game to Linux when we can bend the kernel to make Wine run their intentionally flawed code better?

The feature addition to the kernel however doesn't seem bad at all, so kudos to the developers making/testing solutions for an acceptable speed!

[Larry$ilverstein]

Whenever there's an article here about a technical subject, I always just click the link to the original source and read that instead. Reading Michael's bad paraphrasing of it gives me brain damage.

[tildearrow]

After this, WINE becomes an emulator (again).

[oiaohm]

After this, WINE becomes an emulator (again).

This still does not make wine a emulator.

https://en.wikipedia.org/wiki/Compatibility_layer

Turns out what Gabriel Krisman Bertazi of Collabora is up to for wine with SECCOMP_MEMMAP is very close to FreeBSD's Linux compatibility layer and other FreeBSD OS compatibility layers.

So this is still compatibility layer work. After SECCOMP_MEMMAP idea is in the Linux kernel this does open up a few interesting possibilities.

This feature does open up the possibility of full blown WSL 1 in reverse. As in Windows 10 userspace running on the Linux kernel.