On Tue, Nov 23, 2010 at 3:10 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: > On 11/23/2010 06:26 AM, Stefan Hajnoczi wrote: >>> More worrying, I don't see anything in QED that requires the filename to >>> occur within the first 10K bytes. Do we need to add another enum value >>> to libvirt's backing store callback routine, to be used when the header >>> requests data that lies beyond buf_size but is still feasibly valid, for >>> the case where QED designates a backing store location that is beyond >>> 10k but still before the start of the first cluster, rather than the >>> current approach of just treating it as BACKING_STORE_INVALID? >> >> QED doesn't explicitly restrict >> backing_filename_offset/backing_filename_size to just the header >> cluster(s). I think it makes sense to say backing_filename_offset + >> backing_filename_size <= header_size * cluster_size and will add it to >> the QED spec. > > Thanks. Do you also want to require that backing_filename_offset > > sizeof(backing_filename_size)+offsetof(header,backing_filename_size)? > That is, it doesn't make sense for the backing filename to overlap with > existing header elements. Although I agree that it doesn't make sense to overlap the backing filename with the header fields it isn't possible to check this fully. A backwards compatible QED image could have feature bits enabled for new header fields that an old programs don't know about. At that point the "header structure size" is just an arbitrary number and we can't really guard where the backing filename should be stored. Stefan -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list