One of the big topics of discourse in the Linux gaming sphere recently has been Tim Sweeney's statement on porting Fortnite to the Steam Deck, where Sweeney argues that Linux would be too difficult of a target and the market not big enough to warrant the amount of resources it would take to bring all of Fortnite on the platform.
The central crux of the issue, from Sweeney's point of view, is that making Easy Anti-Cheat, with all of its capabilities, run on Steam Deck (and thus on Linux) would be extremely difficult. He argues, that for a game of Fortnite's size this would open the flood-gates to significant influx of cheaters.
There have been some responses to this from the Linux side, with some accusing Sweeney of exaggerating the difficulty of such a port or that his statements are conflicting, because he simultaneously believes the Linux market is too small to be worthwhile but also would provide a way for too many cheaters. I will address some of these aspects a bit later, but for now let's focus on the main technical blocker, which is Easy Anti-Cheat.
Easy Anti-Cheat, or EAC, is an anti-cheat solution which apparently comes in a few configurations. We know that it can be run in a configuration where it is compatible with Linux/Proton apparently with just a relatively simple toggle. However, this mode of operation is seemingly a comparatively high-trust configuration, where only part of the anti-tampering protections of EAC are active. This may prevent some cheats but fail to detect others, which can be perfectly reasonable for games, where the number of cheaters and potential cheaters are fairly low or other systems complement the anti-cheat solution. There are plenty of games, even some popular free-to-play titles, which at best have this level of anti-tamper protection and they don't seem to have a major cheating epidemic, so clearly in many cases this should be enough. We also don't know the scope of cheats that are detected by EAC in this configuration, so this system by itself may already be fairly comprehensive.
EAC also contains a kernel-level component, which on Windows is installed as a kernel driver. This allows EAC code to run at a very privileged level and inspect essentially any and all parts of the system in order to detect tampering. This provides a very broad level of monitoring, which is also harder to bypass. Based on Sweeney's comments, this is the mode of operation used by Fortnite. It is also a mode of operation that is technically incompatible with the Linux way of doing things.
In Linux, the standard way of delivering drivers is by submitting the driver into the kernel source code tree, which naturally requires that the driver be open source. Most drivers are delivered this way, where the driver gets tightly integrated into the kernel and the drivers are updated when the kernel is updated. There are of course some notable exceptions to this rule, the largest of which is the Nvidia driver. The Nvidia driver is instead loaded as a separate kernel module, which allows Nvidia to keep its source code hidden, but also allows the driver to be updated separately from the kernel. So, EAC could surely use this approach as well, right?
The separate kernel module approach comes with some gotchas. Firstly, the kernel is licensed under GPLv2 and many of the parts in the kernel require the calling code to also be GPLv2 due to the "viral" quality of GPL. This means that, legally speaking, if Epic were to turn EAC into a kernel module and started poking around the kernel APIs, they'd have to open source EAC or they'd be in a legal grey area. The first approach is obviously not possible due to their business model and the second is at least not a great look.
Another problem with separate kernel modules is that the Linux kernel only guarantees a stable user-facing interface. This means that almost anything is allowed to change inside the kernel as long as user-level programs continue functioning. This is also the reason why sometimes the Nvidia driver stops working when you upgrade from one kernel to the next without installing an up-to-date Nvidia driver as well. So, when Sweeney is complaining about the multitude of kernel configurations, he's not wrong. EAC would need to maintain a compatibility shim similar to that of the Nvidia driver, which ensures that the EAC kernel module functions with each kernel version out there. Every time the kernel updates, an EAC engineer would need to go over the changes and update the compatibility shim every time there's a breaking change while still maintaining the compatibility with older kernel versions.
Theoretically you could overcome this problem somewhat by only targeting the Steam Deck and its SteamOS. This would give you a single kernel version to target, although Epic would need to negotiate with Valve in order to ensure their driver is somehow shipped with SteamOS.
But the problems don't end there. Since Linux is a fully open platform, there is technically nothing that would prevent a determined cheater from cracking open the Linux source code and making some tactical changes to how the kernel behaves, building the kernel and then making the EAC kernel module blind. On Windows the EAC developers can assume that the black box that is the NT kernel is at least somewhat difficult to modify by users. This means that in kernel-space they can assume some level of security through obscurity. On Linux this assumption does not hold. The only way for Epic to overcome that problem would be to negotiate with Valve to lock down the Steam Deck, which Valve has already decided not to do.
So, from EAC's point of view the Linux platform can never be quite fully trusted, which is entirely fair, because from the user's point of view EAC can never be quite fully trusted.
But surely Epic could still somehow bring Fortnite to the Steam Deck, right? Surely they could ship a version of Fortnite without the kernel-level component, right?
That they could, which brings us to the points about market share and the viability of cheating. Sweeney argues that the Linux market is too small, which initially sounds a bit odd because he then goes on to worry about the large numbers of cheaters. The kicker is here that the small Linux market doesn't necessarily guarantee a low number of cheaters. If it turns out that certain cheats are possible via a Linux version of Fortnite, this will attract some cheaters to use the platform in order to bypass EAC. It won't be all of the cheaters, many casual cheaters would likely not bother to learn Linux in order to cheat in a video game, but there is no doubt a group of cheaters that would take the opportunity. So, Fortnite would see some increase in cheating, but without good data it is hard to determine how big that effect would be. However, considering the popularity and free-to-play nature of Fortnite, it could very well be that it would be an attractive enough target for cheaters to attack even if there is a slightly higher initial investment. Cheat makers on the other hand would probably eventually find ways to package their offerings in an accessible enough format, like boot-to-cheat USBs or pre-configured VM images.
Some solutions to this problem have been proposed. For example, they could silo Steam Deck/Linux users in such a way that they will never come into contact with the rest of the playerbase. This would contain cheating, but it's also a hard-handed measure that would likely be unpopular. It would also require some amount of work to accomplish and I think it's fair for Epic to discount options that would cause extra work on them.
So, what's the solution to the problem? Here's the thing: I don't think there is one. My personal opinion is that client-side anti-cheat is fundamentally limited and taking it into the kernel is a bandaid that comes with excessive cost and is simply incompatible with the Linux platform. So, as long as Epic insists on maintaining its current anti-cheat approach with Fortnite, I just don't think there's going to be Fortnite on Linux.
And that doesn't mean Tim Sweeney is wrong or lying about the difficulties of adapting that approach to Linux. It just means that a new or different approach is needed in the future.
Article taken from GamingOnLinux.com.
This indeed brings the question on future multiplayer games targetting Linux.
We need efficient models/processes/methods to prevent cheating by design in multiplayer games to come.
What amazes me is that many don't even think about the fact that Valve itself runs a pretty extensive AC system. VAC works very well in conjunction with a pay barrier. Fortnite lacks this pay barrier.
Many of today's cheats are also based on external image recognition that directly controls the input devices. For the kernel, this appears as a normal mouse, keyboard or controller. Nothing at all is installed on the PC or console that could be recognised. EAC is also snake oil. Fortnite is full of cheaters.
I could cheat as much as I wanted in CSGO. Only VACNet/Overwatch would get me at some point and I would have to keep paying money for new accounts. Before that, the trust system would already match me against other cheaters.
In comparison, EAC is a pile of arcane bullshit that now maybe barely works.
Last edited by 1xok on 9 February 2022 at 9:10 pm UTC
No wonder why nobody flipped the switch yet.
Elden Ring has recently announced it will use EAC as well... So there is pretty no hope it will work on Proton :/
While I honestly don't give a shxxx of Fortnite, I would have loved to play Elden Ring on the Steam Deck.
with everything saifd about the Linux kernel and different versions and hackabiltiy etc. yet it plays on Android, even on 3rd party Roms and Kernels just fine.Theoretically yes. I think the overriding issues are that Android is a market big enough to take the risk and generally speaking tech illiterate enough that the likelihood of someone installing a custom ROM to cheat in Fortnite is so unlikely, that it doesn't register as a realistic risk.
Would that not have the same exact issues and from a significantly larger player base than desktop Linux users?
Right now I can take my phone, root it, throw on a different Rom, and even use a different customized kernel, and still play Fortnite. This has been done, proven, viewed, tested, and seems to be OK.
Think you've just shot your own argument in the foot there.
It's a given than 99% of cheaters have no clue on how to write a cheat let alone a kernel driver on windows, Which also would be true for Linux side or the deck.
So the entire premise fails as a result of that theory.
The simple fat is that he has no intention of allowing fortnite on the deck. Am sure if the deck had been produced by say Samsung it wouldn't have been an issue.
Think you've just shot your own argument in the foot there.Different argument, production and consumption operate under different rules entirely. For a cheat to be popular, all you need is that 1% to make a few and a distribution method to get them in the hands of would-be cheaters. My argument on Android side is that there isn't an easy distribution method, because replacing a phone ROM is a more complex procedure than installing essentially an application or even booting up a VM image or flashing a USB stick.
It's a given than 99% of cheaters have no clue on how to write a cheat let alone a kernel driver on windows, Which also would be true for Linux side or the deck.
So the entire premise fails as a result of that theory.
And even in the case of some people booting a cheater ROM on their phone, Epic would be willing to make that deal simply due to the size of the market.
Clearly easy anticheat is a very dangerous backdoor in the already subpar protection of windows.
What I don't get is how something like easy anticheat can get it's stuff into the windows kernel. That means that microsoft is supporting them?
Mountain Man Feb 9, 2022
Last edited by Mountain Man on 9 February 2022 at 9:49 pm UTC
with everything saifd about the Linux kernel and different versions and hackabiltiy etc. yet it plays on Android, even on 3rd party Roms and Kernels just fine.Theoretically yes. I think the overriding issues are that Android is a market big enough to take the risk and generally speaking tech illiterate enough that the likelihood of someone installing a custom ROM to cheat in Fortnite is so unlikely, that it doesn't register as a realistic risk.
Would that not have the same exact issues and from a significantly larger player base than desktop Linux users?
Right now I can take my phone, root it, throw on a different Rom, and even use a different customized kernel, and still play Fortnite. This has been done, proven, viewed, tested, and seems to be OK.
From everything I've read, they do try to prevent custom ROMs from playing the game. Even when those Custom ROMs do get it running, they have to have root disabled, play services must be installed, and safetynet must pass its checks, among other things.
So, it still requires a fairly locked down Android OS to run the game.
So in other words, they manage to implement some safeguards even when run under the evil Linux kernel :-)
So, what's the solution to the problem? Here's the thing: I don't think there is one.The solution was created long time and it's called signed kernel module.
I don't think that not having access to the source code of the kernel helps much with security. Security through obscurity is bad. The source code of the kernel can leak, or Microsoft servers can get hacked, or people can try to make sense of the binary, although "illegal", I doubt that the cheaters are concerned about it.
I guess the pirates just don't have the skill or the patience to modify the kernel, closed source or not…
Sure it would require more effort, but still, security through obscurity is a poor way to secure a system.
Also, you have to release under the GPLv2 only the modified kernel code, not the module itself.
Different argument, production and consumption operate under different rules entirely. For a cheat to be popular, all you need is that 1% to make a few and a distribution method to get them in the hands of would-be cheaters.
Which is what happens on all platforms!
My argument on Android side is that there isn't an easy distribution method
Oh come on, just about everyone knows it takes seconds to look for an apk and install it for andriod. And lets be honest, a cheater is going to know how to do basic things on any platform and there is no need for custom roms to be used. On IOS I would agree with your point.
EAC also contains a kernel-level component, which on Windows is installed as a kernel driver. This allows EAC code to run at a very privileged level and inspect essentially any and all parts of the system in order to detect tampering. This provides a very broad level of monitoring, which is also harder to bypass.
Yet cheaters today bypass this every single day. What they do is that they write their own kernel drivers that simply mess with the stuff that EAC looks at in order to make everything look as if the cheat wasn't there. The hard part here for the cheat-devs are not the Windows stuff, it's determining what the EAC driver is looking at, when it does it and what it expects to see.
Since the EAC driver is closed source this is a little bit harder than if they would have had access to the source code, but they have tools to make this work with the closed binary. In the end this is only a cat and mouse type of game where the cheat-devs releases version 1 of their stuff, EAC tries to detect how they do that and makes a new version of EAC to circumvent this at which time the cheat-devs have to do the same and they release v2 and it goes on and on in an infinite loop. The Operating system does not come into play here so this is independent on Windows vs Linux.
The main problem is as you write yourself that it's extremely hard for a closed sourced driver to keep up with a constant changing Linux kernel since Linux changes the internal API and ABI if something better is possible while Windows keeps constant API/ABI interface for kernel drivers. None of this is due to being open- or closed source, it's just down to the philosophical difference between the two systems.
Also note that this very problem would affect the cheaters as well, which is why IMHO cheating this way would be actually harder on Linux and the cheats would simply stop working much faster here than on Windows where the API/ABI would not change.
But the problems don't end there. Since Linux is a fully open platform, there is technically nothing that would prevent a determined cheater from cracking open the Linux source code and making some tactical changes to how the kernel behaves, building the kernel and then making the EAC kernel module blind. On Windows the EAC developers can assume that the black box that is the NT kernel is at least somewhat difficult to modify by users. This means that in kernel-space they can assume some level of security through obscurity. On Linux this assumption does not hold.
Rewriting the entire Linux Kernel to make the EAC module blind (which of course would trigger EAC that something is happening) while making everything else work just fine is IMHO a much harder undertaking than what is presenting here. It's a theoretical attack vector that most likely will never happen in practice. Besides the massive undertaking of this fork, they would also have to carry on support for new kernel releases to support new hardware so the maintenance burden would way outweigh the support burden that the cheat-devs have to do today so I fail to see how this would be a chosen path for any of them. They would also have to have a way for their users to put external kernels into the Steam Deck of which we right now don't know how easy that would be.
IMHO one could just as easily argue that the cheaters could invest into ReactOS to make it Windows 11 compatible and then have cheaters replace the Windows kernel with the ReactOS one with added "make EAC blind" patches.
Last edited by F.Ultra on 9 February 2022 at 10:23 pm UTC
Oh come on, just about everyone knows it takes seconds to look for an apk and install it for andriod. And lets be honest, a cheater is going to know how to do basic things on any platform and there is no need for custom roms to be used. On IOS I would agree with your point.Android is so sandboxed that you aren't going to be installing Fortnite cheats with an APK off the Internet, except if you somehow found a hacked Fortnite client that is still somehow respected by the Fortnite servers. Otherwise you'd at the very least need root in order to poke at the running processes from outside the official binary and although it can be done, it is not common knowledge. You are also still not acknowledging the other side of the issue, which is that the Android market is so unbelievably big that it's a great deal even if you have some cheaters. You just cannot equate the Android and Linux/Deck markets and assume the same risk calculus applies everywhere.
To ensure that a program hasn't been modified is impossible to get totally right, it's always a fight between the pirates and the security experts.
I don't think that not having access to the source code of the kernel helps much with security. Security through obscurity is bad. The source code of the kernel can leak, or Microsoft servers can get hacked, or people can try to make sense of the binary, although "illegal", I doubt that the cheaters are concerned about it.
I guess the pirates just don't have the skill or the patience to modify the kernel, closed source or not…
Sure it would require more effort, but still, security through obscurity is a poor way to secure a system.
Also, you have to release under the GPLv2 only the modified kernel code, not the module itself.
And the entire source code for both Windows 10 and Windows XP have leaked over the years so they are out there for any one interested enough to find.
Oh come on, just about everyone knows it takes seconds to look for an apk and install it for andriod. And lets be honest, a cheater is going to know how to do basic things on any platform and there is no need for custom roms to be used. On IOS I would agree with your point.Android is so sandboxed that you aren't going to be installing Fortnite cheats with an APK off the Internet, except if you somehow found a hacked Fortnite client that is still somehow respected by the Fortnite servers. Otherwise you'd at the very least need root in order to poke at the running processes from outside the official binary and although it can be done, it is not common knowledge. You are also still not acknowledging the other side of the issue, which is that the Android market is so unbelievably big that it's a great deal even if you have some cheaters. You just cannot equate the Android and Linux/Deck markets and assume the same risk calculus applies everywhere.
Wouldn't the much greater marker on Android make it that much more susceptible to cheaters and thus much more profitable for a cheat-dev to write an exploit for?
A quick google shows that cheats for Fortnite on Android is just a simple APK that you can sideload, what those do is apparently to replace the Fortnite launcher with one patched to load the cheats.
slaapliedje Feb 9, 2022
Kernel level "anti-cheats" are spyware garbage that mask companies unwillingness to invest in server side AI solutions for the problem (which are expensive obviously). It's much easier to require users to install spyware and monitor their system instead. Tim Sweeny and his kernel anti-cheats can get lost.Agreed. I honestly want to know if any game actually prompted for a root password on Linux, how many people would just immediately uninstall it. I know I do. No game should require root. Hell, GUI applications barely have a reason to have root.
Anyone who cares about security of their systems shouldn't come anywhere close to stuff like that.
Windows 10 gets away with this because the majority of software needs to be installed in Program Files(whatever), so prompts for Yay/Nay. So people ignore just giving up access...
Wouldn't the much greater marker on Android make it that much more susceptible to cheaters and thus much more profitable for a cheat-dev to write an exploit for?It might be, if there is demand for exploits and cheats. Hell, maybe there even is a Fortnite cheating problem on Android. But clearly Epic's calculus says that it's worth the money to compromise. Otherwise they'd pull the plug on Android, right?
A quick google shows that cheats for Fortnite on Android is just a simple APK that you can sideload, what those do is apparently to replace the Fortnite launcher with one patched to load the cheats.
My whole argument hinges on the simple fact that Epic does not want to compromise with the Linux/Deck market. If Epic was willing to compromise we could hand-wave literally all the technical hurdles, because if Epic really really wanted the game to be available on the Deck then they could obviously make that happen. They aren't interested in compromising and at least claim to want to run their full-blown EAC on Linux and my argument is that it's never going to be a viable approach.
Getting Fortnite to run on Linux is not what I am claiming to be impossible here. It's the set of demands Epic is putting on Fortnite running on Linux that I am claiming as at least highly impractical.
pleasereadthemanual Feb 9, 2022
As I see it, in very brief form, Samsai is saying
--doing a kernel module for EAC would be problematic because of the GPL
Thing is, as I understand it there are lots of binary blobs in the kernel in nearly all distros. I don't see this as a realistic issue.
A sub-point he made on this would be that it would look bad. This is ridiculous. I don't think Epic can look much worse in the eyes of the open source community than they already do, and I don't think doing a kernel module for EAC on the Steam Deck would make them look worse than, well, sabotaging the Steam Deck by keeping Fortnite off it.
--"On Windows . . . they can assume some level of security through obscurity."
As far as I can tell, cheating on Fortnite is an industry. Samsai seems to be describing a level of security by obscurity that would stop casual cheaters from writing their own cheat functionality from scratch, thus only allowing elite, highly skilled cheaters to do so. Except casual cheaters don't write their own cheat functionality, they do a quick google and buy a cheat program from the thriving industry writing them. The thriving industry is clearly not deterred by this mild level of security by obscurity; we know this because you can do a quick google and find their programs for sale. The scenario and issue Samsai describes is not just marginal, I would wager it literally does not exist at all. The only kind of person who would imagine it might would be, well, a non-cheating Linux user used to controlling their system who is also some kind of skilled programmer and so imagines that if they wanted to cheat on games, they might do it from scratch themselves. In real life, I don't think anyone in the world does it that way, and certainly no low-skilled casual cheater does, and so this security by obscurity that would deter this sort of cheater is entirely hypothetical.
Come to that, arguably, Linux has significantly more security by obscurity just because most employees in this thriving industry are very likely to be Windows programmers and not familiar with Linux. Not that it matters.
I think Samsai has come to his position by making an error at a more social level. He looks at Tim Sweeney saying X, and at many people saying hostile things about Tim Sweeney saying X, and considers that many of those hostile things are not well informed, and that after all Sweeney is an important man at the top of a large company. Plus, frankly, honourable people tend to just imagine certain basic levels of conduct in others. So his instincts tell him that he shouldn't react in a knee-jerk fashion like the hostile people, and that he should give some benefit of the doubt to Sweeney because come on, surely an important person in a public role wouldn't just be lying through their teeth. And so, he starts thinking about ways in which Sweeney's claims could be true, and comes up with some.
The problem is that Tim Sweeney is in fact very likely to be lying through his teeth, and indeed we can verify that because, within the same sequence of tweets under discussion, he clearly did lie through his teeth. Specifically, he said
Epic would be happy to put Fortnite on Steam. We wouldn't be happy to give Steam 20-30% of its revenue for the privilege.Now, Fortnite is free to play. I presume it makes lots of money from micro-transactions within the game. But Steam, unlike Apple that I believe Epic had a lawsuit with over this very issue, does not collect a percentage from such in-game transactions, and there is no possible way Sweeney does not perfectly well know this. So, if Fortnite were available on Steam, Epic would be paying Valve 20-30% of zero for the privilege.
So he's lying. Flat out, no ifs, ands or buts, it's a barefaced lie. From what I've heard of Sweeney's character, this is far from unusual for him. This does not prove that the stuff about EAC is lies, but it does show that it is unwise to give him the benefit of the doubt, or start from the idea that he might be right and look for ways to square that possibility with the rest of reality.
Seeing the efforts these people take to continue hacking you would assume they would take the opportunity and have an easy one on Linux. Interestingly enough I've heard no complains about cheaters abusing the Linux version of CS:GO. It is secured by a custom version of VAC, a private blogger analyzed it (https://lwss.github.io/State-Of-Vac-linux-2020/) and apparantly it does nothing other than monitoring /mem /proc /cmdline and the gamedir for suspicious files/processes/signatures and therefor should be easily bypassed with a custom kernel.
I think Linux is generally too unattractive to gamers, but the Steam Deck might bring a lot of them to it, and if it is profitable there will be cheat providers.
Patreon
PayPal
See more from me