Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.

A developer for Collabora, the open source consultancy firm that works with the likes of Valve has sent in a Linux Kernel patch aimed at helping Windows games run on Linux through Wine.

From what's noted in the patch titled "[PATCH RFC] seccomp: Implement syscall isolation based on memory areas", which was sent in for gathering comments (RFC = Request for comments), it seems more and more modern Windows applications / games are sidestepping the actual Windows API. The result? It breaks Wine compatibility as "it doesn't have a chance to intercept and emulate these syscalls before they are submitted to Linux".

What they're going for is an addition to the Linux Kernel, to enable them to filter and find out if the calls being done are from Wine itself or from the Windows application being run. They're proposing using the seccomp function, used usually for security purposes but this is in no way a security feature it's just how they're building the functionality for Wine while re-using what's available.

Their new way will avoid some harsh performance penalties too. An existing method would have added a 10% overhead but they say this averages around 1.5% which is a pretty dramatic difference, for something as performance critical as this. Reading over comments and how it's done, it's possible this can help anti-cheat systems too but as always, don't go getting hopes up over early work that's not complete or merged in yet.

You can see the patch here on the mailing list.

Article taken from GamingOnLinux.com.
Tags: Misc, Wine
29 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
30 comments
Page: «2/3»
  Go to:

CatKiller Jun 1, 2020
View PC info
  • Supporter Plus
Quoting: elmapul"sidestepping the actual Windows API. "
how is that even possible?

So, again, just as I understand it from reading bug reports about a game I'm vaguely interested in rather than from any in-depth knowledge, most programs will use some kind of library when they need to make some system calls to make something happen - libc or ntdll.dll, say - but it's also possible to just make system calls directly: libc and ntdll.dll need to be able to make their own system calls, too, of course. Windows and Linux both use the same mechanism for this (I think it's a processor instruction and registers?) but they use different numbers in the registers: that is, they'll both have a system call number 12, but there's no reason for it to necessarily do the same thing. In fact, which thing gets done by each number changes between versions of Windows, so the developers doing this need to check the version of Windows and use a look-up table to generate their numbers.
LordDaveTheKind Jun 1, 2020
View PC info
  • Supporter Plus
Quoting: BeamboomIsn't this to punch holes in the os layer and open up for instabilities, hardware conflicts and massive security issues?

Usually there is a Change and Release Management process which controls and avoids this kind of issues or criticalities. It's very unlikely that a patch is immediately released just as soon as it is implemented.
Nevertheless Jun 1, 2020
Quoting: CatKiller
Quoting: elmapul"sidestepping the actual Windows API. "
how is that even possible?

So, again, just as I understand it from reading bug reports about a game I'm vaguely interested in rather than from any in-depth knowledge, most programs will use some kind of library when they need to make some system calls to make something happen - libc or ntdll.dll, say - but it's also possible to just make system calls directly: libc and ntdll.dll need to be able to make their own system calls, too, of course. Windows and Linux both use the same mechanism for this (I think it's a processor instruction and registers?) but they use different numbers in the registers: that is, they'll both have a system call number 12, but there's no reason for it to necessarily do the same thing. In fact, which thing gets done by each number changes between versions of Windows, so the developers doing this need to check the version of Windows and use a look-up table to generate their numbers.

That makes sense now! I was confused why Windows syscalls would go through as Linux syscalls directly..
I guess some calls of those programs are tracable by the firejail program, which is able to log the syscalls it is configured to filter.
Koopacabras Jun 1, 2020
I will keep an eye on tk-glitch on github probably he/she ports it soon.
Koopacabras Jun 1, 2020
I made the experiment and the patch applies to 5.6 almost cleanly, not sure what I'm getting into. compiling now.
scaine Jun 1, 2020
View PC info
  • Contributing Editor
  • Mega Supporter
I'm a bit confused as to why they pushed this patch at all. If they only need to establish whether something is happening in Wine, or in Windows, can't they simply apply their patch to a locally-compiled kernel and test a few of the offending games/apps with that custom kernel loaded?

Presumably it's far wider-reaching than locally debugging a few system calls though. Perhaps this does lay a low-level foundation for future work, like anti-cheat, or just general stability or better compatibility.

I don't know much about this stuff though (which should be obvious from my rambling above). Always interesting to see what happens under the hood!
CatKiller Jun 1, 2020
View PC info
  • Supporter Plus
QuoteReading over comments and how it's done, it's possible this can help anti-cheat systems too but as always, don't go getting hopes up over early work that's not complete or merged in yet.

My reading of it was that they don't want to take an approach that will definitely break their anti-cheat work, rather than that this approach will specifically help.
CatKiller Jun 1, 2020
View PC info
  • Supporter Plus
Quoting: scaineI'm a bit confused as to why they pushed this patch at all. If they only need to establish whether something is happening in Wine, or in Windows, can't they simply apply their patch to a locally-compiled kernel and test a few of the offending games/apps with that custom kernel loaded?

They've already done that: that's how they have benchmarks on the relative performance of selectively trapping system calls. And while the Wine devs being able to play All The Games might be nice for them, I expect that they'd quite like other Wine users to be able to as well.

The issue is that Windows applications are using Windows system calls without going through Wine. Those system calls won't work, because Linux isn't Windows, and they can't be translated because they don't go through Wine.

They need a solution that will catch (self-modifying and obfuscated) code that doesn't go through Wine and somehow still make it work for all users, without breaking Wine for everything else. For that, it needs to go to the kernel - since that's where the system calls end up - and it needs some discussion to find the best approach, and it needs the kernel devs to agree that it's a good idea. Hence the Request For Comment.

I would say that the game developers have done something pretty manky, but this is the least-bad way of handling it if those games are to be made to be able to run.


Last edited by CatKiller on 1 June 2020 at 2:56 pm UTC
scaine Jun 1, 2020
View PC info
  • Contributing Editor
  • Mega Supporter
Super helpful, CatKiller. Now you mention the benchmarks, it's obvious that they've rolled their own prior to submitting a patch for wider adoption. Thanks for clearing that up.
razing32 Jun 1, 2020
Quoting: TheSHEEEPI read "the open source conspiracy firm"... :D

Join our global cabal on Github.
Merge our banking ploy into upstream.
Bug #34176 Free Speech will be patched in next release.
:D
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.