Michael Tokarev <[email protected]> writes: > 22.12.2020 14:33, Marian Posteuca wrote: >> Qemu's ACPI table generation sets the fields OEM ID and OEM table ID >> to "BOCHS " and "BXPCxxxx" where "xxxx" is replaced by the ACPI >> table name. >> >> Some games like Red Dead Redemption 2 seem to check the ACPI OEM ID >> and OEM table ID for the strings "BOCHS" and "BXPC" and if they are >> found, the game crashes(this may be an intentional detection >> mechanism to prevent playing the game in a virtualized environment). > > This isn't a technical question/comment about the patch itself, but > about something different. Do we really want to play this whack-a-mole > game? If we change ACPI table IDs, those who want to disallow running > their software inside qemu/kvm will find some other way to check for > this environment. We will change that, - just to be found again. And > so on.. is it productive? I don't think so.
My personal opinion is that as long as it's not too difficult to mask that the guest is running in a virtualized environment we should try to do these changes. But I guess this can only be judged on per change basis. > > I'm not against this patch in any way, not at all, - having this ability > is good for other purpose too. But I think we can't won in this "detect > if we're running under qemu" battle easily. And the next version of the > same game will have a more sofisticated detection method and we won't > even know which way they used. People gaming in a virtualized environment, are a very small fraction of windows gamers, so I would assume that these companies do the bare minimum to detect QEMU(an exception might be online games where they have an incentive to prevent cheating). Also I suppose this change could also be helpful for malware analysis(since it prevents one way of detecting if windows is running in a VM)? Would you like a more generic commit message which doesn't references gaming? > > Thanks, > > /mjt
