Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.

Tim Sweeney has a point about Fortnite EAC support

By - | Views: 63,423

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.
54 Likes
About the author -
author picture
I'm a Linux gamer from Finland. I like reading, long walks on the beach, dying repeatedly in roguelikes and ripping and tearing in FPS games. I also sometimes write code and sometimes that includes hobbyist game development.
See more from me
The comments on this article are closed.
148 comments
Page: «10/15»
  Go to:

F.Ultra Feb 10, 2022
View PC info
  • Supporter
Quoting: oberjaegerI do believe a solution could be found, if it is really wanted. I believe creating a kind of trusted bubble should be technical possible, and it should be no problem for a program to check if the kernel (or the bubble) has be corrupted.

To do that you require a completely locked down system where a single entity controls the private keys and use something similar to TPM to make sure that the entire software stack is what this single entity expects it to be.

But just to show how hard this is to actually pull off we can just point to the available cheats for consoles, and consoles by their very nature try very very hard to create such a bubble (not to specifically avoid cheats but to be the single controlling entity of the entire machine, aka to make sure that you only buy games from them and not run something of your own on it).
F.Ultra Feb 10, 2022
View PC info
  • Supporter
Quoting: RCLTo all people saying that not trusting the client or moving the game to the cloud is the solution - you seem to ignore the existence of network latency.

I think that you are misunderstanding what people mean. People are not saying that putting a game like Fortnite in the cloud would be a good solution for the gameplay itself, no what they mean is that putting it in the cloud is the only solution if you really want to stop the cheaters. As long as you rely on the client being honest you are going to loose this battle, there is not a single thing that you can do to make it work this way.

Now there can be made an argument that, well we don't need to be 100% free from the cheaters so if client side makes it just 90% safe then that might be a good compromise. Well the problem is that the real world numbers are probably more like 5% then 90%, going by peoples experience there are vast amount of cheaters out there for these highly competitive games.

And I've seen this first hand, back in my Wii U days I became quite good at the online part of Watchdogs, but then suddenly one day almost every single opponent I tried to hack would instantly find me long before I had even travelled to where they where in the game (which is impossible without cheats). That was the last time I ever played a game online.
EagleDelta Feb 10, 2022
Really the only solution for these developers to get what they want is Cloud gaming. Even on Windows right now some AC is digging in so deep that certain devices get blocked by the AC from being used on Windows (I.E. the driver is blocked by the AC) and in some rarer cases, features critical to a Developer's use of Windows (or even just a power user) has to be disabled to play a game (Search FaceIT and HyperV).

This isn't unique to Linux, the anti-cheat developers want your PC to be more like a Console because they want that sweet PC revenue, but don't want to give up the control Consoles give them.
eridanired123 Feb 10, 2022
Quoting: RCLTo all people saying that not trusting the client or moving the game to the cloud is the solution - you seem to ignore the existence of network latency.

False.

Gforcenow latency is pretty fine on LOL, GW2 and BDO which are the competitive games I've played. I can assume other gaming clouds to have similar results. And I'm not a resident of a first world country by any means.


Last edited by eridanired123 on 10 February 2022 at 11:22 pm UTC
Shmerl Feb 11, 2022
Quoting: Purple Library GuyDid I say something about feeling bad for them?
I want lots of Steam Deck sales.

I don't think sales at the cost of perpetuating poor security is a good idea. That's my take on it at least. Those who sell stuff that causes damage becasue there is demand are doing a very questionable thing.

If information security sounds too abstract, you can use some more tangible example. Let's take transport. Imagine someone will say it's good to sell more but risky vehicles, because someone hyped that it's "cool" and clueless masses want that.

I'd argue those who sell that will bear responsibility for the harm that will cause.


Last edited by Shmerl on 11 February 2022 at 2:32 am UTC
BlackBloodRum Feb 11, 2022
View PC info
  • Supporter Plus
Another reason to think of it as a bad thing and why we should reject it:

One game which requires a kernel module? You can ignore that game (and therefore the module).. But the game is still popular so other companies see it mostly works, so another game studio tries it.

Again, only a small percentage of users reject it. Thus more studios see it's okay to do it. So again, more games start adding it.

Next thing you know, you'll find every new game requires its own kernel module to be installed, and if you want to play games you must always give game studios full access over your computer.

Then it'll move over to other industries like music and movies to stop piracy.. so you'll need a module from them too.

Can this really be justified? Honestly.. imo no. At this point, you basically don't have the right to control your computer anymore if using their software.

Sadly, you always get a small group of people who can see it's a bad thing and try to stop it.. but you also always get a large group of people who don't understand why it's bad (no one explained it properly) or defeatists who simply say "well you can't stop it anyway" and allow it to happen.

Just look at the EARN IT act, or the many spying laws in the UK to see how that works.


Last edited by BlackBloodRum on 11 February 2022 at 2:35 am UTC
Koopacabras Feb 11, 2022
I mean how much control over the kernel Easy Anti Cheat needs, back in the days we had ndiswrapper which was open source but loaded a firmware, it was a windows driver loaded into the linux kernel basically... why not that instead of kernel module?
It doesn't gets easier than that, just create your damned EAC firmare and Linux devs will take care of the rest...
maybe Valve has to create a generic anti cheat kernel module, open source, that set the basic rules, and then let companies load their own firmware within the module.
Sweeney is like talking as like perfect AntiCheat Software existed, seems like the same as Denuvo, with enough determination any of this things can be hacked.
They should try to implement server side anticheat instead imho.
I'm quite sure that a open source implementation of anti cheat it's totally possible as long it doesn't abuse the system with ring 0 priviliges.
If linux gaming with the steam decks starts to pick up, surely something will be done.
In my book Sweeney will be another guy that will be remembered in history books as an asshat like Steve Ballmer that talked nonsense crap about Linux 15 years ago.
Truth is that we don't need you Sweeney, eventually Wine will get all the AntiCheat software to work regardless, maybe a little late, sure, but don't feel so special Sweeney.
Koopacabras Feb 11, 2022
what I don't get about this whole article... is how does the heck Fortnite for Android works? and I think there's enough android "distros" out there, that have plenty of different kernels. Did google let them run a proprietary module on their kernels?
I'm sorry if my question is too stupid I simply ignore this.
EagleDelta Feb 11, 2022
Quoting: Koopacabraswhat I don't get about this whole article... is how does the heck Fortnite for Android works? and I think there's enough android "distros" out there, that have plenty of different kernels. Did google let them run a proprietary module on their kernels?
I'm sorry if my question is too stupid I simply ignore this.

They will detect if you are running with root, or running with an unlocked bootloader, or try to see if you're running a custom ROM and block those things.
RCL Feb 11, 2022
EAC and other anticheats don't try to be watertight. It is as of now impossible on PC. Even consoles do not try to be watertight. The platform owners set a goal that cracking a console should cost the user an equivalent of buying 10 AAA games (watch this video for the details: https://youtu.be/U7VwtOrwceo), and then it is a sufficient deterrent.

I.e. it is understood that nothing will stop a _very_ determined individual. But if you raise the threshold so high that 99[.99]% of people give up trying, the goal is achieved.

PC is slowly moving towards this as an architecture, but it will always remain more open than a dedicated hardware.

Doing everything server-side is an unacceptable latency (as of now). Yes, the tech is also improving in that area, but for example if you wanted to prevent aimhacks, you'd need to make the server authoritative over the mouse movement - and good bye the feeling of smoothness when playing at 60 or more FPS.

So the critique and ideas voiced here are often indeed underway, but in the meantime existing anti-cheat mechanisms need to work with what we have - PCs that cannot be fully secured, games that cannot relegate everything to the server. And they do make a difference, very noticeable one for the players.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.