6 ms·

Going through great pains to support EAC is a bit ridiculous. EAC itself is ridiculous from the get-go since it doesn't actually prevent cheaters it just prete

Going through great pains to support EAC is a bit ridiculous. EAC itself is ridiculous from the get-go since it doesn't actually prevent cheaters it just pretends. It's not even meant to stop cheaters! Its entire purpose is to lock developers into Epic's proprietary system and prevent them from porting to non-approved platforms. The entire premise of client side anti-cheat tools is, "trust the client." I think pretty much everyone at Hacker News knows that's the exact opposite of how you make a secure system. Never trust the client.

m-p-3 4y ago
The issue with the server-client relationship in games is there a trade-off between latency and security required. Offload too many tasks to the server and you end up with a game where you encounter latency where it's critical, like hit detection (and likely many others). Those extra milliseconds does make or break the experience. Not saying it's an impossible problem to solve, just that multiplayer games are operating in a time-sensitive environment.
brigade 4y ago
I don't think anyone is proposing to eliminate support for --hash-style=both. Correct me if I'm wrong? So at this point, the maintenance burden on glibc is however much effort they want to spend justifying breaking backwards compatibility.
- ajross 4y ago
  They didn't break backwards compatibility, only forwards. The core issue here is that there is a new format that won't work with old runtime linkers. But the only way to present that format to those old linkers[1] is to take a binary compiled with a glibc version from the last few weeks (!) and run it against on a system where the ld-linux.so is from pre-2006 glibcs. That direction of compatibility is not impossible, but it's not what one normally considers when discussing "breaking backwards compatibility". Fundamentally the only way to provide the kind of compatibility you're demanding, where any level of reverse engineering or parallel implementation must be supported in perpetuity, is to just Never Change Anything At All. [1] With the sole known exception of the "runtime linker" embedded in this EAC product under discussion.
  - fweimer 4y ago
    If the required symbol versions are provided by the old glibc version (which is a bit unlikely), it will still work. The internal glibc hash tables are ignored by the link editor, and most distributions override the link editor hash table default anyway. (What changed is that glibc no longer overrides the distribution defaults.)
  - brigade 4y ago
    Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that. Never Change Anything is far from the ask here. The ask is that when real actual breakage is found, the benefits of keeping said breakage justify not spending the engineering costs to fix backwards compatibility. Near as I can tell, the benefit is 16kB disk space savings, and glibc's engineering cost to maintain compatibility is nothing. Like, another backwards compatibility breakage I saw recently was Graphene switching from 39-bit to 48-bit virtual address space, which also broke games. That has a real measurable security benefit, and actual engineering costs to develop a backwards compatibility story. But they still spent effort to fix breakages.
    - ajross 4y ago
      > Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that. No, that's simply wrong. No "glibc binary" that could have been even theoretically compiled within the past few decades will fail to run because of this issue. What happened is that this EAC product had reverse-engineered the internal formats glibc uses to provide the APIs it implements. And that format changed. I repeat what I said elsewhere: it is simply not possible for any software product to anticipate all possible external users of its internal implementation details. What you want, you cannot have. (And I repeat what I said elsewhere too: you don't have this, even on windows. Microsoft breaks things like anti-cheat hackery with every release too, it's just that you don't notice because the proprietary vendors care enough to fix it, where they don't on Linux.)
      - brigade 4y ago
jsheard 4y ago
Not trusting the client can only get you so far, in some types of game it's unavoidable that the client must have enough information and control that a cheat can enhance human play or replace the human altogether. It will always be possible to enhance aiming in a shooter, or automate repetitive tasks in an MMO, or script perfect blocks and parries in a fighting game, or feed the state of an online chess game into Stockfish and have it play for you, even if you trust the client to the minimum possible extent. The only things that can be done in those cases are loosely "detecting" cheaters through heuristics and human review of suspicious behaviour, which won't catch more careful cheaters and may lead to false positives, and client side solutions like EAC which frustrate less skilled cheat developers and sometimes catch the more skilled ones off guard. Alternatively, give up on PC and focus on consoles which are sufficiently locked down that cheating is currently impossible regardless of how much you trust the client.
- kllrnohj 4y ago
  Or server-side automated review using machine learning models, which is what Valve is trying with "vacnet" (with then manual review to confirm the model's results are accurate - something most tech companies should learn from) Great talk on it here: https://www.youtube.com/watch?v=kTiP0zKF9bc https://www.youtube.com/watch?v=kTiP0zKF9bc
  - jsheard 4y ago
    It's an interesting idea, but it's hard to say if it's really effective against anything besides blatant ragehacking. AFAICT the general consensus in the community is that Valves own CS:GO servers are still infested with cheaters, and to avoid them you need to go to ESEA or FACEIT (third party CS:GO matchmaking services) or Valorant (Riots CS:GO clone) which all primarily rely on very aggressive clientside scanning solutions.
    - kllrnohj 4y ago
      I suspect for ESEA & FACEIT the most effective aspect of their anticheats is just that they are paid services. If I'm going to cheat at a game, I'm generally going to bias towards minimal consequences if I do get caught. I can say that Valorant's anti cheat is the singular reason I've never tried it, even though I love counter-strike and similar games. Giving game devs (especially those owned by Tencent) ring 0 access is, uh, a step too far I think.
matheusmoreira 4y ago
Yeah. These things have to literally take over the machine in order to even have a chance at preventing anything. They're basically malware at this point. EAC is implemented as a kernel module, at least in Windows. It's bad enough to have to put up with proprietary nvidia drivers, now we're gonna have to tolerate this? It doesn't even work, people will still cheat. I seriously hope these corporations don't start pushing this on Linux gamers. They need to accept that they can't control it and move on.

m-p-3 4y ago

The issue with the server-client relationship in games is there a trade-off between latency and security required. Offload too many tasks to the server and you end up with a game where you encounter latency where it's critical, like hit detection (and likely many others). Those extra milliseconds does make or break the experience. Not saying it's an impossible problem to solve, just that multiplayer games are operating in a time-sensitive environment.

brigade 4y ago

I don't think anyone is proposing to eliminate support for --hash-style=both. Correct me if I'm wrong? So at this point, the maintenance burden on glibc is however much effort they want to spend justifying breaking backwards compatibility.

ajross 4y ago
They didn't break backwards compatibility, only forwards. The core issue here is that there is a new format that won't work with old runtime linkers. But the only way to present that format to those old linkers[1] is to take a binary compiled with a glibc version from the last few weeks (!) and run it against on a system where the ld-linux.so is from pre-2006 glibcs. That direction of compatibility is not impossible, but it's not what one normally considers when discussing "breaking backwards compatibility". Fundamentally the only way to provide the kind of compatibility you're demanding, where any level of reverse engineering or parallel implementation must be supported in perpetuity, is to just Never Change Anything At All. [1] With the sole known exception of the "runtime linker" embedded in this EAC product under discussion.
- fweimer 4y ago
  If the required symbol versions are provided by the old glibc version (which is a bit unlikely), it will still work. The internal glibc hash tables are ignored by the link editor, and most distributions override the link editor hash table default anyway. (What changed is that glibc no longer overrides the distribution defaults.)
- brigade 4y ago
  Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that. Never Change Anything is far from the ask here. The ask is that when real actual breakage is found, the benefits of keeping said breakage justify not spending the engineering costs to fix backwards compatibility. Near as I can tell, the benefit is 16kB disk space savings, and glibc's engineering cost to maintain compatibility is nothing. Like, another backwards compatibility breakage I saw recently was Graphene switching from 39-bit to 48-bit virtual address space, which also broke games. That has a real measurable security benefit, and actual engineering costs to develop a backwards compatibility story. But they still spent effort to fix breakages.
  - ajross 4y ago
    > Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that. No, that's simply wrong. No "glibc binary" that could have been even theoretically compiled within the past few decades will fail to run because of this issue. What happened is that this EAC product had reverse-engineered the internal formats glibc uses to provide the APIs it implements. And that format changed. I repeat what I said elsewhere: it is simply not possible for any software product to anticipate all possible external users of its internal implementation details. What you want, you cannot have. (And I repeat what I said elsewhere too: you don't have this, even on windows. Microsoft breaks things like anti-cheat hackery with every release too, it's just that you don't notice because the proprietary vendors care enough to fix it, where they don't on Linux.)
    - brigade 4y ago

jsheard 4y ago

Not trusting the client can only get you so far, in some types of game it's unavoidable that the client must have enough information and control that a cheat can enhance human play or replace the human altogether. It will always be possible to enhance aiming in a shooter, or automate repetitive tasks in an MMO, or script perfect blocks and parries in a fighting game, or feed the state of an online chess game into Stockfish and have it play for you, even if you trust the client to the minimum possible extent. The only things that can be done in those cases are loosely "detecting" cheaters through heuristics and human review of suspicious behaviour, which won't catch more careful cheaters and may lead to false positives, and client side solutions like EAC which frustrate less skilled cheat developers and sometimes catch the more skilled ones off guard. Alternatively, give up on PC and focus on consoles which are sufficiently locked down that cheating is currently impossible regardless of how much you trust the client.

kllrnohj 4y ago
Or server-side automated review using machine learning models, which is what Valve is trying with "vacnet" (with then manual review to confirm the model's results are accurate - something most tech companies should learn from) Great talk on it here: https://www.youtube.com/watch?v=kTiP0zKF9bc https://www.youtube.com/watch?v=kTiP0zKF9bc
- jsheard 4y ago
  It's an interesting idea, but it's hard to say if it's really effective against anything besides blatant ragehacking. AFAICT the general consensus in the community is that Valves own CS:GO servers are still infested with cheaters, and to avoid them you need to go to ESEA or FACEIT (third party CS:GO matchmaking services) or Valorant (Riots CS:GO clone) which all primarily rely on very aggressive clientside scanning solutions.
  - kllrnohj 4y ago
    I suspect for ESEA & FACEIT the most effective aspect of their anticheats is just that they are paid services. If I'm going to cheat at a game, I'm generally going to bias towards minimal consequences if I do get caught. I can say that Valorant's anti cheat is the singular reason I've never tried it, even though I love counter-strike and similar games. Giving game devs (especially those owned by Tencent) ring 0 access is, uh, a step too far I think.

matheusmoreira 4y ago

Yeah. These things have to literally take over the machine in order to even have a chance at preventing anything. They're basically malware at this point. EAC is implemented as a kernel module, at least in Windows. It's bad enough to have to put up with proprietary nvidia drivers, now we're gonna have to tolerate this? It doesn't even work, people will still cheat. I seriously hope these corporations don't start pushing this on Linux gamers. They need to accept that they can't control it and move on.