Preferences


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.

quotemstr
Well, look on the bright side: once we eliminate the boring old memory safety bugs, and the XSS, and the SQL injection, the exploits that remain will at least be interesting.
orblivion
And they'll have time to deal with them.
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?
simion314
If a developer finishes his task he will be given a new task, I don't think you will get a task "go and review our code again for weird logic errors" you will be sent to add a new feature or fix a bug, so you will work on that and create a few new bugs.
I got that while trolling Rust developers a bit on this point, and had to concede-- it's a fair point.

I do think that rust doesn't (yet) have enough affordances for formal verification of algorithmic correctness-- but if you're not chasing memory safety you have more time to deal with other issues.

If we remove memory corruption errors, that it already one less class of errors to worry about.

As for the <whatever type safe systems programming language> crowd, these complaints have been done in the past by fairly unknown people like C. A. R. Hoare, Niklaus Wirth, James G. Mitchell, Alan Kay, Luca Cardelli,.... so what do they know about computers.

Range checking is done deal with sufficiently strong types (read - dependent types). It was done in the Epigram LONG time ago, ten years ago if not more.

For example, when you fetching bytes for decode you can type-check that you are in the quota and act accordingly.

tyingq
Still a developer choice as to what the quota is though, right? That's the logic error here, quota set too high.
No.

Working with two page quota (as QEMU dev intended) at type level won't allow you to pass through three page (as QEMU code allows and what is exploited).

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?

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

Confiks
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.
omribahumi
Yes, I get that. I was wondering how widely used is qemu in x86 software mode
Confiks
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.
omribahumi
Right, if you're running on x86 hardware. The use case is probably non-x86 hardware running x86 VMs.

For example, I remember using qemu to emulate RPi with ARM software emulation on my x86 machine.

gbrown_
Not sure why this wasn't duped to https://www.hackerneue.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...

gbrown_
Ah interesting didn't know this, thanks.

This item has no comments currently.