Linux Kernel patch being discussed to help Windows games run in Wine

I read "the open source conspiracy firm"... :D

The title is a bit weird. like "gets". Nothing is there yet, its just a patch that isn't accepted yet. Interesting stuff though.

The title is a bit weird. like "gets". Nothing is there yet, its just a patch that isn't accepted yet. Interesting stuff though.

To get something is to receive something, seems perfectly appropriate. It mentions clearly it's a patch (doesn't say merged or anything) and notes its 'RFC' directly in the title. A title is just a title, the key is as always the text that accompanies it.

Does anyone know of any current use cases for this patch? Which Windows applications/games skip WinAPI calls to do syscalls directly?

i think its more to do with all those anticheat and drm protection systems, rather than games itself

To get something is to receive something, seems perfectly appropriate. It mentions clearly it's a patch (doesn't say merged or anything) and notes its 'RFC' directly in the title. A title is just a title, the key is as always the text that accompanies it.

I'm not native english speaker, true. but wouldnt it be better to use "might get" ? :)

i know its request for comments but its not inside the kernel yet lol...


Last edited by Xpander on 1 June 2020 at 7:17 am UTC

"sidestepping the actual Windows API. "
how is that even possible?

To get something is to receive something, seems perfectly appropriate. It mentions clearly it's a patch (doesn't say merged or anything) and notes its 'RFC' directly in the title. A title is just a title, the key is as always the text that accompanies it.

I'm not native english speaker, true. but wouldnt it be better to use "might get" ? :)

i know its request for comments but its not inside the kernel yet lol...

It got the patch, it received it, it hasn't yet done anything with it. The title is factually correct. Splitting hairs at this point. As always, if you have issues it's better to use the correction report system. Edit: However, I have edited to ensure it's as clear as possible.


Last edited by Liam Dawe on 1 June 2020 at 7:47 am UTC

Isn't this to punch holes in the os layer and open up for instabilities, hardware conflicts and massive security issues?

Does anyone know of any current use cases for this patch? Which Windows applications/games skip WinAPI calls to do syscalls directly?

The two I read about a little while ago here were Detroit: Become Human and Red Dead Redemption 2. I saw reference to some other culprits elsewhere, too, but I can't remember which they were right now.

Would this bring some overhead to anything non winds/windows related ? :S:

Isn'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.

"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.

Isn'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.

"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'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!

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.

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.

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?

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

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.

I 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

"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.

Exactly this! on i386 you put the syscall number in the eax register and some other data in other registers depending on the syscall and then you raise the $80 interrupt. On x86_64 they implemented a pure syscall instruction on the CPU.

Here is an old "Hello World" example that calls the sys_write syscall (syscall 4) to write the "hello world" string to stdout and then it calls exit (syscall 1) to let the kernel terminate the "application" with a proper exit code.
 
.data
    s:
        .ascii "hello world\n"
        len = . - s
.text
    .global _start
    _start:

        movl $4, %eax   /* write system call number */
        movl $1, %ebx   /* stdout */
        movl $s, %ecx   /* the data to print */
        movl $len, %edx /* length of the buffer */
        int $0x80

        movl $1, %eax   /* exit system call number */
        movl $0, %ebx   /* exit status */
        int $0x80


Last edited by F.Ultra on 1 June 2020 at 11:53 pm UTC

I hear this may allow WSL in reverse, which would be quite funny running Windows in WSL under Linux and having access to DX12 without needing a virtual machine with pass-through, however that would be VERY far off and wishful thinking.. (surprised or not surprised MS haven't done it already)


Last edited by TheRiddick on 2 June 2020 at 3:47 am UTC