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.
That’s what I’m personally banking on. I think anyone with the resources to bypass these would first just use a rubber hose.
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.
You don't need any major resources to exploit systems these days in this manner, especially with AI in the mix.
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.