Re: Let's remove some deprecated stuff
On Mon, May 03, 2021 at 13:21:47 -0500, Eric Blake wrote: > On 4/29/21 4:59 AM, Markus Armbruster wrote: [...] > > qemu-img backing file without format (since 5.1) > > > > > > The use of ``qemu-img create``, ``qemu-img rebase``, or ``qemu-img > > convert`` to create or modify an image that depends on a backing file > > now recommends that an explicit backing format be provided. This is > > for safety: if QEMU probes a different format than what you thought, > > the data presented to the guest will be corrupt; similarly, presenting > > a raw image to a guest allows a potential security exploit if a future > > probe sees a non-raw image based on guest writes. > > > > To avoid the warning message, or even future refusal to create an > > unsafe image, you must pass ``-o backing_fmt=`` (or the shorthand > > ``-F`` during create) to specify the intended backing format. You may > > use ``qemu-img rebase -u`` to retroactively add a backing format to an > > existing image. However, be aware that there are already potential > > security risks to blindly using ``qemu-img info`` to probe the format > > of an untrusted backing image, when deciding what format to add into > > an existing image. > > I'm not sure how widely used these were, but I'm game for writing a > patch to drop them. I'm fairly certain libvirt is not using them. This is certainly seeing some upstream "use" from random scripts and possibly also libguestfs. There are few limited scenarios when probing format is still safe if you are not 100% sure what the original format of the image was. I'm afraid that removing this will (at least when used with libvirt) remove the potential detection of the unsafe scenarios and prompt people to modify their code to do plainly: 1) probe format of backing file 2) use it in the new overlay without considering the implications This is IMO less-safe because libvirt will consider the backing chain without questioning security. > > Kevin Wolf: > > > > ``nbd-server-add`` and ``nbd-server-remove`` (since 5.2) > > > > > > Use the more generic commands ``block-export-add`` and > > ``block-export-del`` > > instead. As part of this deprecation, where ``nbd-server-add`` used a > > single ``bitmap``, the new ``block-export-add`` uses a list of > > ``bitmaps``. > > Peter, is libvirt good for this one to go? Yes, libvirt added support for block-export-add usage in favor of nbd-server-add in: https://gitlab.com/libvirt/libvirt/-/commit/8c67e389d6367af2ef6dbe2f578c585e2150558d 6.8.0-379-g8c67e389d6 It was briefly disabled since qemu decided to change the design of block-export-add-before it was really released since the change happened around a libvirt release: https://gitlab.com/libvirt/libvirt/-/commit/b87cfc957f57c1d9f7e5bf828ee4b23972085991 v6.9.0-rc1-7-gb87cfc957f and then re-enabled in https://gitlab.com/libvirt/libvirt/-/commit/42558a43f87f5a3e73bacb88baf425648415a06f v6.9.0-8-g42558a43f8
Re: Let's remove some deprecated stuff
On 4/29/21 4:59 AM, Markus Armbruster wrote: > If you're cc'ed, you added a section to docs/system/deprecated.rst that > is old enough to permit removal. This is *not* a demand to remove, it's > a polite request to consider whether the time for removal has come. > Extra points for telling us in a reply. "We should remove, but I can't > do it myself right now" is a valid answer. Let's review the file: > [adjusting cc for this response] > > Eric Blake: > > qemu-img amend to adjust backing file (since 5.1) > ' > > The use of ``qemu-img amend`` to modify the name or format of a qcow2 > backing image is deprecated; this functionality was never fully > documented or tested, and interferes with other amend operations that > need access to the original backing image (such as deciding whether a > v3 zero cluster may be left unallocated when converting to a v2 > image). Rather, any changes to the backing chain should be performed > with ``qemu-img rebase -u`` either before or after the remaining > changes being performed by amend, as appropriate. > > qemu-img backing file without format (since 5.1) > > > The use of ``qemu-img create``, ``qemu-img rebase``, or ``qemu-img > convert`` to create or modify an image that depends on a backing file > now recommends that an explicit backing format be provided. This is > for safety: if QEMU probes a different format than what you thought, > the data presented to the guest will be corrupt; similarly, presenting > a raw image to a guest allows a potential security exploit if a future > probe sees a non-raw image based on guest writes. > > To avoid the warning message, or even future refusal to create an > unsafe image, you must pass ``-o backing_fmt=`` (or the shorthand > ``-F`` during create) to specify the intended backing format. You may > use ``qemu-img rebase -u`` to retroactively add a backing format to an > existing image. However, be aware that there are already potential > security risks to blindly using ``qemu-img info`` to probe the format > of an untrusted backing image, when deciding what format to add into > an existing image. I'm not sure how widely used these were, but I'm game for writing a patch to drop them. I'm fairly certain libvirt is not using them. > > Kevin Wolf: > > ``nbd-server-add`` and ``nbd-server-remove`` (since 5.2) > > > Use the more generic commands ``block-export-add`` and > ``block-export-del`` > instead. As part of this deprecation, where ``nbd-server-add`` used a > single ``bitmap``, the new ``block-export-add`` uses a list of > ``bitmaps``. Peter, is libvirt good for this one to go? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
