What if the kernel module is only run in a separate VM than your main one?

Games that require kernel-level anticheat will probably try to detect VMs and refuse to run.

The idea is that the hypervisor would also be signed and provide security guarantees to games to block cheats from working.

▲

digiown 37 minutes ago | parent [-]

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 21 minutes ago | parent [-]

>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 12 minutes ago | parent [-]

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 7 minutes ago | parent [-]

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.

	▲	digiown 2 minutes ago \| parent [-]
		Ah, I see, you're talking about Intel ME/AMD PSP? That's unfortunate and I'm obviously not happy with it, but so far there seems to be no evidence of it being abused against normal users. My answer to your question: No, I don't like it at all, even if I fully trust the hypervisor. It will reduce the barrier for implementing all kinds of anti-user technologies. If that were possible, it will quickly be required to interact with everything, and your arbitrary guest will soon be pretty useless, just like the "integrity" bullshit on Android. Yeah you can boot your rooted AOSP, but good luck interacting with banks, government services (often required by law!!), etc. That's still a net minus.