
QEMU: user-to-root privesc inside VM via bad translation caching - webaholic
https://bugs.chromium.org/p/project-zero/issues/detail?id=1122
======
tyingq
_" However, while real X86 processors have a maximum instruction length of 15
bytes, QEMU's instruction decoder for X86 does not place any limit on the
instruction and length or the number of instruction prefixes."_

Interesting, and not your usual type of exploit. Guessing this isn't one that
will have the Rust crowd doling out "told ya so" :). Logic error only. No
buffer overflow, not much strong types do for you, etc.

~~~
hueving
If you really wanted to fish for a "told ya so", someone could just point out
that by eliminating all of those other classes of bugs, developers could have
spent more time looking for logic errors.

~~~
empath75
Will you have time for that after fighting the borrow checker?

------
omribahumi
> To be clear: As far as I know, this bug only affects the TCG mode (without
> hardware acceleration), not KVM VMs or so.

I wonder what's the reach of that bug.

~~~
bonzini
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.

~~~
omribahumi
That doesn't mean people don't use it.

Is what you're saying here documented anywhere?

~~~
pm215
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_...](http://wiki.qemu-
project.org/SecurityProcess#How_impact_and_severity_of_a_bug_is_decided)

~~~
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://git.qemu-
project.org/?p=qemu.git;a=blob_plain;f=tcg/README;hb=HEAD) [http://wiki.qemu-
project.org/Documentation/TCG](http://wiki.qemu-project.org/Documentation/TCG)

~~~
pm215
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/](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
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-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?

------
gbrown_
Not sure why this wasn't duped to
[https://news.ycombinator.com/item?id=13921305](https://news.ycombinator.com/item?id=13921305)

~~~
tomhoward
Dang has addressed this matter several times in the past [1]. The dupe
detector is 'deliberately porous' so good stories have multiple chances to get
exposure.

[1]
[https://hn.algolia.com/?query=dang%20porous&sort=byPopularit...](https://hn.algolia.com/?query=dang%20porous&sort=byPopularity&prefix&page=0&dateRange=all&type=comment)

~~~
gbrown_
Ah interesting didn't know this, thanks.

