Linux Syscall User Dispatch Close To Mainline For Better Handling Windows Games

[Ironmask]

Anyway my 3c: so gamers publishers are bypass win32 security settings by calling Windows kernel directly, right (with silent Microsoft permission of course)?

WinAPI has nothing to do with security. Microsoft does not suggest using the Native API, that's why WinAPI exists. You can use Native API and other kernel facilities to do work, but you're risking it breaking if they ever change the Native API which has no promises of stability or backwards compatibility, which is why MS does not suggest targeting it. That's the whole reason WinAPI exists. Wine takes advantage of WinAPI's existence as a mere wrapper for a native OS API by just writing those APIs to work on Linux/macOS.

What (malicious AAA) games actually do to bypass the security of the OS is to install a kernel-mode driver, which would let anyone do anything on any OS and there's not really a good way to prevent that without just crippling your OS. Windows NT does require drivers to be cryptographically signed by an authorized entity before being loaded outside of a special OS dev/testing mode, but, you can get anything signed with enough money. Of course anything that comes with a kernel-mode driver is going to get a ton of pushback by the playerbase, as seen when Fallout 76 tried it.

[ssokolow]

Remember local anti-cheat systems also have to regularly update to detect newly made cheats so dealing with MS syscall changes is also a minor problem compared to all the other work required.

...and Microsoft dropped support for SafeDisc in 2015, partly because its kernel driver was a shoddy source of exploits.

[oiaohm]

Ugh... Complicated... I would like to say that I know what it is about but in fact - I do not

Anyway my 3c: so gamers publishers are bypass win32 security settings by calling Windows kernel directly, right (with silent Microsoft permission of course)?

In fact it not with Microsoft permission going direct syscall. Kernel mode driver is allowed.. Some game developers don't care either like they might only have the rights for the music or some other content in their game for like 12 months after 12 months the game is going to disappear anyhow so long term support is not important.

Remember local anti-cheat systems also have to regularly update to detect newly made cheats so dealing with MS syscall changes is also a minor problem compared to all the other work required.

Wine is horrible when it comes to security emulation because it basically does not. Wine says to applications you have XYZ security right now while basically implementing none of it.

[Danniello]

Ugh... Complicated... I would like to say that I know what it is about but in fact - I do not

Anyway my 3c: so gamers publishers are bypass win32 security settings by calling Windows kernel directly, right (with silent Microsoft permission of course)?

And now Linux kernel will could emulate this, right? If yes - probably gamer publishers will not be happy abut this, but anyway - Linux is 0% (+/- 1%) of their target group so I hope that they ignore it

[pal666]

Could this lead to faster file system interception without crossing kernel boundary 2 additional times compared to FUSE?

it does cross kernel boundary 2 additional times

[xen0n]

I wonder if this could be used by Firefox or Chrome to make any exploit more difficult?

I think any syscall sandboxing feasible in a browser context is already implemented, by means of seccomp. The mail mentioned that too, listing seccomp as an approach to the problem and why it wouldn't work.

[oiaohm]

Could this lead to faster file system interception without crossing kernel boundary 2 additional times compared to FUSE?

Looking forward to seeing how this evolves from a user space file system point of view.

Really no. Trapping the syscall requires crossing the kernel boundary. So the application syscals this is context switch to kernel space then the trap in the kernel space context switches back to userspace to handle the trapped syscall then this context switch to kernel space with answer then this gets passed to application. So 4 context switches same as not optimised fuse.

Fuse has the file system caches of the kernel to optimise out some requests in kernel space so making particular requests not go through fuse at all that you lose if you directly trap the syscalls.

https://events19.linuxfoundation.org/wp-content/uploads/2017/11/When-eBPF-Meets-FUSE-Improving-Performance-of-User-File-Systems-Ashish-Bijlani-Georgia-Tech.pdf

Fuse also has the above these days being a eBPF extension that allows particular operational logic to be performed fully in kernel space and those case there are no context switch overhead difference between a native file system call and fuse usage.

So system call trapping at this stage is going to consume equal or more context switches than old fuse before eBPF support for file system stuff as well. Really a lot of cases due to how many operations skip fuse completely due to the file system caches trapping the syscalls you lose this optimisation.

[jeisom]

I wonder if this could be used by Firefox or Chrome to make any exploit more difficult?

[tildearrow]

#RobloxOnLinux

Hopefully after this...

[hackworks]

Could this lead to faster file system interception without crossing kernel boundary 2 additional times compared to FUSE?

Looking forward to seeing how this evolves from a user space file system point of view.