= How this lets the guest escape isolation =
Unfortunately, this lets the guest shift the trust boundary and escape
isolation, as follows:
* Expose a raw image to the guest (whether you specify the format=raw or
let QEMU guess it doesn't matter). The complete contents becomes
untrusted.
* Reuse the image *without* specifying the raw format. QEMU guesses the
format based on untrusted image contents. Now QEMU guesses a format
chosen by the guest, with meta-data chosen by the guest. By
controlling image meta-data, the malicious guest can access arbitrary
files as QEMU, enlarge its storage, and more. A non-malicious guest
can accidentally DoS itself, by writing a pattern probing recognizes.
Thank you for bringing that to my attention. This means that I'm even
more in favor of using Kevin's patches because in fact they don't
break anything.
They break things differently. The difference may or may not matter.
Example: innocent guest writes a recognized pattern.
Now: next restart fails, guest DoSed itself until host operator gets
around to adding format=raw to the configuration. Consequence:
downtime (probably lengthy), but no data corruption.
With Kevin's patch: write fails, guest may or may not handle the
failure gracefully. Consequences can range from "guest complains to
its logs (who cares)" via "guest stops whatever it's doing and refuses
to continue until its hardware gets fixed (downtime as above)" to
"data corruption".
You somehow seem convinced that writing to sector 0 is a completely
normal operation. For x86, it isn't, though.
There are only a couple of programs which do that, I can only think
of partitioning and setting up boot loaders. There's not a myriad of
programs which would increase the probability of one both writing a
recognizable pattern *and* not handling EPERM correctly.
I see the probability of both happening at the same time as
extremely low, not least because there are only a handful of
programs which access that sector.