Many, many issues with the requirements here that essentially make this unusable for most Linux users. I really hope they don't force current EAC games to upgrade. I would also love to see companies like this actual give behavior-based AC the college try before resorting to shipping spyware.
> Signed Kernel and Kernel modules
Probably the most egregious. Why am I not allowed to compile my own kernel? Why do I have to get a kernel, and modules, from specific, approved, vendors?
> TPM 2.0, Secure Boot, Measured Boot
Also all impractical for most linux users.
> IOMMU
You may not spy on my memory, thank you very much. What's stopping Epic from taking snapshots and phoning home?
> Kernel Lockdown Integrity mode at boot time
Preventing root from doing root things for the sake of it. I mean, maybe this makes sense.
They're also trying really hard to make Linux distros that "don't support this" look like the bad guys. They encourage distro maintainers to reach out to work together on the requirements, but many distros are effectively excluded by default (Arch, Gentoo, NixOS, which I believe have most of the gamers, at least in the online spaces I chat in).
When I used Arch I had full secure boot set up. Making a second kernel image with the Epic required settings is not hard.
I think most people will dual boot a ready made gaming distro like Garuda next to their normal one anyway because the kind of setup you need to really optimize game performance is not easy, and you can get a console/Steam Deck like experience right from boot.
Even a locked down Linux is infinitely better than Windows if you care about privacy, because you only have two closed source components (EAC and the game itself) instead of the whole OS. If any of them tries to read your private data it will turn to a scandal immediately and they can't blame Microsoft.
And IOMMU does not let anyone spy on memory. The whole point of it is making sure no one can do that, to avoid DMA hacks.
> Probably the most egregious. Why am I not allowed to compile my own kernel? Why do I have to get a kernel, and modules, from specific, approved, vendors?
Because your kernel could have the ability to allow a program to modify the game memory and hide the fact it's doing so?
Most Linux users are probably using a signed kernel. I don't think this is as big of a deal as you're making out.
> Because your kernel could have the ability to allow a program to modify the game memory and hide the fact it's doing so?
I understand this, and my contention with this is that a signed kernel could have that too, so requiring the kernel to be signed locks us into very few ways of getting the kernel with little benefit to the AC if a key is leaked.
> Most Linux users are probably using a signed kernel. I don't think this is as big of a deal as you're making out.
I don't think this is true of most people interested in gaming on Linux in particular. Aside from that, the chain of things you need to do to prove you have a signed kernel are onerous and incompatible with many bootloaders and other tools many Linux users use regularly.
Right, well, for me I ditched Windows entirely because every serious development workflow is way more involved and complex, performance is really poor, random weird bugs after mandated updates, and so on. The cherry on top is all of Valve and the open source folks work on Proton and gaming on Linux in general.
All good and dandy, except Valve's failure to have studios target Linux, including games that already make use of compatible APIs, like those using Android NDK.
Thus Proton depends on Windows as source ecosystem, only yet another platform to "emulate" on Linux, like MAME, Amiga, Playstation, whatever.
I can't disagree with that, of course. I can only point to Valve at least shipping their games (notably CS2 and Deadlock) native, and the overall improvement in the performance and ergonomics of Proton in the past decade.
> Probably the most egregious. Why am I not allowed to compile my own kernel? Why do I have to get a kernel, and modules, from specific, approved, vendors?
So you can't compile cheats into your kernel? You want your own custom compiled kernel for hypothetical 2℅ performance gains in a synthetic benchmark? Just don't boot into it when you wanna play the game.
> Also all impractical for most linux users.
You don't represent "most" linux users. Define impracticality here because these are genuinely useful security features that you ideally should have even if you don't wanna play Fortnite.
> You may not spy on my memory, thank you very much. What's stopping Epic from taking snapshots and phoning home?
The fact that it would be a huge legal and PR nightmare for them upon getting caught which is very much in the realm of possibilities given the fact that it's not hard to tell if some eBPF byte code is doing that especially with LLMs making it a 100x easier nowadays.
> Preventing root from doing root things for the sake of it. I mean, maybe this makes sense.
Just don't boot into the kernel you want to tamper with when you want to play an EAC game. Problem solved
> They're also trying really hard to make Linux distros that "don't support this" look like the bad guys. They encourage distro maintainers to reach out to work together on the requirements, but many distros are effectively excluded by default (Arch, Gentoo, NixOS, which I believe have most of the gamers, at least in the online spaces I chat in).
You just made that up in your head. You can install a kernel that EAC will accept into any of these distros. Oh, and, did you just say most gamers in the online spaces you frequent use Arch, Gentoo and NixOS? I can buy Arch, sure, but NixOS? and especially Gentoo?! I guess that explains your comment and gives me context on why you decided to write what you have written. You're far from "most" linux users, buddy. Most people don't care if they've haven't hand-compiled their own kernel on the back of a notebook they bought in 1998. I myself use Arch and if I ever want to play such a game, I'll just boot into a kernel that has been signed by a key that EAC accepts and won't go around whining that Arch maintainers are bad or anything.
This is a good thing but I guess it takes time to let the copium wear off that a lot of neck beard linux users kept sniffing over the years when they couldn't find a good answer for people not wanting to switch because their favorite game wouldn't run by calling literally any closed source code running below ring 0, "rootkit" as if their UEFI and firmware is GPL licensed.
> And luckily, according to the article, Valve has no immediate intention of getting the Steam Deck to meet those requirements.
I'm not sure how you get that from the article (maybe it was pointed to a different article earlier?).
I don't have a Steam Deck, but as I understand it, it does not support Secure Boot out-of-the-box. Also, SteamOS is Arch-based, and it doesn't look like Arch is listed among the "well-known" signing keys that EACv2 lists as trusted.
But not supporting the EACv2's requirements today, doesn't mean that Valve is inherently opposed to doing so. If you have a statement from Valve claiming that, please share it.
I suppose I read into the Steam Deck not supporting all of the requirements right now a bit much. Thats the section I was referencing. I am still hopeful they'll at least object to IOMMU and get some movement from Epic there...
Aside from the fact that this is obviously not true (secure boot is possible on Linux, limine/lanzaboote come to mind), I would argue these security modules / attestations do very little for security and are more about lock in and control.
Look, if Canonical had one of their keys leaked, I can go and sign my kernel and kernel modules and secure boot just fine as if my kernel is one distributed by Canonical. There are no checks on whether the contents of the kernel are correct. So, let's exclude people entirely from tuning their kernel for performance etc, and tell them they have to go to a narrow set of approved vendors, who must listen to Epic rather than their users. This is about control over the ecosystem, an ecosystem Epic has spent their years spitting in the face of.
Many, many issues with the requirements here that essentially make this unusable for most Linux users. I really hope they don't force current EAC games to upgrade. I would also love to see companies like this actual give behavior-based AC the college try before resorting to shipping spyware.
> Signed Kernel and Kernel modules
Probably the most egregious. Why am I not allowed to compile my own kernel? Why do I have to get a kernel, and modules, from specific, approved, vendors?
> TPM 2.0, Secure Boot, Measured Boot
Also all impractical for most linux users.
> IOMMU
You may not spy on my memory, thank you very much. What's stopping Epic from taking snapshots and phoning home?
> Kernel Lockdown Integrity mode at boot time
Preventing root from doing root things for the sake of it. I mean, maybe this makes sense.
They're also trying really hard to make Linux distros that "don't support this" look like the bad guys. They encourage distro maintainers to reach out to work together on the requirements, but many distros are effectively excluded by default (Arch, Gentoo, NixOS, which I believe have most of the gamers, at least in the online spaces I chat in).
When I used Arch I had full secure boot set up. Making a second kernel image with the Epic required settings is not hard.
I think most people will dual boot a ready made gaming distro like Garuda next to their normal one anyway because the kind of setup you need to really optimize game performance is not easy, and you can get a console/Steam Deck like experience right from boot.
Even a locked down Linux is infinitely better than Windows if you care about privacy, because you only have two closed source components (EAC and the game itself) instead of the whole OS. If any of them tries to read your private data it will turn to a scandal immediately and they can't blame Microsoft.
And IOMMU does not let anyone spy on memory. The whole point of it is making sure no one can do that, to avoid DMA hacks.
Before: it wasn't possible to run these specific games that require this competitive anti-cheat on Linux.
So you can ignore the newly-enabled games in this proposal and you're not missing anything you had previously.
> Probably the most egregious. Why am I not allowed to compile my own kernel? Why do I have to get a kernel, and modules, from specific, approved, vendors?
Because your kernel could have the ability to allow a program to modify the game memory and hide the fact it's doing so?
Most Linux users are probably using a signed kernel. I don't think this is as big of a deal as you're making out.
> Because your kernel could have the ability to allow a program to modify the game memory and hide the fact it's doing so?
I understand this, and my contention with this is that a signed kernel could have that too, so requiring the kernel to be signed locks us into very few ways of getting the kernel with little benefit to the AC if a key is leaked.
> Most Linux users are probably using a signed kernel. I don't think this is as big of a deal as you're making out.
I don't think this is true of most people interested in gaming on Linux in particular. Aside from that, the chain of things you need to do to prove you have a signed kernel are onerous and incompatible with many bootloaders and other tools many Linux users use regularly.
All of this will defeated by one of the now regular Linux LPEs anyway.
Even on Windows I don't install such games.
There are so many to chose from, even retrogaming content is more than I can play during my remaining lifetime.
Right, well, for me I ditched Windows entirely because every serious development workflow is way more involved and complex, performance is really poor, random weird bugs after mandated updates, and so on. The cherry on top is all of Valve and the open source folks work on Proton and gaming on Linux in general.
All good and dandy, except Valve's failure to have studios target Linux, including games that already make use of compatible APIs, like those using Android NDK.
Thus Proton depends on Windows as source ecosystem, only yet another platform to "emulate" on Linux, like MAME, Amiga, Playstation, whatever.
I can't disagree with that, of course. I can only point to Valve at least shipping their games (notably CS2 and Deadlock) native, and the overall improvement in the performance and ergonomics of Proton in the past decade.
> Probably the most egregious. Why am I not allowed to compile my own kernel? Why do I have to get a kernel, and modules, from specific, approved, vendors?
So you can't compile cheats into your kernel? You want your own custom compiled kernel for hypothetical 2℅ performance gains in a synthetic benchmark? Just don't boot into it when you wanna play the game.
> Also all impractical for most linux users.
You don't represent "most" linux users. Define impracticality here because these are genuinely useful security features that you ideally should have even if you don't wanna play Fortnite.
> You may not spy on my memory, thank you very much. What's stopping Epic from taking snapshots and phoning home?
The fact that it would be a huge legal and PR nightmare for them upon getting caught which is very much in the realm of possibilities given the fact that it's not hard to tell if some eBPF byte code is doing that especially with LLMs making it a 100x easier nowadays.
> Preventing root from doing root things for the sake of it. I mean, maybe this makes sense.
Just don't boot into the kernel you want to tamper with when you want to play an EAC game. Problem solved
> They're also trying really hard to make Linux distros that "don't support this" look like the bad guys. They encourage distro maintainers to reach out to work together on the requirements, but many distros are effectively excluded by default (Arch, Gentoo, NixOS, which I believe have most of the gamers, at least in the online spaces I chat in).
You just made that up in your head. You can install a kernel that EAC will accept into any of these distros. Oh, and, did you just say most gamers in the online spaces you frequent use Arch, Gentoo and NixOS? I can buy Arch, sure, but NixOS? and especially Gentoo?! I guess that explains your comment and gives me context on why you decided to write what you have written. You're far from "most" linux users, buddy. Most people don't care if they've haven't hand-compiled their own kernel on the back of a notebook they bought in 1998. I myself use Arch and if I ever want to play such a game, I'll just boot into a kernel that has been signed by a key that EAC accepts and won't go around whining that Arch maintainers are bad or anything.
This is a good thing but I guess it takes time to let the copium wear off that a lot of neck beard linux users kept sniffing over the years when they couldn't find a good answer for people not wanting to switch because their favorite game wouldn't run by calling literally any closed source code running below ring 0, "rootkit" as if their UEFI and firmware is GPL licensed.
No arch?
Looking at those requirements, I doubt this will ever get that much adoption.
And luckily, according to the article, Valve has no immediate intention of getting the Steam Deck to meet those requirements.
> And luckily, according to the article, Valve has no immediate intention of getting the Steam Deck to meet those requirements.
I'm not sure how you get that from the article (maybe it was pointed to a different article earlier?).
I don't have a Steam Deck, but as I understand it, it does not support Secure Boot out-of-the-box. Also, SteamOS is Arch-based, and it doesn't look like Arch is listed among the "well-known" signing keys that EACv2 lists as trusted.
But not supporting the EACv2's requirements today, doesn't mean that Valve is inherently opposed to doing so. If you have a statement from Valve claiming that, please share it.
I suppose I read into the Steam Deck not supporting all of the requirements right now a bit much. Thats the section I was referencing. I am still hopeful they'll at least object to IOMMU and get some movement from Epic there...
Yeah, the arch omission is a bit telling.
The thing is, Android, iDevices don't do kernel drivers for apps.
Additionally macOS is transitioning to have only userspace drivers.
I suspect that eventually Microsoft will be pressured to do the same with the ongoing cyber security liability laws, and disasters like in 2024.
So will they only do consoles when it comes to it?
iOS and Android both have remote attestation services and security coprocessors you can use to establish the integrity of the booted environment.
Desktop Linux has none of that.
Yes, but that alone doesn't prevent the cheats, because you get developer access.
Aside from the fact that this is obviously not true (secure boot is possible on Linux, limine/lanzaboote come to mind), I would argue these security modules / attestations do very little for security and are more about lock in and control.
Look, if Canonical had one of their keys leaked, I can go and sign my kernel and kernel modules and secure boot just fine as if my kernel is one distributed by Canonical. There are no checks on whether the contents of the kernel are correct. So, let's exclude people entirely from tuning their kernel for performance etc, and tell them they have to go to a narrow set of approved vendors, who must listen to Epic rather than their users. This is about control over the ecosystem, an ecosystem Epic has spent their years spitting in the face of.
It's clearly targeted at Linux servers for cloud gaming
Now you're thinking like ... NVIDIA circa 2015 or something like that
un acc epti cal