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

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.

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.

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

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.

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

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.

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

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.

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