- Joined
- Dec 19, 2005
- Messages
- 18,455
what would happen if you implemented kernel level drivers for anticheat under Linux?
![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
EAC v2 and Fortnite coming to Linux
- Thread starter Mazzspeed
- Start date
I don't believe you can actually do it anymore, the process has been outlawed, it's the reason Nvidia swapped from closed drivers to nvidia-open drivers. Under nvidia-open, the closed source driver runs in user land, it's the shim connecting the driver to the kernel that runs at kernel level, and that shim is open source.
It doesn't secure shit. SO.
Secure boot isn't really the issue here. SystemD processes are concerning. I don't think this is going to go as smoothly as Epic would hope. We'll see I can admit when I'm wrong.
You can still run full kernel mode drivers
For example, it's how monitoring software works - if you need to read something out of an MSR, you need an actual kernel module
- Joined
- Dec 19, 2005
- Messages
- 18,455
could you technically build the kernel with a lot this approach to enable ai to decompose it into source as a permissive license like MIT
and then you have an ai cloned linux kernel that you can allow for kernel level anti cheat legally?
# --- Optimization Drop ---
CONFIG_CC_OPTIMIZE_FOR_NONE=y
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=n
CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED=y
# --- Frame & Boundary Enforcement ---
CONFIG_FRAME_POINTER=y
CONFIG_STACKTRACE=y
# --- Metadata Blueprint Injection ---
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_REDUCED=n
CONFIG_DEBUG_INFO_DWARF5=y
CONFIG_DEBUG_INFO_BTF=y
CONFIG_DEBUG_INFO_BTF_MODULES=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# --- Structural Runtime Tracing Hooks ---
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_KPROBES=y
CONFIG_EVENT_TRACING=y
CONFIG_PERF_EVENTS=y
It secures shit more so than no secure boot in place whatsoever. This is about coming up with viable solutions to problems, while being open and transparent with leaders in the Linux community as well as Valve and other willing companies in the industry, to the extent of co-hosting panel discussions with willing project leaders - and Linux needs a solution to the kernel level anticheat problem as it's only going to get worse as more studios jump on the AC bandwagon.
As stated: no one's forcing you to make use of it, but personally I'm staying open minded and I intend to try it when Fortnite's released under Linux, even though I have absolutely no interest in the game whatsoever.
Last edited:
What do you mean "a kernel level anti cheat legally?"
You could implement your anti cheat as a kernel module if you wanted. It doesn't HAVE to be an eBPF program.
You still need a shim allowing the driver to communicate with the kernel, you can't modify the kernel directly which I believe is what Nvidia were doing. IMO a full kernel level driver really is a step too far when it comes to AC, hence why I state this is a compromise on behalf of both users and studios.
EDIT: Monitoring software can also make use of eBPF...
The use of very specific kernels just to play games is what we're trying to avoid here. Once again, this is a distinction that needs to be understood: signing kernels is not the same as locking users to specifically built kernels just to play games.
EDIT: Furthermore, Arch is used as the basis for SteamOS, distro maintainers could very well lean on Valve for the signing of kernels and drivers.
- Joined
- Dec 19, 2005
- Messages
- 18,455
how’d nvidia get caught?
- Joined
- Dec 19, 2005
- Messages
- 18,455
Production-Grade Linux Clone:
Highly Unfeasible. Replacing the full breadth of the Linux kernel—which handles millions of lines of hardware-specific drivers, complex file systems, and cutting-edge networking stacks—would require millions of dollars in compute, flawless multi-agent coordination, and years of iterative prompt engineering.
—-
1 The Dirty Architect Agent: This agent has access to your unoptimized, highly traceable Linux binary compilation. It parses the control flow graphs, BTF type maps, and DWARF5 metadata. Its sole output is a highly granular, language-agnostic text specification (e.g., "Design an intrusive red-black tree layout for virtual memory tracking that responds to the following interface constraints...").
2 The Clean Engineer Agent: This agent operates in a completely isolated context window. It has zero access to the Linux kernel source code, the internet, or the decompiled binary. It receives only the text specification from the Architect and writes the fresh C or Rust code from scratch.
3 The Validation Agent: A third, independent agent runs test suites against the Clean Engineer's output to verify binary-level compatibility with standard Linux user-space binaries.
Production-Grade Linux Clone:
Highly Unfeasible. Replacing the full breadth of the Linux kernel—which handles millions of lines of hardware-specific drivers, complex file systems, and cutting-edge networking stacks—would require millions of dollars in compute, flawless multi-agent coordination, and years of iterative prompt engineering.
—-
1 The Dirty Architect Agent: This agent has access to your unoptimized, highly traceable Linux binary compilation. It parses the control flow graphs, BTF type maps, and DWARF5 metadata. Its sole output is a highly granular, language-agnostic text specification (e.g., "Design an intrusive red-black tree layout for virtual memory tracking that responds to the following interface constraints...").
2 The Clean Engineer Agent: This agent operates in a completely isolated context window. It has zero access to the Linux kernel source code, the internet, or the decompiled binary. It receives only the text specification from the Architect and writes the fresh C or Rust code from scratch.
3 The Validation Agent: A third, independent agent runs test suites against the Clean Engineer's output to verify binary-level compatibility with standard Linux user-space binaries.
I don't know what this is implying, it seems AI generated.
I believe it was always known just what Nvidia were doing, leaders in the Linux community just turned a blind eye until it wasn't acceptable anymore.
You can definitely just YOLO it.
You need root to load it (and you need to appease whatever other kernel security features you enabled), but there's not really anything stopping you from just straight up building a module and raw dogging some hardware or whatever you want and blowing your leg off.
- Joined
- Dec 19, 2005
- Messages
- 18,455
i was suggesting a clean room reimplementation of the linux kernel clone so we could move forward with allowing kernel level anticheats
- Joined
- Dec 19, 2005
- Messages
- 18,455
it’s be awesome if that worked and we got more games on linux that use kernel level anticheat
That's 'exactly' what we don't want. We do not want to be forced to run very specific kernel builds that specifically support very specific anticheat implementations. Epic's solution is waaaaay better than such an approach.
eBPF is already extensively used for hot patching and mitigations to work around security issues/bugs without the need to recompile the kernel or reboot the system.
Last edited:
Apart from issues with GPL-only exported symbols the other problem is that you could easily reverse-engineer them on Linux.
- Joined
- Dec 19, 2005
- Messages
- 18,455
so cheats could easily bypass the anti cheat then you’re saying?
it’s be awesome if that worked and we got more games on linux that use kernel level anticheat
I mean that's literally what Epic is trying to soften the blow around with their eBPF implementation.
Well, I think it's a bit of a multi pronged approach - they're trying to make it as difficult up front to even attempt a meaningful attack, and still balance how much ordinance they're willing to deploy against it.
There's probably some things they can't quite do as effectively, but I think this gets them pretty far.
We actually really don't need a solution to kernel level anti cheat. NO Gaming company should be doing that.
Your right no one is forcing me to use this and I won't. Valve isn't going to enable this on steamos so this isn't going to solve anything. If Epic is serious about Linux (and I don't believe they are) they would be looking for real working anti cheat solutions. What they are proposing, I don't know maybe it isn't as terrible as I believe. I think realistically their proposed solution is going to work on a very small sub set of un popular Linux distros. Again I guess we'll see, maybe I'm wrong and everyone buys in. Keep in mind Valve never turned on Secure boot on their hardware. I doubt EPIC saying what about our shooter guys convinces them to change that.
At this point I'll wait and see what the company that cares so much they Vibe coded a launcher actually achieves. I am a little worried Epic comes in gets a bunch of other developers to use their solution then drop the ball... and leave. I don't trust Epic one bit.
Pretty much just like in Windows yes.
Easier than in Windows, yes.
But we do. Server side anticheat can only go so far, and user land anticheat isn't terribly effective - VACnet and VAC are evidence of that, cheating under CS2 is out of control. Don't get me wrong, I'm by no means a fan of kernel level anticheat, but what Epic are proposing is philosophically better than the solution currently in place under Windows, while trying to appease all parties - and technically, this isn't strictly kernel level anticheat and still less effective than the solution implemented under Windows (but obviously better than EAC).
As more games move to such solutions, we need a way to let studio's know that it's OK to allow your game to run under Linux, or soon enough there will be no games to play under Linux. You may be comfortable playing Linux native titles, personally I believe most of them are poorly optimized hacks.
I don't see any evidence whatsoever Valve aren't going to implement this on SteamOS.
And if that's the case, should EAC v2 actually be successful and studios start mass adopting it in place of EAC, I'm sure people will have no problem hopping to a distro supporting EAC v2. Having said that, I'm also confident CachyOS maintainers will work on a solution, possibly one that involves Valve considering SteamOS is Arch based.
You are right regarding one previous comment, CachyOS isn't specifically a gaming distro. Based on my testing running KDE Neon as well as CachyOS here, quite often KDE Neon comes out in front. It's just another distro, use what works for you.
So your argument is "Valve hasn't done it yet, so they never will". Based on Valve's contributions to gaming under Linux thus far, finer details may need to be ironed out, but I see absolutely no reason why Valve wouldn't be fully committed to Epic's solution.
Something they didn't do regarding EAC, I see no reason they'd start now unless the Linux community as a whole totally rejects their solution; and based on what I've been reading across the interwebz, this isn't the case. At the end of the day, this is a far more viable and fairer solution than anything proposed by armchair experts that I've read so far; and it gives those wanting to play more games under Linux more options - which in itself isn't a bad thing.
Last edited:
Flogger23m
Fully [H]
- Joined
- Jun 19, 2009
- Messages
- 16,963
So Epic is making Valve improve Steam? Seems like a win for everyone.
The time it takes for Steam to start off a bloody fast SSD is enough to drive a man to drink. Having said that, I got an update to the EGS launcher for Linux today, and it's still buggy as all hell to the point of being basically unusable, but at least there was an update.
EDIT: That's odd, the window is rendered correctly in the screenshot, but not when I view it directly on the screen in front of me...
Screenshot using Spectacle:
Screenshot using phone camera:
Last edited:
I think we are just going to have to disagree on this one.
We really don't need kernel level anti cheat anything. If developers don't want to release their games on Linux cause they can't root users machines... ok. I get what Epic is proposing is a sort of in between solution. I still don't see it working out they way they are hoping/suggesting.
Valve so far hasn't said a thing about this Epic thing. Epic saying "we are talking to Valve" really doesn't mean a thing. Valve has been down these roads with other developers the last few years. The result has always been Valve holding the line at compromising in anyway on the anti cheat front. Valve has pushed their own non security hole anti cheat solution. They aren't going to bend over backwards to accommodate the direct competition. I think Gabes response to this is going to be a big middle finger. (Though if in a couple days they come out and say ya ya we are on board I'll admit I was wrong) Yes Valve has contributed to gaming no doubt, they have never budged on allowing anyone's anti cheat solution to dictate anything about their OS. I highly doubt they will now.
This is just my opinion. But if Valve was GOING to be on board with this. Epic would have waited till they could say so. An announcement with out Valve already on board is a pressure tactic. My guess it doesn't work.
Bug report it so they can get Claude on that.
(I'm joking Maz) lol
I actually did a bug report using the little button in the app, screenshot and all.
I think we are just going to have to disagree on this one.
We really don't need kernel level anti cheat anything. If developers don't want to release their games on Linux cause they can't root users machines... ok. I get what Epic is proposing is a sort of in between solution. I still don't see it working out they way they are hoping/suggesting.
Valve so far hasn't said a thing about this Epic thing. Epic saying "we are talking to Valve" really doesn't mean a thing. Valve has been down these roads with other developers the last few years. The result has always been Valve holding the line at compromising in anyway on the anti cheat front. Valve has pushed their own non security hole anti cheat solution. They aren't going to bend over backwards to accommodate the direct competition. I think Gabes response to this is going to be a big middle finger. (Though if in a couple days they come out and say ya ya we are on board I'll admit I was wrong) Yes Valve has contributed to gaming no doubt, they have never budged on allowing anyone's anti cheat solution to dictate anything about their OS. I highly doubt they will now.
This is just my opinion. But if Valve was GOING to be on board with this. Epic would have waited till they could say so. An announcement with out Valve already on board is a pressure tactic. My guess it doesn't work.
Oh we're definitely disagreeing on this one. No Linux user should feel they have the right to stand on the soapbox and tell other Linux users that they can't use their systems as they see fit to play the games they like under the OS of their choosing when everyone has options available to them and no part of this implementation is being forced on anyone. I see absolutely no reason why Valve wouldn't be 100% on board with Epic's implementation.
If the suggestion is to break the majority of installs ya I'm not going to say ya ok FOR GAMINGS (epics) sake. As I have already said I also see how this could go very wrong for us very quickly. I think every can see the security issues with this implementation. Cheaters.... are going to cheat. They have many ways through windows based kernel level anti cheat. (All this talk of needing more low level game security would mean more if it actually worked, but it doesn't) What is worse, is someone is likely to break this hard on purpose so they can do some ransomware or some other highly annoying destructive thing that is going to result in a... OK BACK to windows developers and gamers.
If Epic had come in with their tale in their hands and said ya you know what we want to support Linux. We aren't going to push our windows lite solution here we have talked to Valve and are are going to do this. Then I would be less hostile. That isn't what they did. EAC already worked on Linux. Lets all get a little real here. EAC as it was WORKED. The extra kernel level stuff done in Fortnight, Apex, Battlefield hasn't really done all that great a job of keeping cheatin off windows? They could turn Linux support on for their games right now with a click. THIS is a play to start weezling their way in and I have zero doubt long term they are still angling for a kernel back door.
Coming as they have. They are saying LOOK we made a vibe coded launcher. We are using a community built version of valves proton. Basically we made a less then version of Heroic game launcher. OH and we have decided that we know best, how to make game anti cheat work better FOR US in Linux. HERE is our solution take it or don't and be blocked. We are also going to push other developers using EAC to adopt the new version... breaking the installs of 1,000s of current Linux users. Once Epic rolls this out. Are games like Elden Ring or black desert going to end up being a PITA cause now they require secure boot and signed kernels as well cause Epic got them to adopt their newer version of EAC. Epic has come in, with a pretty anti open source stance imo.
I think we are just going to have to disagree on this one.
We really don't need kernel level anti cheat anything. If developers don't want to release their games on Linux cause they can't root users machines... ok. I get what Epic is proposing is a sort of in between solution. I still don't see it working out they way they are hoping/suggesting.
Valve so far hasn't said a thing about this Epic thing. Epic saying "we are talking to Valve" really doesn't mean a thing. Valve has been down these roads with other developers the last few years. The result has always been Valve holding the line at compromising in anyway on the anti cheat front. Valve has pushed their own non security hole anti cheat solution. They aren't going to bend over backwards to accommodate the direct competition. I think Gabes response to this is going to be a big middle finger. (Though if in a couple days they come out and say ya ya we are on board I'll admit I was wrong) Yes Valve has contributed to gaming no doubt, they have never budged on allowing anyone's anti cheat solution to dictate anything about their OS. I highly doubt they will now.
This is just my opinion. But if Valve was GOING to be on board with this. Epic would have waited till they could say so. An announcement with out Valve already on board is a pressure tactic. My guess it doesn't work.
Well, Valve (Arch) appears to already be heading in this direction / doing adjacent work
They have literally provided financial sponsorship to build/singing infrastructure for Arch
https://lists.archlinux.org/archive....org/thread/RIZSKIBDSLY4S5J2E2STNP5DH4XZGJMR/
https://rfc.archlinux.page/0059-automated-digital-signing-of-os-artifacts/
https://gitlab.archlinux.org/archlinux/signstar
Once this begins rolling out, it is the ticket to Arch having what it needs. It's not just packages - secure boot is mentioned in the RFC / roadmap.