Hacker Neue

Preferences
pm215 parent
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_...

robryk
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

pm215 OP
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.

i336_
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.

pm215 OP
Well, I guess technically you could do it -- the codegen started out as code from tcc, after all. However we've made enough changes over the years that right now it has some specializations to QEMU's needs. Also questions like "is this optimization pass worthwhile" have definitely different answers for QEMU's JIT purposes compared to an actual compiler -- we care a lot more about codegen speed so there are some optimizations that we prototyped but abandoned because they didn't improve the runtime performance enough to make up for codegen getting slower.
i336_
I didn't actually know that TCG was built from tcc, interesting.

Leveraging TCG in its current JIT-optimized state could actually be very compelling though: the only "C interpreters" I'm aware of are PicoC and Ch (and pedantically, tcc -run), all very different codebases. None offer a JIT-optimizing C interpreter though.

I take it that all that would be necessary would be ripping out the disassembler frontend and wiring in something like http://www.quut.com/c/ANSI-C-grammar-y.html + http://www.quut.com/c/ANSI-C-grammar-l-2011.html (or an equivalent), or maybe even a (heavily) forward-ported copy of tcc's C parser?

bonzini
TCG used to have no optimizations at all, so the current ones shouldn't be worse than what tcc used to have... That said I have never looked at tcc's code generator.

This item has no comments currently.