3 ms·

That doesn't mean people don't use it. Is what you're saying here documented anywhere?

pm215 10y ago
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_severity_of_a_bug_is_decided http://wiki.qemu-project.org/SecurityProcess#How_impact_and_...
- robryk 10y ago
  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/README;hb=HEAD http://git.qemu-project.org/?p=qemu.git;a=blob_plain;f=tcg/R... http://wiki.qemu-project.org/Documentation/TCG http://wiki.qemu-project.org/Documentation/TCG
  - pm215 10y ago
    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_ 10y ago
      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/ 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 10y ago
        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.
        bonzini 10y ago
        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.
        i336_ 10y ago
        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-y.html + http://www.quut.com/c/ANSI-C-grammar-l-2011.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?

pm215 10y ago

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_severity_of_a_bug_is_decided http://wiki.qemu-project.org/SecurityProcess#How_impact_and_...

robryk 10y ago
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/README;hb=HEAD http://git.qemu-project.org/?p=qemu.git;a=blob_plain;f=tcg/R... http://wiki.qemu-project.org/Documentation/TCG http://wiki.qemu-project.org/Documentation/TCG
- pm215 10y ago
  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_ 10y ago
    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/ 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 10y ago
      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.
      - bonzini 10y ago
        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.
      - i336_ 10y ago
        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-y.html + http://www.quut.com/c/ANSI-C-grammar-l-2011.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?