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

[phoronix]

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

Earlier this year we reported on Linux kernel work for better handling Windows games/apps that make system call instructions that bypass the Windows API. Directly making the system calls without going through the WinAPI has become an increasingly common occurrence for modern Windows games, likely as part of their Digital Rights Management schemes. Syscall User Dispatch is now the latest take on that effort...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Syscall-User-Dispatch

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

[tildearrow]

#RobloxOnLinux

Hopefully after this...

[jeisom]

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

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

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

[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

[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

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

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