- secure kernel WILL get hijacked and be completely invisible to anti cheats. Which would be funny.
- Microsoft won't port back the attestation process to win 10 (although secure kernel exists there too), forcing all gamers, where the AC adopts this attestation, to install win11
- trying to lock out Linux for sure, which is a funny coincidence given that Valve is partnering with anti cheat developers (eg EAC and Battleye) to support Linux
Win10 only supports this in specific high-sec enterprise configurations and, as indicated, Microsoft will not be porting that back to Windows 10. One can reasonably expect that Windows 10 support will be killed in favor of this new API, specifically because it means game studios can stop paying for soon-irrelevant development effort into Windows anti-modding. And I bet TF2 starts blocking unattested (and, so, Windows 10) players within one year of Valve enabling the new attestation API on Steam hardware in Windows/Linux.
Linux is and has for years been capable of supporting all of this at any time, and when-not-if Valve enables attestation of a clean sealed-booted Steam Linux environment for their hardware, AAA multiplayer games will begin allowing only sealed-attested Steam Linux players to join multiplayer games from Linux.
Microsoft isn’t doing this to screw Linux. Microsoft is doing this to avoid losing the secured PC gaming market to Valve. They already lost the (secured) console gaming market, after all.
Valve let bots infest and ruin TF2 servers for 8 (eight) years straight before doing anything. There's no way they'd add anything like that to TF2 within one year.
Of course not. They’d just add it to VAC and make it an opt-in flag for all Steam games. And then check that box for TF2 et al., because one click in a metadata editor to lock out 99.999% of software cheaters is a no-brainer for any multiplayer game — including their own! And as a bonus, that’s an upsell driver for sealed-capable hardware like the upcoming Steam console, when people find out that their Win10 PCs can’t access their inventories next year and it’s either Windows 11 or Steam Linux. Mod it all you want for local play, then dual-boot to a competition-grade sealed OS to join lobbies? Hard to see how they’d turn that opportunity down.
They may be partnering with them but support for competitve titles is rather limited. For example, the most prominent Battleye title (iirc), Rainbow Six Siege, is not support on Linux via Steam due to Battleye blocking it. Valorant, LoL, BF6 or CoD also don't work ime.
Particularly frustrating, because Rainbow Six Siege runs spectacularly on linux, but the moment you join a multiplayer session the anticheat forces a crash-to-desktop.
For many of these games it's a choice. They choose not to support linux. Perhaps one day that will change.
I've been playing online multiplayer games, including competitive FPS and more, for nearly 3 decades. Cheating has never been such a problem that it made me quit a game. So much of this is way overplayed by wannabe-super-sweat try-hards, thinking they're competing in high-stakes games.
So we cede more and more control of our computer over to video game(!!) companies, going deep down the rabbit hole of kernel-level anti-cheat and worse to come.
It's a freaking video game... have fun. If someone cheats, find a new server. It's really that simple.
They will need to sooner or later. Linux has more momentum than ever, and saying "players on steam deck/steam machine/bazzite can't play our game" seems like a losing long term strategy.
It's a balance between allowing linux and (theoretically) opening the door for more cheaters. Saying "players can't play our game because every match has a cheater" is just as bad.
I can't say which has more weight but it's not a cut and dry situation, at least until Linux has anti-cheat.
Right now developers could make an "unattested" queue for linux and other non-TPM windows systems. Which could also serve as a black-hole for cheaters, so maybe there's some value in that.
So, the problem with anticheat on Linux is there's no "safe" reference version of Linux that you can enforce to be running. This is a good thing. It's supposed to be modifiable. This fundamentally conflicts with the goal of anticheat which is to stop you modifying it.
I predict they won't allow all Linux but only the specific version Valve puts on the Steam Deck/Machine, and if you modify it then your games won't run again.
Only because desktop Linux will be behind on security.
Macs already got this ability in 2023 which allowed for a user mode anticheat for Riot Games to be made that successfully prevented cheating. Now Windows is getting attestation that is the game running on a secure system.
If desktop Linux ever gets around to this then a anticheats can add support for it and it will be much easier then them needing to make a kernel anticheat for a platform that few people use.
Proving my device's integrity is for me. If I want to modify the code on my device and don't want you to know that I did, that's my right.
Allowing third parties to measure it is a security violation, and a freedom violation if there's no way for me to spoof what I'm running on my device and they block me based on that.
The whole point of remote attestation is to prove integrity of remote machines.
>that's my right.
It's common for states to make fraud unlawful due to being an antisocial behavior. I similarly believe that lying about your the integrity of an app running is similarly antisocial behavior.
>Allowing third parties to measure it is a security violation
How does it break your security model?
>a freedom violation
It turns out that such freedom when given to bad actors turns into the freedom for them to ruin games by cheating. People still have the freedom to do whatever they want on their own computer, but they just can't hack a game and then fraudulently claim they aren't using hacks.
I don’t really understand what that means. Are you, or anyone, expecting a signed Linux kernel by some organization (say Valve or Debian or whatever) that will be the “Gaming Kernel”? If not, no Linux kernel feature is safe from 1 patch and a custom build.
Stock Linux kernel in Fedora, for example, is signed by MS, so SecureBoot allows to boot it without modification. Kernel booted by SecureBoot is locked down by default. To unlock it, you need to patch kernel source, rebuild it, sign it with your own key, and install this key via UEFI to boot it in SecureBoot mode. Your custom key will not pass remote attestation.
They are not signed by MS they are dual signed by a CA that MS runs as a service for UEFI secure boot as well as the distro’s CA.
If you were around in the late 2000s when UEFI SecureBoot was being proposed, you’d remember the massive hysteria about how “SecureBoot is a MS plot to block Linux install”. Even though the proposal was to just allow the UEFI to verify the sig of the binary it’ll boot, and to allow the user to provide the UEFI with the keys to trust, the massive fear was that MB manufacturers will just be too lazy (or be bought by MS) that they will only allow MS keys, or that the process to enlist a new key would be too difficult to sufficiently discourage people from installing Linux (because you know, I’m all for the freedom and fuck-Microsoft camp, until its expected that I verify a signature) so Microsoft offered a service for CA service, like https CAs, but for boot signing.
Assuming you’re a good Linux user, you can always just put your favorite distro signing key in your UEFI without accepting MS CA n there.
Well if you walk backwards 10 paces and look at the big picture here, what MS did enables anti-cheat attestation via TPM, and that in turn can act as a feature that structurally - via the market - reduces the appeal of Linux.
Signing your own custom-built kernel (if you need to adjust flags etc., like I do) won't result in a certification chain that will pass the kind of attestation being sketched out by the OP article here.
Yes because you’re trying to communicate that trust to other players of the game you’re playing as opposed to yourself.
It’s why I hate the term “self-signed” vs “signed” when it comes to tls/https. I always try to explain to junior developers that there is no such a thing as “self-signed”. A “self-signed” certificate isn’t less secure than a “signed” certificate. You are always choosing who you want to trust when it comes to encryption. Out of convenience, you delegate that to the vendor of your OS or browser, but it’s always a choice. But in practice, it’s a very different equation.
I mean the approach the article is talking about. Creating a safe hypervisor and safe kernel that games can get an attestation to in order to trust that they are running on a secure platform.
It’s not a gimmick feature. It’s just the “user” is always, inherently, in “control” of the kernel itself when it comes to Linux. That’s not true with NT or Darwin. You (a 3rd party) can always verify NT or Darwin’s “integrity” by checking it’s cryptographically signed by Microsoft or Apple. Other than assuming that Valve (or Sony, Nintendo, Debian, SUSE, RedHat, etc) is the “trusted kernel” for your game, you can’t do that with Linux. And the moment you say “My application only runs on Kernels signed by {insert organization}, are you really “Linux”?
The reality is the overwhelming majority of desktop linux users are probably using a kernel shipped by their distro, be it Fedora, Debian, Ubuntu, Valve, whatever. Those kernels could be attested.
I agree with your sentiment though. It's a wild future we're considering, just so some people can play video games and complain less about supposed cheaters (or often, skill issues, but I digress).
Yeah, I agree. Majority of people running any OS are expecting a vendor that manages their OS. Even those running Arch are rarely patching things by hand and just following whatever is in the official repos or wiki.
However, I believe part of the huge positive sentiment about “Linux gaming” online is that, so far, it’s been truly “Linux gaming”. Once it becomes “Valve’s Gaming” it’s really no different than PS5 or Switch using Linux for its base OS but it’s really Sony or Nintendo’s device.
In other words - it's up to Microsoft to allow you to do certain things on your own PC, just like it's been on Android with Google for a while now, as if they don't the third parties will just refuse to provide their services to you.
(inb4 "but Microsoft only provides a report that's interpreted by others" - yes, but ultimately it's up to whether Microsoft chooses to sign the content of a report you want to produce)
This is entirely used for anticheat purposes. Ergo, if you want to play with other people in a multiplayer setting, you're required to abide by certain rules: some logical and social, some technical. It's a careful balance between a fully locked down platform (Xbox/PS OS) and just zero measures to prevent cheaters. (No, server-side anticheat is not sufficient, as proven countless times)
You're free to use your hardware as you wish, but if you want to disable the Secure Kernel et al, don't be surprised if the gameserver rejects your connection.
Okay, then I don't get the point you're trying to make. You "slippery slope"'d the Secure Kernel TPM attestation used for multiplayer games into "what if you can't do banking anymore". Like I said (and you agreed), we're already using hardware attestation. So what's the problem with this approach that gets rid of the requirement of anticheat drivers, freeing your hardware? (You can now use that one app that Vanguard preemptively blocks for using a vulnerable driver)
The point is that until now, attestation has not been widely used on PCs, but we can observe this changing and bringing in the pain points known from other platforms.
Sure, but then Riot wouldn't trust these signatures anymore and we would go right back to kernel mode anticheat. Microsoft allowing insecure changes to the secure kernel undermines the whole point of it.
>We can already see that on other platforms.
And it doesnt prevent you from using those devices how you want.
It does, because when you do, "the third parties (...) just refuse to provide their services to you". Anyone who uses an Android device that doesn't pass the attestation know this well.
>the third parties (...) just refuse to provide their services to you
1. The third parties are not your device.
2. This only prevents their app from attesting in the insecure kernel. You can still use the app with it loaded in the secure kernel.
>Anyone who uses an Android device that doesn't pass the attestation know this well.
This is quite different because no Android operating system lets you transparently run those apps in a secure vm that would pass attestation. Needing to reflash your device is totally different than the OS transparently loading the app in a secure environment.
The end result is that you're restricted from computing on your own device if you wish to participate in the society. Only pre-approved software gets a pass.
> You can still use the app with it loaded in the secure kernel.
That's not how it works. The secure kernel is the one that attests the report regardless of whether the user kernel has been modified or not, and the application itself does not run in the secure realm at all. It's quite similar to how it works on Android.
> This is quite different because no Android operating system lets you transparently run those apps in a secure vm that would pass attestation.
Sorry, I don't understand what you're talking about here. You're not going to pass this attestation process inside a VM, or to be more exact: you'll get a signed report that effectively signals "don't accept this client" to the server.
>you're restricted from computing on your own device if you wish to participate in the society.
You are restricted from hiding that you tampered with apps from servers that ask for it. You can still do whatever computing you want on your device. The fact that an app required for society has to run in a secure vm, doesn't take away from all that you can do with the rest of your system.
>That's not how it works.
Please take a charitable interpretation. What you are saying is what I meant. The app is using the secure kernel instead of an unsecured one you may have for extra computing freedom.
>I don't understand what you're talking about here.
I'm talking about adopting the approach Windows is taking but on Android. Allowing both insecure and secure virtual machines running on the same host, seamlessly integrated so the user can't tell.
>You're not going to pass this attestation process inside a VM
Yes, you are. Android VMs are designed to be isolated which means that you could have one VM that is fully trusted, and one that isn't. So you can do all your crazy things in the insecure vm while simultaneously having another secure vm available for apps that need it. The hypervisor ensures that this would be secure.
> You can still do whatever computing you want on your device.
Maybe there's some alternate reality where that's the case, but it's not this one.
> Please take a charitable interpretation. What you are saying is what I meant.
It's hard to figure out what you meant, you seem confused about how this works. Have you read the article? "Secure Kernel" is what Microsoft calls the piece of software that runs within the trusted context and is distinct from the NT kernel which state it inspects and attests.
> It's perfectly accurate, as Microsoft could let you use Riot's servers without using the secure kernel if they wanted to.
And then you're back to needing to load vgk.sys at boot time to play a Riot game. And that's dramatically worse as anticheats like Vanguard do PCIE & DMA screening, vulnerable driver blocklist enforcement, and other hardening at boot time.
The fence you're trying to maintain is already broken on both sides: media DRM (Widevine) does hardware attestation. TPM attestation already exists. Macs don't let you connect to some Apple services without a hardware-sourced ticket. Secure Boot enforcement and requirement by some apps is already a thing.
I don’t think this is really true… you can choose to opt in to this limitation, and in return you can play certain games that have this type of anti-cheat. Or, you can choose to not opt in, and then you can’t play those particular games.
The only thing Microsoft is preventing you from doing on your own PC is having Microsoft lie to the other piece of software.
I reckon hackers get a thrill out of doing the inputs themselves. They seem to be able to disregard the fact they've got an unfair advantage, pretending that they are still achieving something by their acts.
Where vision based AI will start running riot is in games like Runescape where macroing is a huge problem. I expect it will become undetectable and therefore unbannable.
That's still an improvement over the current state of games. Cheats being able to read hidden game state is a huge advantage vs. just what is visible on screen.
No, it just leads to subtler cheating. Closet cheaters are much worse than obvious ones, and they thrive in exactly these conditions: the game is not too broken by rage mode cheaters so there's a lot of fair players they're preying on, they have an inconspicuous advantage, and the advantage is gatekept with some entry barrier so there aren't too many of them.
You can have a fully encrypted and attested click-to-photon DRM chain, but it will just a) turn your computer into an appliance and b) cause even worse cheating.
People already closet cheat to avoid detection. It's nothing new.
You can closet cheat with ESP and that is very game breaking without obvious rage cheating. You can't do ESP if cheats are limited to what is visible on screen so I would say it's an improvement. Even something like autoaim is a bit less effective because it wouldn't be able to snap on players who are offscreen. The gap between cheating and legit players would be reduced which makes it less frustrating for the legit players and probably less tempting for cheaters.
You're right, but developers don't really care about cheaters cheating. They care about cheaters ruining the game to others, so closet cheaters are not such a big deal to them even when they're thriving as long as they remain closeted.
There's nothing good about this, and you'll be surprised how many people are willing to spend more than $1k/mo just to cheat in video games. Your game will still be ruined in a worse way, and every step towards the full lock-in just makes this closer. As I said, closet cheaters are MUCH worse than obvious ones, and much harder to catch (and for the context, I used to host very popular servers for several games, so I've seen player complaints and retention rates).
Here's my previous comment about what it takes to actually eliminate cheaters. Anticheats are only marginally helpful in this, it's all about observability, manual control, and community building. https://news.ycombinator.com/item?id=46139481
Intrusive DRM schemes will just take any semblance of computing freedom away from you, while actually making the problem worse in the end.
Which is a pretty naive view of the cheating landscape that ignores everything I posted above. Enforcing the rules by technical means is largely superficial everywhere except the actual esports, the culture around the multiplayer gaming (both esports and not) needs to change.
Those, who has better ping, bigger screen, better video card, better mouse, always have advantage over those who haven't. Adapt. There is no fair game in the real life.
At the level of League of Legends me and my friend group play, we never noticed cheaters. We play casual ARAM games. Never noticed any hackers or anything.
But we definitely notice when at the start of the game, one of our team didnt actually get past the loading screen because Vanguard decided instead they need to reboot their machine. And then good luck winning when you are down a player for several minutes.
It doesn’t happen often, but it happens way more often than cheaters did. And this bug happens to multiple people in my friend group. This anti cheat software is extremely buggy. And causes way more problems than it solves for us.
I wish i could say “but the software is improving” because the last few weeks it’s been fine, until literally yesterday. I got out of fountain and into combat and then got a “Vanguard must be running” popup. It kicked me out and I couldn’t get back in until I rebooted. And then if you open league too fast after the reboot, because you are hurrying to get back in, you can actually open League before Vanguard starts and then too bad you have to reboot again!
There's some ML image-based cheats out there but they're much worse (and have been for years). Some games have sidestepped this with tiny imperceptible color changes to nametags & outlines to throw off the cheats while not bothering a human player.
I don't get why a bad guy couldn't dump the current log / hash, then load a kernel module that'd just replay the same values whenever someone asks for it?
Does the log have a challenge/nonce from the client that'd change the hash everytime it's obtained? (if the client loads their own kernel module they can check it's on the list, but the whole point is about not having to do that, right..)
I've said this before, but given how fast machines can boot these days, why not simply reboot into a secure boot attested environment with minimal things loading besides the game.
i.e. why not simply make it "XBox for the PC" and leverage both PC and XBox gaming together. There should be no difference to a developer of an "XBox for the PC" and XBox development besides XBox giving you an exact performance config. One codes the same, one has the same resources made available to them and so forth and then one doesn't need anti-cheat (i.e. I'm making an assumption that there's no real need for invasive anti-cheat on xbox / ps platforms).
If I was being conspiracy minded, I might argue that Microsoft doesn't do this, because if one simply reverted to a trusted/attested platform, it be easy for valve to provide the same on a steam deck. If one is booted into a trusted/attested mode on the steam deck, these games that eschew invasive anti-cheat due to trusting the platform could do the same on the steam deck if it provided such a mode. So by enabling invasive anti-cheat, they create a form of lock-in.
Some thoughts
- secure kernel WILL get hijacked and be completely invisible to anti cheats. Which would be funny.
- Microsoft won't port back the attestation process to win 10 (although secure kernel exists there too), forcing all gamers, where the AC adopts this attestation, to install win11
- trying to lock out Linux for sure, which is a funny coincidence given that Valve is partnering with anti cheat developers (eg EAC and Battleye) to support Linux
Win10 only supports this in specific high-sec enterprise configurations and, as indicated, Microsoft will not be porting that back to Windows 10. One can reasonably expect that Windows 10 support will be killed in favor of this new API, specifically because it means game studios can stop paying for soon-irrelevant development effort into Windows anti-modding. And I bet TF2 starts blocking unattested (and, so, Windows 10) players within one year of Valve enabling the new attestation API on Steam hardware in Windows/Linux.
Linux is and has for years been capable of supporting all of this at any time, and when-not-if Valve enables attestation of a clean sealed-booted Steam Linux environment for their hardware, AAA multiplayer games will begin allowing only sealed-attested Steam Linux players to join multiplayer games from Linux.
Microsoft isn’t doing this to screw Linux. Microsoft is doing this to avoid losing the secured PC gaming market to Valve. They already lost the (secured) console gaming market, after all.
Valve let bots infest and ruin TF2 servers for 8 (eight) years straight before doing anything. There's no way they'd add anything like that to TF2 within one year.
Of course not. They’d just add it to VAC and make it an opt-in flag for all Steam games. And then check that box for TF2 et al., because one click in a metadata editor to lock out 99.999% of software cheaters is a no-brainer for any multiplayer game — including their own! And as a bonus, that’s an upsell driver for sealed-capable hardware like the upcoming Steam console, when people find out that their Win10 PCs can’t access their inventories next year and it’s either Windows 11 or Steam Linux. Mod it all you want for local play, then dual-boot to a competition-grade sealed OS to join lobbies? Hard to see how they’d turn that opportunity down.
do you know when a Steam switched to a 64 bit executable?
last month
valve are not the company you think they are
There was no inherent profit or other benefit to Valve from doing so. Of course they didn’t bother.
> EAC and Battleye
They may be partnering with them but support for competitve titles is rather limited. For example, the most prominent Battleye title (iirc), Rainbow Six Siege, is not support on Linux via Steam due to Battleye blocking it. Valorant, LoL, BF6 or CoD also don't work ime.
Particularly frustrating, because Rainbow Six Siege runs spectacularly on linux, but the moment you join a multiplayer session the anticheat forces a crash-to-desktop.
For many of these games it's a choice. They choose not to support linux. Perhaps one day that will change.
I've been playing online multiplayer games, including competitive FPS and more, for nearly 3 decades. Cheating has never been such a problem that it made me quit a game. So much of this is way overplayed by wannabe-super-sweat try-hards, thinking they're competing in high-stakes games.
So we cede more and more control of our computer over to video game(!!) companies, going deep down the rabbit hole of kernel-level anti-cheat and worse to come.
It's a freaking video game... have fun. If someone cheats, find a new server. It's really that simple.
They will need to sooner or later. Linux has more momentum than ever, and saying "players on steam deck/steam machine/bazzite can't play our game" seems like a losing long term strategy.
It's a balance between allowing linux and (theoretically) opening the door for more cheaters. Saying "players can't play our game because every match has a cheater" is just as bad.
I can't say which has more weight but it's not a cut and dry situation, at least until Linux has anti-cheat.
Right now developers could make an "unattested" queue for linux and other non-TPM windows systems. Which could also serve as a black-hole for cheaters, so maybe there's some value in that.
So, the problem with anticheat on Linux is there's no "safe" reference version of Linux that you can enforce to be running. This is a good thing. It's supposed to be modifiable. This fundamentally conflicts with the goal of anticheat which is to stop you modifying it.
I predict they won't allow all Linux but only the specific version Valve puts on the Steam Deck/Machine, and if you modify it then your games won't run again.
That hasn't stopped Android from offering attestation while they use Linux.
>It's supposed to be modifiable.
https://www.kernel.org/linux.html
I have not seen that as a project goal.
>trying to lock out Linux
Only because desktop Linux will be behind on security.
Macs already got this ability in 2023 which allowed for a user mode anticheat for Riot Games to be made that successfully prevented cheating. Now Windows is getting attestation that is the game running on a secure system.
If desktop Linux ever gets around to this then a anticheats can add support for it and it will be much easier then them needing to make a kernel anticheat for a platform that few people use.
I absolutely won't call client side anti-cheat a "security" feature and I find the framing very questionable.
This is specifically an integrity feature. And integrity is typically classified under security.
It is however integrity on behalf of a third party, and possibly antagonistic to the user.
Proving my device's integrity is for me. If I want to modify the code on my device and don't want you to know that I did, that's my right.
Allowing third parties to measure it is a security violation, and a freedom violation if there's no way for me to spoof what I'm running on my device and they block me based on that.
The whole point of remote attestation is to prove integrity of remote machines.
>that's my right.
It's common for states to make fraud unlawful due to being an antisocial behavior. I similarly believe that lying about your the integrity of an app running is similarly antisocial behavior.
>Allowing third parties to measure it is a security violation
How does it break your security model?
>a freedom violation
It turns out that such freedom when given to bad actors turns into the freedom for them to ruin games by cheating. People still have the freedom to do whatever they want on their own computer, but they just can't hack a game and then fraudulently claim they aren't using hacks.
> If desktop Linux ever gets around to this
I don’t really understand what that means. Are you, or anyone, expecting a signed Linux kernel by some organization (say Valve or Debian or whatever) that will be the “Gaming Kernel”? If not, no Linux kernel feature is safe from 1 patch and a custom build.
Stock Linux kernel in Fedora, for example, is signed by MS, so SecureBoot allows to boot it without modification. Kernel booted by SecureBoot is locked down by default. To unlock it, you need to patch kernel source, rebuild it, sign it with your own key, and install this key via UEFI to boot it in SecureBoot mode. Your custom key will not pass remote attestation.
They are not signed by MS they are dual signed by a CA that MS runs as a service for UEFI secure boot as well as the distro’s CA.
If you were around in the late 2000s when UEFI SecureBoot was being proposed, you’d remember the massive hysteria about how “SecureBoot is a MS plot to block Linux install”. Even though the proposal was to just allow the UEFI to verify the sig of the binary it’ll boot, and to allow the user to provide the UEFI with the keys to trust, the massive fear was that MB manufacturers will just be too lazy (or be bought by MS) that they will only allow MS keys, or that the process to enlist a new key would be too difficult to sufficiently discourage people from installing Linux (because you know, I’m all for the freedom and fuck-Microsoft camp, until its expected that I verify a signature) so Microsoft offered a service for CA service, like https CAs, but for boot signing.
Assuming you’re a good Linux user, you can always just put your favorite distro signing key in your UEFI without accepting MS CA n there.
Well if you walk backwards 10 paces and look at the big picture here, what MS did enables anti-cheat attestation via TPM, and that in turn can act as a feature that structurally - via the market - reduces the appeal of Linux.
Signing your own custom-built kernel (if you need to adjust flags etc., like I do) won't result in a certification chain that will pass the kind of attestation being sketched out by the OP article here.
Yes because you’re trying to communicate that trust to other players of the game you’re playing as opposed to yourself.
It’s why I hate the term “self-signed” vs “signed” when it comes to tls/https. I always try to explain to junior developers that there is no such a thing as “self-signed”. A “self-signed” certificate isn’t less secure than a “signed” certificate. You are always choosing who you want to trust when it comes to encryption. Out of convenience, you delegate that to the vendor of your OS or browser, but it’s always a choice. But in practice, it’s a very different equation.
The problem comes in when you need to flip a flag that isn't set in the default kernel build for compatibility with your hardware and configuration.
Exactly, then you are depending on that third party (be it MS, Apple, Valve, Debian, etc) to care enough about your obscure setup to support it.
Many people would be happy with a Valve gaming kernel.
Many are happy with a Sony gaming kernel as is.
I mean the approach the article is talking about. Creating a safe hypervisor and safe kernel that games can get an attestation to in order to trust that they are running on a secure platform.
Yeah, then the “safe kernel” is Valve’s kernel.
Kernel anti cheat in windows has already been used to deploy malware.
It was inevitable when this even started.
it will be behind on security gimmicks
It’s not a gimmick feature. It’s just the “user” is always, inherently, in “control” of the kernel itself when it comes to Linux. That’s not true with NT or Darwin. You (a 3rd party) can always verify NT or Darwin’s “integrity” by checking it’s cryptographically signed by Microsoft or Apple. Other than assuming that Valve (or Sony, Nintendo, Debian, SUSE, RedHat, etc) is the “trusted kernel” for your game, you can’t do that with Linux. And the moment you say “My application only runs on Kernels signed by {insert organization}, are you really “Linux”?
The reality is the overwhelming majority of desktop linux users are probably using a kernel shipped by their distro, be it Fedora, Debian, Ubuntu, Valve, whatever. Those kernels could be attested.
I agree with your sentiment though. It's a wild future we're considering, just so some people can play video games and complain less about supposed cheaters (or often, skill issues, but I digress).
Yeah, I agree. Majority of people running any OS are expecting a vendor that manages their OS. Even those running Arch are rarely patching things by hand and just following whatever is in the official repos or wiki.
However, I believe part of the huge positive sentiment about “Linux gaming” online is that, so far, it’s been truly “Linux gaming”. Once it becomes “Valve’s Gaming” it’s really no different than PS5 or Switch using Linux for its base OS but it’s really Sony or Nintendo’s device.
In other words - it's up to Microsoft to allow you to do certain things on your own PC, just like it's been on Android with Google for a while now, as if they don't the third parties will just refuse to provide their services to you.
(inb4 "but Microsoft only provides a report that's interpreted by others" - yes, but ultimately it's up to whether Microsoft chooses to sign the content of a report you want to produce)
This is entirely used for anticheat purposes. Ergo, if you want to play with other people in a multiplayer setting, you're required to abide by certain rules: some logical and social, some technical. It's a careful balance between a fully locked down platform (Xbox/PS OS) and just zero measures to prevent cheaters. (No, server-side anticheat is not sufficient, as proven countless times)
You're free to use your hardware as you wish, but if you want to disable the Secure Kernel et al, don't be surprised if the gameserver rejects your connection.
Entirely anticheat, then DRM, then banking, then...
We already have media DRM using other methods that aren't as restrictive as you make it out to be. This slippery slope doesn't work.
The most popular consumer OS out there is already past that slope.
Okay, then I don't get the point you're trying to make. You "slippery slope"'d the Secure Kernel TPM attestation used for multiplayer games into "what if you can't do banking anymore". Like I said (and you agreed), we're already using hardware attestation. So what's the problem with this approach that gets rid of the requirement of anticheat drivers, freeing your hardware? (You can now use that one app that Vanguard preemptively blocks for using a vulnerable driver)
The point is that until now, attestation has not been widely used on PCs, but we can observe this changing and bringing in the pain points known from other platforms.
This is not accurate. It would be more like:
Riot would not let you use their servers to play League of Legends with others if you were not using the secure kernel.
You are still able to do whatever you want with your own PC, but you can't force others to let you play with them when they don't trust you.
It's perfectly accurate, as Microsoft could let you use Riot's servers without using the secure kernel if they wanted to.
And it will not be just game servers. We can already see that on other platforms.
Sure, but then Riot wouldn't trust these signatures anymore and we would go right back to kernel mode anticheat. Microsoft allowing insecure changes to the secure kernel undermines the whole point of it.
>We can already see that on other platforms.
And it doesnt prevent you from using those devices how you want.
It does, because when you do, "the third parties (...) just refuse to provide their services to you". Anyone who uses an Android device that doesn't pass the attestation know this well.
>the third parties (...) just refuse to provide their services to you
1. The third parties are not your device.
2. This only prevents their app from attesting in the insecure kernel. You can still use the app with it loaded in the secure kernel.
>Anyone who uses an Android device that doesn't pass the attestation know this well.
This is quite different because no Android operating system lets you transparently run those apps in a secure vm that would pass attestation. Needing to reflash your device is totally different than the OS transparently loading the app in a secure environment.
> The third parties are not your device.
Nobody says they are, but that's a distinction without difference: https://news.ycombinator.com/item?id=46555963
The end result is that you're restricted from computing on your own device if you wish to participate in the society. Only pre-approved software gets a pass.
> You can still use the app with it loaded in the secure kernel.
That's not how it works. The secure kernel is the one that attests the report regardless of whether the user kernel has been modified or not, and the application itself does not run in the secure realm at all. It's quite similar to how it works on Android.
> This is quite different because no Android operating system lets you transparently run those apps in a secure vm that would pass attestation.
Sorry, I don't understand what you're talking about here. You're not going to pass this attestation process inside a VM, or to be more exact: you'll get a signed report that effectively signals "don't accept this client" to the server.
>you're restricted from computing on your own device if you wish to participate in the society.
You are restricted from hiding that you tampered with apps from servers that ask for it. You can still do whatever computing you want on your device. The fact that an app required for society has to run in a secure vm, doesn't take away from all that you can do with the rest of your system.
>That's not how it works.
Please take a charitable interpretation. What you are saying is what I meant. The app is using the secure kernel instead of an unsecured one you may have for extra computing freedom.
>I don't understand what you're talking about here.
I'm talking about adopting the approach Windows is taking but on Android. Allowing both insecure and secure virtual machines running on the same host, seamlessly integrated so the user can't tell.
>You're not going to pass this attestation process inside a VM
Yes, you are. Android VMs are designed to be isolated which means that you could have one VM that is fully trusted, and one that isn't. So you can do all your crazy things in the insecure vm while simultaneously having another secure vm available for apps that need it. The hypervisor ensures that this would be secure.
> You can still do whatever computing you want on your device.
Maybe there's some alternate reality where that's the case, but it's not this one.
> Please take a charitable interpretation. What you are saying is what I meant.
It's hard to figure out what you meant, you seem confused about how this works. Have you read the article? "Secure Kernel" is what Microsoft calls the piece of software that runs within the trusted context and is distinct from the NT kernel which state it inspects and attests.
> Anyone who uses an Android device that doesn't pass the attestation know this well.
Speaking of which, tangentially, what are the latest workaround for play integrity these days?
> It's perfectly accurate, as Microsoft could let you use Riot's servers without using the secure kernel if they wanted to.
And then you're back to needing to load vgk.sys at boot time to play a Riot game. And that's dramatically worse as anticheats like Vanguard do PCIE & DMA screening, vulnerable driver blocklist enforcement, and other hardening at boot time.
The fence you're trying to maintain is already broken on both sides: media DRM (Widevine) does hardware attestation. TPM attestation already exists. Macs don't let you connect to some Apple services without a hardware-sourced ticket. Secure Boot enforcement and requirement by some apps is already a thing.
I don’t think this is really true… you can choose to opt in to this limitation, and in return you can play certain games that have this type of anti-cheat. Or, you can choose to not opt in, and then you can’t play those particular games.
The only thing Microsoft is preventing you from doing on your own PC is having Microsoft lie to the other piece of software.
You may want to look up what SafetyNet Attestation and Play Integrity APIs are being used for.
The future of serious cheating is probably a second machine watching the video and playing the game.
I reckon hackers get a thrill out of doing the inputs themselves. They seem to be able to disregard the fact they've got an unfair advantage, pretending that they are still achieving something by their acts.
Where vision based AI will start running riot is in games like Runescape where macroing is a huge problem. I expect it will become undetectable and therefore unbannable.
I could see a vision based solution being popular in an mmo too. Gold farming is lucrative.
That's still an improvement over the current state of games. Cheats being able to read hidden game state is a huge advantage vs. just what is visible on screen.
No, it just leads to subtler cheating. Closet cheaters are much worse than obvious ones, and they thrive in exactly these conditions: the game is not too broken by rage mode cheaters so there's a lot of fair players they're preying on, they have an inconspicuous advantage, and the advantage is gatekept with some entry barrier so there aren't too many of them.
You can have a fully encrypted and attested click-to-photon DRM chain, but it will just a) turn your computer into an appliance and b) cause even worse cheating.
People already closet cheat to avoid detection. It's nothing new.
You can closet cheat with ESP and that is very game breaking without obvious rage cheating. You can't do ESP if cheats are limited to what is visible on screen so I would say it's an improvement. Even something like autoaim is a bit less effective because it wouldn't be able to snap on players who are offscreen. The gap between cheating and legit players would be reduced which makes it less frustrating for the legit players and probably less tempting for cheaters.
You're right, but developers don't really care about cheaters cheating. They care about cheaters ruining the game to others, so closet cheaters are not such a big deal to them even when they're thriving as long as they remain closeted.
Good! It would push down the cheating down to really low percentages. It won’t be easy for a script kiddie to just download any cheat.
There's nothing good about this, and you'll be surprised how many people are willing to spend more than $1k/mo just to cheat in video games. Your game will still be ruined in a worse way, and every step towards the full lock-in just makes this closer. As I said, closet cheaters are MUCH worse than obvious ones, and much harder to catch (and for the context, I used to host very popular servers for several games, so I've seen player complaints and retention rates).
Here's my previous comment about what it takes to actually eliminate cheaters. Anticheats are only marginally helpful in this, it's all about observability, manual control, and community building. https://news.ycombinator.com/item?id=46139481
Intrusive DRM schemes will just take any semblance of computing freedom away from you, while actually making the problem worse in the end.
If we could eliminate all cheaters down to those willing to spend $1000 per month to cheat, I would consider the war won
Which is a pretty naive view of the cheating landscape that ignores everything I posted above. Enforcing the rules by technical means is largely superficial everywhere except the actual esports, the culture around the multiplayer gaming (both esports and not) needs to change.
Those, who has better ping, bigger screen, better video card, better mouse, always have advantage over those who haven't. Adapt. There is no fair game in the real life.
I don’t think it is an improvement.
At the level of League of Legends me and my friend group play, we never noticed cheaters. We play casual ARAM games. Never noticed any hackers or anything.
But we definitely notice when at the start of the game, one of our team didnt actually get past the loading screen because Vanguard decided instead they need to reboot their machine. And then good luck winning when you are down a player for several minutes.
It doesn’t happen often, but it happens way more often than cheaters did. And this bug happens to multiple people in my friend group. This anti cheat software is extremely buggy. And causes way more problems than it solves for us.
I wish i could say “but the software is improving” because the last few weeks it’s been fine, until literally yesterday. I got out of fountain and into combat and then got a “Vanguard must be running” popup. It kicked me out and I couldn’t get back in until I rebooted. And then if you open league too fast after the reboot, because you are hurrying to get back in, you can actually open League before Vanguard starts and then too bad you have to reboot again!
This youtuber had an interesting approach: https://www.youtube.com/watch?v=pjJImfcQGjI
"Neuromuscular Cyborg Aim Assist"
There's some ML image-based cheats out there but they're much worse (and have been for years). Some games have sidestepped this with tiny imperceptible color changes to nametags & outlines to throw off the cheats while not bothering a human player.
[dead]
I don't get why a bad guy couldn't dump the current log / hash, then load a kernel module that'd just replay the same values whenever someone asks for it? Does the log have a challenge/nonce from the client that'd change the hash everytime it's obtained? (if the client loads their own kernel module they can check it's on the list, but the whole point is about not having to do that, right..)
I've said this before, but given how fast machines can boot these days, why not simply reboot into a secure boot attested environment with minimal things loading besides the game.
i.e. why not simply make it "XBox for the PC" and leverage both PC and XBox gaming together. There should be no difference to a developer of an "XBox for the PC" and XBox development besides XBox giving you an exact performance config. One codes the same, one has the same resources made available to them and so forth and then one doesn't need anti-cheat (i.e. I'm making an assumption that there's no real need for invasive anti-cheat on xbox / ps platforms).
If I was being conspiracy minded, I might argue that Microsoft doesn't do this, because if one simply reverted to a trusted/attested platform, it be easy for valve to provide the same on a steam deck. If one is booted into a trusted/attested mode on the steam deck, these games that eschew invasive anti-cheat due to trusting the platform could do the same on the steam deck if it provided such a mode. So by enabling invasive anti-cheat, they create a form of lock-in.