On Fri, Apr 24, 2020 at 10:25:15 -0500, Eric Blake wrote:
On 4/24/20 10:18 AM, Peter Krempa wrote:
> On Fri, Apr 24, 2020 at 09:52:00 -0500, Eric Blake wrote:
> > On 4/24/20 4:24 AM, Peter Krempa wrote:
> > > The implementation was never finished in libvirt. Remove it.
> > >
> > > Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
> > > ---
> > > src/util/virstoragefile.c | 19 ++-----------------
> > > 1 file changed, 2 insertions(+), 17 deletions(-)
> >
> > Shouldn't we at least recognize if there is a qcow2 file with the
extension
> > header set, at which point we can error out and tell the user their image is
> > unsupported, rather than trying to use it without the data file?
>
> I don't think it's scalable to do so unless qemu exposes a whitelist of
> supported extensions we can declare we support. Otherwise we are
> band-aiding stuff we lear that exists and ignore any other extensions.
external data files have an incompatible feature bit set in addition to the
header extension. Maybe whitelisting header extensions is prohibitive, but
we should be able to recognize when a qcow2 file has an incompatible feature
bit set that we are not aware of, and assume that since we don't know about
the feature, we also don't know how to safely pass that file to qemu.
That is, we could quickly reject qcow2 files with offset 72-79 containing
bit 2 set, until we are ready to support external data files in libvirt.
Are there any specific reasons to do so? If so we should track them in a
bug/issue in the first place. Additionally I'm against extending the
qcow2 header parser beyond what's strictly necessary. In the end our
reimplementation of of the parser is considered a security measure.
I've pushed the patches for now. If somebody will require the 'data
file' field the last patch can always be reverted.