5 ms·

I'd be less antianticheat if I could just select the handcuffs at boot time for the rare occasion where I need them. Although even then I'd still have qualms a

I'd be less antianticheat if I could just select the handcuffs at boot time for the rare occasion where I need them. Although even then I'd still have qualms about paying for the creation of something that might pave the path for hardware vendors to work with authoritarian governments to restrict users to approved kernel builds. The potential harms are just not in the same league as whatever problems it might solve for gamers.

digiown 10mo ago
Once a slave, always a slave. Running an explicitly anti-user proprietary kernel module that does god-knows-what is not something I'd ever be willing to do, games be damned. It might just inject exploits into all of your binaries and you'd be none the wiser. Since it wouldn't work on VMs you'd have to use a dedicated physical machine for it. Seems to high of a price to play just a few games.
- charcircuit 10mo ago
  What if the kernel module is only run in a separate VM than your main one?
  - Delk 10mo ago
    Games that require kernel-level anticheat will probably try to detect VMs and refuse to run.
    - charcircuit 10mo ago
      The idea is that the hypervisor would also be signed and provide security guarantees to games to block cheats from working.
      - digiown 10mo ago
        Being able to snapshot and restore memory is a pretty common feature across all decent hypervisors. That in and of itself enables most client-side cheats. I doubt they'd bother to provide such a hypervisor for the vanishingly small intersection of people who: - Want to play these adversarial games - Don't care about compromising control of hypervisor - Don't simply have a dedicated gaming box
        charcircuit 10mo ago
        >Being able to snapshot and restore memory is a pretty common feature across all decent hypervisors A hypervisor that protects against this already exists for Linux with Android's pKVM. Android properly enforces isolation between all guests. Desktop Linux distros are way behind in terms of security compared to Android. If desktop Linux users ever want L1 DRM to work to get access to high resolution movies and such they are going to need such a hypervisor. This is not a niche use case.
        digiown 10mo ago
        It "protects" against this given the user already does not control the hypervisor, at which point all bets are off with regard to your rights anyway. It's actually worse than Windows in this regard. I would never use a computer I don't have full control over as my main desktop, especially not to satisfy an external party's desire for control. It seems a lot more convenient to just use a separate machine. Even mainstream consumers are getting tired of DRM crap ruining their games and movies. I doubt there is a significant Linux users would actually want to compromise their ownership of the computer just to watch movies or play games. I do agree that Linux userland security is lackluster though. Flatpak seems to be a neat advancement, at least in regard to stopping things from basically uploading your filesystems. There is already a lot of kernel interfaces that can do this like user namespaces. I wish someone would come up with something like QubesOS, but making use of containers instead of VMs and Wayland proxies for better performance.
        charcircuit 10mo ago
        You already don't control the firmware on the CPU. Would you be okay with this if the hypervisor was moved into the firmware of the CPU and other components instead? I honestly think you would be content as long as the computer offered the ability to host an arbitrary operating system just like has always been possible. Just because there may be an optional guest running that you can't fully control that doesn't take away from the ability to have an arbitrary guest you can fully customize. >to satisfy an external party's desire for control. The external party is reflecting the average consumer's demand for there not being cheaters in the game they are playing. >It seems a lot more convenient to just use a separate machine. It really isn't. It's much more convenient to launch a game on the computer you are already using than going to a separate one.
- cindyllm 10mo ago
  [dead]
- cindyllm 10mo ago
  [dead]

digiown 10mo ago

Once a slave, always a slave. Running an explicitly anti-user proprietary kernel module that does god-knows-what is not something I'd ever be willing to do, games be damned. It might just inject exploits into all of your binaries and you'd be none the wiser. Since it wouldn't work on VMs you'd have to use a dedicated physical machine for it. Seems to high of a price to play just a few games.

charcircuit 10mo ago
What if the kernel module is only run in a separate VM than your main one?
- Delk 10mo ago
  Games that require kernel-level anticheat will probably try to detect VMs and refuse to run.
  - charcircuit 10mo ago
    The idea is that the hypervisor would also be signed and provide security guarantees to games to block cheats from working.
    - digiown 10mo ago
      Being able to snapshot and restore memory is a pretty common feature across all decent hypervisors. That in and of itself enables most client-side cheats. I doubt they'd bother to provide such a hypervisor for the vanishingly small intersection of people who: - Want to play these adversarial games - Don't care about compromising control of hypervisor - Don't simply have a dedicated gaming box
      - charcircuit 10mo ago
        >Being able to snapshot and restore memory is a pretty common feature across all decent hypervisors A hypervisor that protects against this already exists for Linux with Android's pKVM. Android properly enforces isolation between all guests. Desktop Linux distros are way behind in terms of security compared to Android. If desktop Linux users ever want L1 DRM to work to get access to high resolution movies and such they are going to need such a hypervisor. This is not a niche use case.
        digiown 10mo ago
        It "protects" against this given the user already does not control the hypervisor, at which point all bets are off with regard to your rights anyway. It's actually worse than Windows in this regard. I would never use a computer I don't have full control over as my main desktop, especially not to satisfy an external party's desire for control. It seems a lot more convenient to just use a separate machine. Even mainstream consumers are getting tired of DRM crap ruining their games and movies. I doubt there is a significant Linux users would actually want to compromise their ownership of the computer just to watch movies or play games. I do agree that Linux userland security is lackluster though. Flatpak seems to be a neat advancement, at least in regard to stopping things from basically uploading your filesystems. There is already a lot of kernel interfaces that can do this like user namespaces. I wish someone would come up with something like QubesOS, but making use of containers instead of VMs and Wayland proxies for better performance.
        charcircuit 10mo ago
        You already don't control the firmware on the CPU. Would you be okay with this if the hypervisor was moved into the firmware of the CPU and other components instead? I honestly think you would be content as long as the computer offered the ability to host an arbitrary operating system just like has always been possible. Just because there may be an optional guest running that you can't fully control that doesn't take away from the ability to have an arbitrary guest you can fully customize. >to satisfy an external party's desire for control. The external party is reflecting the average consumer's demand for there not being cheaters in the game they are playing. >It seems a lot more convenient to just use a separate machine. It really isn't. It's much more convenient to launch a game on the computer you are already using than going to a separate one.
cindyllm 10mo ago
[dead]
cindyllm 10mo ago
[dead]