Tim Sweeney has a point about Fortnite EAC support

By - | Views: 40,981

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.
55 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
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
148 comments
Page: «11/15»
  Go to:

Koopacabras 11 Feb
Quoting: EagleDelta
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.
that probably can be easily bypassed with MagisK. There's actually nothing preventing me from patching my own kernel and building a custom rom image, with a patched kernel to run on my android device (and running fortnite with full customized kernel). I don't see that being any different from Linux distros, It might be a little more complicated to setup and compile, than lets say installing xanmod or liquorix kernel, but it's totally doable.

Anyway... I think that clearly, they are not relying on a kernel module on android, so all this about GPL incompatibilities with EAC and the kernel is all nonsense.

Besides let's not make it about Linux only tho... I think that probably Apple wouldn't allow a kernel module for anticheat on their kernel, for the obvious security reasons.

In my opinion...this is not about Linux only, Google banned fortnite from their play store, Apple did likewise. So maybe the problem is Epic here. Maybe their app wants unlimited trust, their app needs more permissions and priviliges, than anything out there, so it's getting banned, for security reasons.
And Sweeney is so blinded with greed, that cannot see the Elephant in the room here.


Last edited by Koopacabras on 11 February 2022 at 10:08 am UTC
spaceback 11 Feb
Well... there is always Nvidia NOW service ... works like a charm for deep EAC games, Fortnite included... and I reckon that somebody will devise a way to run Nvidia NOW on the Deck sooner or later...
EagleDelta 11 Feb
Quoting: Koopacabras
Quoting: EagleDelta
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.
that probably can be easily bypassed with MagisK. There's actually nothing preventing me from patching my own kernel and building a custom rom image, with a patched kernel to run on my android device (and running fortnite with full customized kernel). I don't see that being any different from Linux distros, It might be a little more complicated to setup and compile, than lets say installing xanmod or liquorix kernel, but it's totally doable.

Anyway... I think that clearly, they are not relying on a kernel module on android, so all this about GPL incompatibilities with EAC and the kernel is all nonsense.

Besides let's not make it about Linux only tho... I think that probably Apple wouldn't allow a kernel module for anticheat on their kernel, for the obvious security reasons.

In my opinion...this is not about Linux only, Google banned fortnite from their play store, Apple did likewise. So maybe the problem is Epic here. Maybe their app wants unlimited trust, their app needs more permissions and priviliges, than anything out there, so it's getting banned, for security reasons.
And Sweeney is so blinded with greed, that cannot see the Elephant in the room here.

Not sure that will be a thing anymore. Back in August, Magisk said they were dropping support for hiding root from SafetyNet and joined the Android Platform Security Team.

https://www.xda-developers.com/magisk-development-continues-without-magiskhide/

The latest Magisk release from 2 weeks ago no longer contains MagiskHide
EDIT: Looks like that release just copied the release notes from 24.0
https://github.com/topjohnwu/Magisk/releases/tag/v24.1


Last edited by EagleDelta on 11 February 2022 at 4:09 pm UTC
marcus 11 Feb
View PC info
  • Supporter
Quoting: HoolyThe problem is that even a TPM or Pluton would be unsuited to combat cheaters.

A cheater could simply modify one system and keep another "legit" one. When something asks for a verification, you send that request to the legit machine, have it attest that everything is ok and send that back instead.

This is also why TPMs aren't used to enforce DRM, btw.

Right! I missed that. This is often a general problem in TPM / remote attestation implementations, that after the check you can exchange the system and thus "spoof" the check that it has not been tampered with.

The standard way to combat this in a normal TPM / remote attestation scenario is to encrypt the communication with a key where only the TPM has the private key to decrypt it. So only the trusted non-manipulated software can read the communicated data. However, routing FPS gaming network traffic through a TPM admittedly is prohibitive ;)
hagabaka 11 Feb
View PC info
  • Supporter Plus
Quoting: SamsaiThe 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.
Based on the Linux Syscall Note, using system calls does not count as deriving from the Linux kernel. Otherwise closed-source drivers and libraries couldn't legally exist. You might argue that EAC needs to do more than what the NVIDIA driver might access, and you may be right, but it's not clear how GPL would prevent them from doing those things.


Last edited by hagabaka on 11 February 2022 at 9:06 pm UTC
emphy 11 Feb
For someone who pretends to be doing stuff "for the good of the industry", Sweeney is displaying a remarkably short-sighted stance.

What is the point of "breaking the steam monopoly" if you are going to concede the underlying OS to an even bigger competitor that has a proven track record of monopoly abuse?
Quoting: emphyFor someone who pretends to be doing stuff "for the good of the industry", Sweeney
Somehow I suddenly can't get out of my mind the Joker's laugh from shortly before he makes the pencil disappear.
14 12 Feb
I once scored too high on a WPM typing test. In order to save my score, I had to achieve it again in a different session with various text. That was super annoying!

Something like that could work for players who get automatically flagged or voted as possibly cheating. Modern, multiplayer shooters have some pretty detailed player statistics. You could use those, maybe add player's camera angle and how much of the target's hit box was even visible, to form an algorithm to detect anomalies.

Sure takes the fun out of game development, huh? Well, it could still be handled by a 3rd party in the form of licensed software you package into the game or your game servers and feed its API data from your game. It's all behind the scenes to the player and will work on any operating system that the game's engine works. The game dev has to put some effort into implementation but doesn't have to "recreate the wheel" every new game.


Last edited by 14 on 12 February 2022 at 5:00 pm UTC
Koopacabras 12 Feb
Quoting: emphyFor someone who pretends to be doing stuff "for the good of the industry", Sweeney is displaying a remarkably short-sighted stance.
Sweeney couldn't care less about the industry, he sued Apple because they are a bunch of whiners. Apple ofc did the right thing, any app that wants to take control of your wallet looks SUS to me. He is just a Tencent puppet and he'll do the Tencent "dance" or anything they'll ask. At this point if you consider Sweeney as someone "neutral" and with "fair" opinions, I'm sorry to tell you, but, unfortunately you are being played. He is just a snake oil salesman and a puppet, the opposite of being independent (like ie an indie dev).


Last edited by Koopacabras on 12 February 2022 at 8:57 pm UTC
slaapliedje 13 Feb
View PC info
  • Supporter Plus
Quoting: Koopacabras
Quoting: emphyFor someone who pretends to be doing stuff "for the good of the industry", Sweeney is displaying a remarkably short-sighted stance.
Sweeney couldn't care less about the industry, he sued Apple because they are a bunch of whiners. Apple ofc did the right thing, any app that wants to take control of your wallet looks SUS to me. He is just a Tencent puppet and he'll do the Tencent "dance" or anything they'll ask. At this point if you consider Sweeney as someone "neutral" and with "fair" opinions, I'm sorry to tell you, but, unfortunately you are being played. He is just a snake oil salesman and a puppet, the opposite of being independent (like ie an indie dev).
The whole thing was about Epic wanting to be able to have their own store within the game that didn't use Apple's payment methods (thereby skipping giving Apple a cut).
I am on the fence about this, as for one it is about two greedy bullies trying to figure out who should get all of the kids lunch money they are picking on. Think of Apple as the mob racket, and Epic wanting to move into their territory without paying their cut on the new 'service' they provide.

There is a solution to this Fortnite business... Valve should work on a better game! Guaranteed if something similar enough, but better comes along, Fortnite will be left in the dust, and 20 years from now when the kids that enjoy it get nostalgic, they will have recreated server side software to be able to play it themselves.


Last edited by slaapliedje on 13 February 2022 at 10:38 am UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: Liberapay or PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just 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!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.