Why load on boot? -> Because we need to, don't worry.
Why is scanning my serial port -> Is a bug, don't worry is not a problem.
What if Riot is hacked? -> If Microsoft gets hacked is even worse, so is not a problem.
Why load on boot? -> Because we need to, don't worry.
Why is scanning my serial port -> Is a bug, don't worry is not a problem.
What if Riot is hacked? -> If Microsoft gets hacked is even worse, so is not a problem.
But the point is that in one the OS security layers or antivirus will catch it.
Doesn't antivirus have detections for ring0 as well? Otherwise virus makers can just code their viruses to be in drivers and evade all the antiviruses.
At ring 0 the virus can do whatever it wants with your computer.
A more accurate phrasing is that antivirus software can positively confirm the presence of malware but it cannot on its own definitely prove the absence of ring0 malware. For that, you need an Apple-level secure boot process to give confidence that the code is running on an unmodified, unvirtualized kernel.
I believe the reason stated was "because we know it will not be tampered with after boot". Not saying it's a good or bad reason, but this is dishonest paraphrasing.
If I remember correctly I can just enable/disable the easy anticheat service, sane with the EA thing, I don't need to reboot the machine like with Vanguard.
But thanks for pointing it out.
It is done by FACEIT and ESEA.
> If I remember correctly I can just enable/disable the easy anticheat service, sane with the EA thing, I don't need to reboot the machine like with Vanguard.
You can disable Vanguard as well, you'll only need to re-enable it and restart if you want to play the games.
Can also read process memory of the same user.
In any case, something being programmed poorly isn't a good excuse to make things even worse. It is, however, a great reason to... run things under isolated users/environments, or in a VM (which these drivers also want to prevent).
Are you sure there isn't some sort of setuid executable that's doing all the root stuff for you? At least in theory for something like steam, you'd want either all installs to require root, or restrict all installs to per-user basis.
>In any case, something being programmed poorly isn't a good excuse to make things even worse.
The point is that if multi-user security is broke in practice, you shouldn't invest effort into using it, and use something better like virtualization and/or dual booting with full disk encryption.
These drivers generally try to prevent you from using virtualization for the same reason they want root. The point is that fundamentally they want to live one level above wherever the user is, which means they compromise user ability to secure against them. The game industry isn't exactly known for slow, careful development, so they're kind of the worst group to give root.
Even without a VM, multi-user security does work, and Linux has other tools to isolate programs. Steam already runs in a sandbox[0] on NixOS to give it a normal FHS layout and work at all, so it wouldn't be unreasonable to add more isolation.
[0] apparently using https://github.com/containers/bubblewrap which can also do things like PID and network isolation.