this post was submitted on 16 Aug 2025
204 points (100.0% liked)

PC Gaming

12108 readers
241 users here now

For PC gaming news and discussion. PCGamingWiki

Rules:

  1. Be Respectful.
  2. No Spam or Porn.
  3. No Advertising.
  4. No Memes.
  5. No Tech Support.
  6. No questions about buying/building computers.
  7. No game suggestions, friend requests, surveys, or begging.
  8. No Let's Plays, streams, highlight reels/montages, random videos or shorts.
  9. No off-topic posts/comments, within reason.
  10. Use the original source, no clickbait titles, no duplicates. (Submissions should be from the original source if possible, unless from paywalled or non-english sources. If the title is clickbait or lacks context you may lightly edit the title.)

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] unhrpetby@sh.itjust.works 4 points 5 days ago* (last edited 4 days ago)

If you tell me that all I need to do to negate the security concern of the kernel level anticheat is to run the dualboot windows partition...

...it makes intuitive sense that installing a kernel level anticheat would only affect the windows kernel it was installed on not the linux kernel on the other drive partition.

The intuition is incorrect as the kernel-level anticheats are not necessarily trusted. Operating systems interact with low-level hardware and firmware on the system. As such, it is not self-contained.

https://www.kaspersky.com/about/press-releases/more-elusive-and-more-persistent-the-third-known-firmware-bootkit-shows-major-advancement

There exists both UEFI bootkits and firmware implants. Its intuitive if you understand it like this: if there exists a communication pathway from (A) lower-privilege code -> (B) higher-privilege code, there exists the potential for vulnerabilities.

This is due to (A) now having an effect on the code execution for (B).