Zero. TCG is not considered secure/trusted by any means by the QEMU team, unlike KVM or Xen. It has never received a serious security audit.
That doesn't mean people don't use it.
Is what you're saying here documented anywhere?
It is documented here, but you're right that ideally we could mention it somewhere more prominent.
http://wiki.qemu-project.org/SecurityProcess#How_impact_and_...
Is this the correct link? I can find nothing about TCG nor about "tiny code generator" there.
It would be nice to warn about lack of security properties of TCG in some of these places: http://git.qemu-project.org/?p=qemu.git;a=blob_plain;f=tcg/R... http://wiki.qemu-project.org/Documentation/TCG
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.
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.
Yes, I get that. I was wondering how widely used is qemu in x86 software 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.
I wonder what's the reach of that bug.