It's the bit where it says 'is it used in conjunction with a hypervisor?'. That's how we define the use cases that count as defendable against malicious guests.
This covers more than just the TCG cpu emulation because it also means that any device model that can only be used with an emulated CPU is also out of scope for CVEs and hasn't been audited to confirm it has no VM-escape bugs. So the internal documentation of TCG itself isn't really the right place to document this I think.
Hi, wanted to quickly ask a slightly offtopic question about TCG that I've wondered about for a few years. I was never sure who to ask.
Rob Landley made some small noises about the possibility of leveraging TCG as a successor to tcc (I read about the tinycc/tcc debacle (http://www.landley.net/code/tinycc/) - really sad). I was just curious if such an idea - turning QEMU's code generator into a standalone compiler - is technically feasible in terms of architectural sanity and practical maintainability.
As the bug seems to rely on a maximum instruction length that is present in hardware x86 but not in QEMU's x86, the reach of this particular bug seems to be just the software emulated mode.
It might be used for special applications, but not for your typical server that is connected to the internet, simply because it's horribly slow compared to the virtualization support (VT-x / AMD-V) most modern CPUs offer since at least 2010.