Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode

[Anthony Liguori <anthony@codemonkey.ws>]

Ian Jackson wrote:
> Anthony Liguori writes ("Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode"):
>   
>> Ian Jackson wrote:
>>     
>>>  4. qemu will take steps to try to ensure that bugs and missing
>>>     changes in the readonly implementation don't leave a security
>>>     hole where the
>>>       
>> I'm not at all worried about this FWIW.
>>     
>
> Well, in the Xen world we have different priorities I think.  Many
> people are depending very heavily on the security properties of Xen
> including the hardware emulations.  So for us it is important that we
> take all the measures we can to stop us from accidentally committing
> bugs.
>   

Which is fine, but you're missing my fundamental argument.  Having a 
read-only flag exposed to the user should not translate to "open the 
underlying files O_RDONLY".  That's an implementation detail.  If that's 
what ends up happening, great.  However, I'll make the argument also 
that for certain circumstances that's not actually what we want.

> If this is something that qemu upstream doesn't want then we will have
> to maintain it as a permanent delta in our `Xen' tree (along with the
> mapcache, etc. etc.)
>
> It would be fine if there were in fact only one place where writes
> take place.  But actually there are multiple routes at pretty much all
> levels: multiple entrypoints (aio and not, pwrite or not), multiple
> block drivers, in cow devices multiple read/write paths depending on
> whether the block is already present in the diffs and multiple writes
> to the .img for each requested write, etc.
>   

All writes end up going through the block-raw-posix write functions.

>> qemu-system-x86_64 -drive file=foo.img -drive file=boo.img,read-only=on
>>
>> Down the road, you do a savevm.  savevm has to create a checkpoint in 
>> all disk images.  The checkpoint will be empty in boo.img but it still 
>> needs to create one.
>>     
>
> Perhaps I don't understand clearly enough how you imagine this
> scenario.  Surely when the snapshot is resumed it is sufficient for
> the file boo.img to be identical ?
>   

Not really.  When the snapshot is restored, what do you do with 
boo.img?  Do you just use the main L1 table if no properly named 
snapshots are available?  That seems quite error prone to me.

Another example is introducing a copy-on-read disk.  This would be 
useful for image stream.  Think a qcow2 file that backs an http block 
device.  The perfect use-case for something like this is an ISO image 
which a user would want to export to the guest read-only.  However, we 
need to modify the qcow2 image as the guest reads it (to do the 
copy-on-read).

N.B. I've said before that there's no reason that a read-only disk 
cannot result in the file being opened O_RDONLY (for raw in particular) 
but that is a detail of each block device and I don't think it should be 
the case for qcow2.

Regards,

Anthony Liguori