[dasyatidprime]

I've considered this for consolidating core hardware, but dual-boot doesn't do trust boundaries well. The Windows kernel still has full block access to the other device, so if it gets admin-level malware, it has free rein to infect the other system. At one point several years ago I got partway through a plan involving having most disks be externally pluggable (and assuming that firmware-level malware persistence is unlikely, which I'm not as sure about these days) but gave up for unclear reasons. I think if I were to try that again (and if I had the hardware for it) I'd try some kind of NAS approach to separate storage credentials from the OS.

[Neikius]

You could run windows in the VM. Pcie passthrough is a thing just be careful with the Mobo.

[dasyatidprime]

You could indeed run Windows in a VM with PCI passthrough, and for a while long ago my desktop was Xen and I ran a Windows 7 domU which was attached to a second graphics card. Sharing a GPU at least used to be much harder; I think there's better options nowadays than before (paravirtualization-style GPU-command-level passthrough devices, and I assume some graphics hardware supports being split up for partial IOMMU passthrough in the way some high-end network cards do), but I don't know how they stack up for gaming performance.

However, the use case under discussion touches on things like handling kernel-level anti-cheat requirements, which is exactly the kind of place where I'd expect you to get in trouble trying to jigger around with virtual machines. Even before that point, I get the general feeling games and game platforms can get tetchy when you're not on Real Recognizable Hardware.

[fsflover]

You can use TPM with Heads and a hardware key to ensure Windows can't infect the other partition.

[kogir]

With secure boot, full disk encryption, and robust backups, this risk should be largely mitigated, right?

That’s what I’m personally banking on. I think anyone with the resources to bypass these would first just use a rubber hose.

[dasyatidprime]

Normal/classical FDE doesn't truly protect integrity, only confidentiality. Supposedly LUKS2 allows you to run with --integrity, but it's an extra layer of I/O amplification, and if you're willing to take that hit then there's less incentive not to just use an external drive. https://security.stackexchange.com/questions/87367/does-luks...

As for Secure Boot, maybe? I haven't thought through how that would help in this context, but my instinct is to ask how you'd do the binding between “I intend to boot Y instead of X” and “only accept the boot signature for Y instead of X”, so that malware can't try to unexpectedly substitute X. It feels like there's probably places for attackers to mess around here unless you're very careful.

[d3Xt3r]

Not really. Regular exploits that allow attackers to gain SYSTEM level access frequently crop up in Windows (like the recent regpwn exploit). Someone who games on PC is likely into modding as well, and this is a frequent attack vector - so an innocent-looking mod executable could gain admin rights and make use of secure boot exploits like CVE-2023-24932 (assuming the system is using an unpatched BIOS). Even if the BIOS is patched, there's no guarantee that a similar exploit won't crop up in the future. You could update your system regularly to stay on top of things, but zero days exploits are also a thing - like, do you install updates the minute they come out? Probably not. And even if you do, it takes time to download and apply those updates, a window which could be used to execute zero days, by a hidden RAT.

You don't need any major resources to exploit systems these days in this manner, especially with AI in the mix.

[snvzz]

Many of these attacks target the bios.

BIOS is usually a SPI chip. It'd make sense to perhaps tie the write enable line so that it cannot be written to, unless jumpered.

It used to be a thing motherboards did. A BIOS flash enable jumper.

They kept the CMOS reset one, but for some reason got rid of the flash write enable.