Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Flattr, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

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
31 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
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.
See more from me
31 comments
Page: «2/4»
  Go to:

CatKiller 1 Jun
Quoting: BeamboomIsn't this to punch holes in the os layer and open up for instabilities, hardware conflicts and massive security issues?

The opposite. It's so that when a Windows application blindly uses Windows system calls on Linux they can be bounced back to Wine to be interpreted properly rather than naïvely followed or dropped. The seccomp framework already exists for trapping system calls, this is just to handle things more sensibly for this use case so that only Windows system calls need processing and Wine system calls can function unmolested. As I understand it.
CatKiller 1 Jun
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.
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.
View PC info
  • Supporter
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.
I will keep an eye on tk-glitch on github probably he/she ports it soon.
I made the experiment and the patch applies to 5.6 almost cleanly, not sure what I'm getting into. compiling now.
scaine 1 Jun
View PC info
  • Contributing Editor
  • Supporter Plus
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 1 Jun
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 1 Jun
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 1 Jun
View PC info
  • Contributing Editor
  • Supporter Plus
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.
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just 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!

You need to Register and Login to comment, submit articles and more.


Or login with...