Kevin Wolf <address@hidden> writes:
Am 31.10.2014 um 12:24 hat Stefan Hajnoczi geschrieben:
On Thu, Oct 30, 2014 at 10:36:35AM +0100, Kevin Wolf wrote:
Am 30.10.2014 um 10:27 hat Stefan Hajnoczi geschrieben:
The guest may legitimately use raw devices that contain image format
data. Imagine tools similar to libguestfs.
It's perfectly okay for them to lay out image format data onto a raw
device.
Probing is the problem, not putting image format data onto a raw device.
Agreed, that's why any restrictions only apply when probing was used to
detect a raw image. If you want to do anything exotic like storing a
qcow2 image for nested virt on a disk that is a raw image in the host,
then making sure to pass format=raw shouldn't be too much.
Because at that point the solution is way over-engineered.
Probing checks should be in the QEMU command-line code, not sprinkled
across the codebase and even at run-time.
Isn't Markus approach much simpler and cleaner?
I don't think so. My code isn't "sprinkled across the codebase", it has
the checks right where the problem arises, in the raw block driver.
Actually, that's not where the problem is.
The guest writing funny things to its disks is *not* the problem, it's
perfectly normal operation. Probing untrusted images is the problem!
It's with Markus's approach that we'll have to have code in many
different places as I showed. Its fundamental assumption that there is
always a filename string and the filename isn't passed in some QDict
option is simply wrong. Specifying the image is driver-dependent and
therefore you'd have to add functionality to each driver in order to get
the filename extension (or the information that there isn't anything
close enough to a filename).
The RFC patch is incomplete. Can't say how much code recording the
filename correctly will take until I've done it.
I suspect the lack of an image filename already leads to rotten error
messages in places.
The only argument brought up so far that I can reasonably buy is that
in the unlikely case of the restrictions applying it may be surprising
for the user to see requests failing. To address this, we could print
a warning when an image is opened in the "restricted raw" mode. This
way the user knows what's going on,
Improves the virtual hardware from "crippled" to "openly crippled", and
my opinion on it from "I hate it" to "I hate it slightly less" :)
and at the same time we still
effectively protect them instead of only printing a warning without real
protection.
This isn't real protection, either.
If the user runs with format=raw, the guest can write whatever it likes,
and that's a feature. If the user forgets format=raw just once, he's
p0wned. That's because your "protection" does not address the real
problem (probing of untrusted images),
but tries to prevent it by
refusing to created "bad" untrusted images, but can do so only in
special configurations, and not at all for images written by something
else.
Unlike your proposal, mine does attack the real problem, and thus *can*
provide real protection.
Not immediately because we want to avoid
aprupt change, but eventually. Here's how:
1. Initially, we warn on insecure usage. This doesn't protect users,
but it guides them towards protecting themselves.
2. Eventually, we make the warning an error. This *does* protect users,
regardless of how they use or have used QEMU, *except* when they
explicitly ask for insecure probing with format=insecure-probe (assuming
we provide that option).