@Sil_el_mot or publish it and hope it helps others.
There seems to be quite some demand.
Doesn't need to be open source or free software, you could publish it under whatever license and/or conditions you would like.
There appears to be demand, maybe you could serve that demand.

View this comment - View article - View full comments

@tpau they don't actually whitelist keyboards.
They blacklist drivers.
It just happens that some keyboards only work through vulnerable drivers.

View this comment - View article - View full comments

@1xok I assure you they won't let you run on "any shady Windows machine".
I tend to aggressively debloat Windows to keep it running on ancient hardware(part of my job) and gaming ability is one of the first things of consumer value you lose(full telemetry, ads and bloat are the first victims, but those you don't actually want).
Also many anti-cheat systems nowadays require TPM2.0 and although essentially all hardware, since 2008 supports it, activating it in BIOS is often required. Valorant even excludes itself from systems with old keyboards.

View this comment - View article - View full comments

@Mohandevir Many anti-cheat vendors offer Linux compatibility nowadays, but there're often reasons not to use this product/feature.
VAC is the most obvious solution.
EAC and BattleEye work too.
Denuvo can be considered an anti-cheat provider that works on Linux.
You also have that anti-cheat solution whose name I always forget that only works on Steam Deck.
Fairplay is an interesting story. It's certainly not an internally developed solution. [External Link] It's one of the more extreme interpretations of server side anti-cheat. By doing most to all of the gaming at the server side it's easy to check for cheating.

Interesting thing I found:

Spoiler, click me

The FACEIT league actually has its own anti-cheat system, but if that one worked on Linux I would be pretty surprised.

View this comment - View article - View full comments

@CIAPA Do the xinput_calibrator and or xinput count.
xinput_calibrator is an x.org frontend for xinput, but straightly assumes you want your mouse to point up and do nothing fancy.
xinput is a pretty intuitive cli tool for managing this.

View this comment - View article - View full comments

@phil995511 I couldn't find commercial cheating software, so you appear to be right about that part.
I did find open source cheating software. [External Link]
Here an opensource cheat for old versions of half-life. [External Link] and I know that several Windows cracks are also Linux compatible.
@BlackBloodRum might have more insight in the commercial side though.

View this comment - View article - View full comments

@kmturley Linux does something similair/better [External Link].
The problem isn't and has never been Linux features.
Android and TeslaOS are Linux distros with a high focus on security and deeply trusted by games.
RHEL is deeply trusted by production software.
Most to all their features are integrated directly into the Linux kernel you use.

The problem is trust: the games don't trust it, because you could've modified the kernel to lie to them and the users don't trust it, because they've no easy way of checking this is truly what is happening.

So, either one of the parties has to gain trust or the source of trust for the vendors has to be moved outside the kernel, since I'm a programmer and not a social sciences student I propose the second.

Edit:
Places where this trust can be moved to: the development environment(homeomorphic encryption), external servers(game streaming) or hardware modules(TPM)

View this comment - View article - View full comments

@Eike, because than the other gamers will come and visit your house when you cheat.
I prefer Kernel anti-cheat personally.
Also permabans can be more perma.

View this comment - View article - View full comments

@Purple Library Guy
On an AMD machine this actually makes sense.
See the primary problem with your solution is that it's still hard to confirm that you run what you think you're running, but AMD's competitor to SGX actually works with mini kernels in vms.
The real question is. Wouldn't it be easier and just as good/bad to dual boot? Maye its cheaper, Windows is expensive.

Edit:
Correction it would be easier on an AMD machine this feature I just referenced does require exactly 0 reboots.

View this comment - View article - View full comments

@Uso, @Shotm7 and many others who suggest custom kernels as the solution.
Custom kernels are the problem, because people can legally and practically make their own kernel, make it return whatever they want and install it on their own device.
Anti-cheat makers, which are people who are defending against the owner of the device their software is running on don't trust the kernel to help defend against its master and on Windows Microsoft at least attempts to claim that title on Linux a principled stance has been taken to not claim that title.
Yes even signed kernels are treated as suspicious UEFI level cheating already exists.

Feature wise Linux wins all the rounds in anti-cheat.
Acceptable KASLR, tainted kernels, great hardware security modules integration, etc.
This just doesn't matter, because one could've and probably someone has made a kernel that showed all the signs of having these features, but didn't actually help.

If you ask me the technical solution isn't in the Kernel at all.
It's in the things the anti-cheat developer does trust: the development tools and the trusted execution environments.
To express this belief I hereby release EASLR(Executable Adress Space Layout Randomization) under the gplv2.1 [External Link].

Edit:
Yes, I value this freedom flowing from this principled stance too and the lack of monopolistic power originating from it.
As such EASLR doesn't stop anyone from modifying anything on their computer.
It hampers undetectable mass distribution of this capability on the specific programs we're trying to protect.

View this comment - View article - View full comments