it's likely that Microsoft will also attempt to move anti-cheat vendors out of kernel space
[Citation needed]
A place to discuss and support all things Steam Deck.
Replacement for r/steamdeck_linux.
As Lemmy doesn't have flairs yet, you can use these prefixes to indicate what type of post you have made, eg:
[Flair] My post title
The following is a list of suggested flairs:
[Discussion] - General discussion.
[Help] - A request for help or support.
[News] - News about the deck.
[PSA] - Sharing important information.
[Game] - News / info about a game on the deck.
[Update] - An update to a previous post.
[Meta] - Discussion about this community.
Some more Steam Deck specific flairs:
[Boot Screen] - Custom boot screens/videos.
[Selling] - If you are selling your deck.
These are not enforced, but they are encouraged.
Rules:
it's likely that Microsoft will also attempt to move anti-cheat vendors out of kernel space
[Citation needed]
It seems like the point is that Microsoft would be developing some sort of alternative to the kernel with similar functionality for antivirus providers, that doesn't need to have kernel level access. Anticheat uses a lot of the same techniques as kernel level antivirus to detect malware, thus it would probably have to adapt to this new system.
I think the article is more commenting on how Microsoft is directly partnering with antivirus companies for this new system right now, while they're not directly partnering with anticheat companies, even though they'd probably have to migrate to this new system regardless.
This is what, the fourth time a Linux community gets excited about this? But that's actually not good for us at all. Much like Android's safety net, or the nightmare that is the Mac equivalent, the entire point will be creating an untouchable chain from the firmware to the final OS being booted, and only allowing some apps to use a specific API to attest this isn't compromised.
This is horrendous for people trying to modify the OS or, in a more relevant tone, run programs meant for that OS on an entirely different environment. Microsoft has slowly been moving towards making this work on PCs, mostly due to pressure from DRM providers like Netflix or banking apps, but unlike Apple they can't simply lock everything down at once and say "deal with it" because Windows lives by backwards compatibility. Either way, this is just another step towards this upcoming future.
If your favorite games now start asking Windows if the chain of trust is not tampered with... say goodbye to compatibility with Proton.
I'm not sure this will be an issue.
When a piece of software is checking for chain of trust, it's done primarily for security or DRM reasons. The benefits of verifying this chain of trust would make it a little harder for cheaters to inject code and it would be an extra hurdle for pirates to overcome, but the cost is that everyone that bought your game with the intent of playing it on Linux now has absolutely no way to make that happen. I'm not sure the loss in ~4% of your sales would be worth the benefit.
I never understood kernel level anti-cheat. People STILL cheat. lol
To be fair, it certainly still makes cheating harder. If it didn't exist, you'd just see even more people cheating, but it's a pretty overkill way of system monitoring for such a relatively small benefit by comparison.
Massive privacy risk, only slightly better performance than other non-kernel monitoring.
You realize this'll occur at the expense of Microsoft treating the user as an untrustworthy enemy.
This means modding (even for offline play) will not be allowed. Heck, even modify ini files might be viewed as "hacking".
I agree removing the need for anti-cheat in principal sounds nice, but this means archiving games or porting them to "unsupported platforms" will be relics of the past.
I don't think it would go that far, I don't think they can go that far? Stopping people from editing text files basically is what you are saying?
I believe that's just fear-mongering. This has been a thing that Microsoft has wanted to do for a while, largely because having 3rd party code with direct kernel access is a huge problem in terms of stability and security unless you can be sure you know what all that code is doing.
They tried to do this in the past, arguing that anything that wanted kernel-level access had to Windows API calls instead, however Windows Defender which was bundled with the OS was exempt from this restriction. The EU argued that it gave Microsoft a competitive advantage in the AV space and mandated that if they wanted to do this, they had to follow their own rules which MS was not willing to do.
Instead, Microsoft dictated that any code that was going to run in the kernel had to be submitted to Microsoft for review, who would then approve or deny the code for use. The problem with this method is that it's slow, so any AV that wanted to update their engine had to go through a code review process every time. Crowdstrike (and likely every other AV provider) got around this by having a component of their software with kernel-access that could read in data dynamically. This is what caused that worldwide BSOD problem a couple years back. The Crowdstrike component with kernel access loaded in a bad update that was not properly reviewed and it broke every system with the AV installed.
Overall, this change is a good thing and will force software vendors to actually operate securely rather than just asking for ring 0 access when they don't need it. As always, if you're worried about the changes MS is making, Linux is available and getting better day by day.
Oh, so that's why Epic's Easy anticheat keeps having trouble. Microsoft might be using it as a trial run.