Re: [libvirt] [PATCH 0/3] Define XDG variables for hypervisor domains
On Thu, Mar 07, 2019 at 10:37:14AM +, Daniel P. Berrangé wrote:
> On Thu, Mar 07, 2019 at 09:27:29AM +0100, Erik Skultety wrote:
> > On Wed, Mar 06, 2019 at 04:05:13PM +, Daniel P. Berrangé wrote:
> > > On Wed, Mar 06, 2019 at 03:41:16PM +0100, Erik Skultety wrote:
> > > > So, according to this report [1], Mesa enabled on-disk cache for its
> > > > shaders
> > > > which it tries to create either under XDG_CACHE_HOME/mesa_shader_cache
> > > > or under
> > > > HOME/.cache/mesa_shader_cache. Since libvirt doesn't set XDGs and HOME
> > > > is only
> > > > passed iff the QEMU process isn't run with SUID, Mesa will default to
> > > > the home
> > > > directory specified in /etc/passwd.
> > > > Because of this, Mesa will fail to create the cache and QEMU refuses to
> > > > start
> > > > the VM (interestingly enough, Intel reports the problem too, but Mesa
> > > > disables
> > > > the cache and the VM starts). This series proposes usage of XDG
> > > > variables to
> > > > fix the problem by pointing XDG variables to hypervisor specific
> > > > directory
> > > > under libvirt's libDir. Additionally, HOME is also enforced for all VM
> > > > processes and points to the base hypervisor libDir directory.
> > > > To illustrate this further:
> > > >
> > > > system qemu:
> > > > HOME=/var/lib/libvirt/qemu/domain-5-f-live \
> > > > XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.local/share \
> > > > XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.cache \
> > > > XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.config \
> > > >
> > > > session qemu:
> > > > HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live \
> > > > XDG_DATA_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.local/share
> > > > \
> > > > XDG_CACHE_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.cache
> > > > \
> > > > XDG_CONFIG_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.config
> > > > \
> > >
> > > For the bug report IIUC we should only need to set XDG_CACHE_HOME
> > > as that's the one which needs to be writable and which SELinux quite
> > > rightly denies. It is also safe to redefine this because cache data
> > > is liable to be purged at any time, so apps must expect to see an
> > > empty cache directory.
> >
> > Yes, XDG_CACHE_HOME is the only one needed to fix the BZ.
> >
> > >
> > > I'm very wary about setting HOME or XDG_DATA_HOME or XDG_CONFIG_HOME
> > > as I think that is pretty likely to break valid usage.
> > >
> > > For example, when QEMU is configured to use pulseaudio as its audio
> > > backend, I believe this will want to read config files in normal
> > > $HOME and/or $XDG_{CONFIG|DATA}_HOME.
> >
> > I'm glad you mentioned pulseaudio, it's a good example, because pulseaudio
> > should never run as root, instead, it will run in context of the 'qemu'
> > user,
> > right? This is all fine in session mode, but in system mode, having set
> > none of
> > the above apart from cache, pulseaudio might try to read from '/' as that's
> > QEMU's home dir. Any reasonable app should default to reading configs and
> > data
> > from /etc or /usr/local if there's nothing found in HOME or XDG location.
> > But
> > when it comes to writing, having apps write anything to root's home doesn't
> > seem like a good idea to me, so I believe that at least for system mode, we
> > want to override all of the variables.
>
> Yes, ok, for system mode setting all of them is sensible for the reasons
> you say.
>
> > I'd also be okay with not redefining the variables for session mode, but the
> > following motivated me to do so:
> > 1) consistency, if we do it in 1 mode, why not the other (although
> >personally, I don't like enforcing session mode that much)
>
> To me one of key reasons for session mode (aside from access to disk images
> in $HOME) is that it allows VMs to integrate with services / apps in that
> users session, such as PA. So isolating them is going to eliminate that
> key feture of session mode & break valid usage IMHO.
>
> > 2) isolation, configs are fine, but any data an app wants to write, I'm
> >really not sure how they handle multiple instances, so I approached
> > this
> >like non-shared filesystems, any 2 apps need to have their own view
> > of
> >the location and I also don't want them to even think of trying to
> > write
> >something to root's home
>
> We don't really expect QEMU (or things it links to) to write to these
> dirs, but if they did try SELinux would block it. IMHO if you wanted
> stricter isolation then QEMU needs to be running a different UID.
>
> > > Similary if using the GTK frontend these dirs are needed to load
> > > the toolkit preferences such as theme.
> >
> > You mean for ? If so, we don't support GTK.
>
> Yes for graphics. Lack of GTK support is a bug :-)
Alright, thanks for comments, I'll respin with the changes we talked about.
Erik
--
libvir-list mailing list
Re: [libvirt] [PATCH 0/3] Define XDG variables for hypervisor domains
On Thu, Mar 07, 2019 at 09:27:29AM +0100, Erik Skultety wrote:
> On Wed, Mar 06, 2019 at 04:05:13PM +, Daniel P. Berrangé wrote:
> > On Wed, Mar 06, 2019 at 03:41:16PM +0100, Erik Skultety wrote:
> > > So, according to this report [1], Mesa enabled on-disk cache for its
> > > shaders
> > > which it tries to create either under XDG_CACHE_HOME/mesa_shader_cache or
> > > under
> > > HOME/.cache/mesa_shader_cache. Since libvirt doesn't set XDGs and HOME is
> > > only
> > > passed iff the QEMU process isn't run with SUID, Mesa will default to the
> > > home
> > > directory specified in /etc/passwd.
> > > Because of this, Mesa will fail to create the cache and QEMU refuses to
> > > start
> > > the VM (interestingly enough, Intel reports the problem too, but Mesa
> > > disables
> > > the cache and the VM starts). This series proposes usage of XDG variables
> > > to
> > > fix the problem by pointing XDG variables to hypervisor specific directory
> > > under libvirt's libDir. Additionally, HOME is also enforced for all VM
> > > processes and points to the base hypervisor libDir directory.
> > > To illustrate this further:
> > >
> > > system qemu:
> > > HOME=/var/lib/libvirt/qemu/domain-5-f-live \
> > > XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.local/share \
> > > XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.cache \
> > > XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.config \
> > >
> > > session qemu:
> > > HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live \
> > > XDG_DATA_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.local/share
> > > \
> > > XDG_CACHE_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.cache
> > > \
> > > XDG_CONFIG_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.config
> > > \
> >
> > For the bug report IIUC we should only need to set XDG_CACHE_HOME
> > as that's the one which needs to be writable and which SELinux quite
> > rightly denies. It is also safe to redefine this because cache data
> > is liable to be purged at any time, so apps must expect to see an
> > empty cache directory.
>
> Yes, XDG_CACHE_HOME is the only one needed to fix the BZ.
>
> >
> > I'm very wary about setting HOME or XDG_DATA_HOME or XDG_CONFIG_HOME
> > as I think that is pretty likely to break valid usage.
> >
> > For example, when QEMU is configured to use pulseaudio as its audio
> > backend, I believe this will want to read config files in normal
> > $HOME and/or $XDG_{CONFIG|DATA}_HOME.
>
> I'm glad you mentioned pulseaudio, it's a good example, because pulseaudio
> should never run as root, instead, it will run in context of the 'qemu' user,
> right? This is all fine in session mode, but in system mode, having set none
> of
> the above apart from cache, pulseaudio might try to read from '/' as that's
> QEMU's home dir. Any reasonable app should default to reading configs and data
> from /etc or /usr/local if there's nothing found in HOME or XDG location. But
> when it comes to writing, having apps write anything to root's home doesn't
> seem like a good idea to me, so I believe that at least for system mode, we
> want to override all of the variables.
Yes, ok, for system mode setting all of them is sensible for the reasons
you say.
> I'd also be okay with not redefining the variables for session mode, but the
> following motivated me to do so:
> 1) consistency, if we do it in 1 mode, why not the other (although
>personally, I don't like enforcing session mode that much)
To me one of key reasons for session mode (aside from access to disk images
in $HOME) is that it allows VMs to integrate with services / apps in that
users session, such as PA. So isolating them is going to eliminate that
key feture of session mode & break valid usage IMHO.
> 2) isolation, configs are fine, but any data an app wants to write, I'm
>really not sure how they handle multiple instances, so I approached
> this
>like non-shared filesystems, any 2 apps need to have their own view of
>the location and I also don't want them to even think of trying to
> write
>something to root's home
We don't really expect QEMU (or things it links to) to write to these
dirs, but if they did try SELinux would block it. IMHO if you wanted
stricter isolation then QEMU needs to be running a different UID.
> > Similary if using the GTK frontend these dirs are needed to load
> > the toolkit preferences such as theme.
>
> You mean for ? If so, we don't support GTK.
Yes for graphics. Lack of GTK support is a bug :-)
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/3] Define XDG variables for hypervisor domains
On Wed, Mar 06, 2019 at 04:05:13PM +, Daniel P. Berrangé wrote:
> On Wed, Mar 06, 2019 at 03:41:16PM +0100, Erik Skultety wrote:
> > So, according to this report [1], Mesa enabled on-disk cache for its shaders
> > which it tries to create either under XDG_CACHE_HOME/mesa_shader_cache or
> > under
> > HOME/.cache/mesa_shader_cache. Since libvirt doesn't set XDGs and HOME is
> > only
> > passed iff the QEMU process isn't run with SUID, Mesa will default to the
> > home
> > directory specified in /etc/passwd.
> > Because of this, Mesa will fail to create the cache and QEMU refuses to
> > start
> > the VM (interestingly enough, Intel reports the problem too, but Mesa
> > disables
> > the cache and the VM starts). This series proposes usage of XDG variables to
> > fix the problem by pointing XDG variables to hypervisor specific directory
> > under libvirt's libDir. Additionally, HOME is also enforced for all VM
> > processes and points to the base hypervisor libDir directory.
> > To illustrate this further:
> >
> > system qemu:
> > HOME=/var/lib/libvirt/qemu/domain-5-f-live \
> > XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.local/share \
> > XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.cache \
> > XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.config \
> >
> > session qemu:
> > HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live \
> > XDG_DATA_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.local/share
> > \
> > XDG_CACHE_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.cache
> > \
> > XDG_CONFIG_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.config
> > \
>
> For the bug report IIUC we should only need to set XDG_CACHE_HOME
> as that's the one which needs to be writable and which SELinux quite
> rightly denies. It is also safe to redefine this because cache data
> is liable to be purged at any time, so apps must expect to see an
> empty cache directory.
Yes, XDG_CACHE_HOME is the only one needed to fix the BZ.
>
> I'm very wary about setting HOME or XDG_DATA_HOME or XDG_CONFIG_HOME
> as I think that is pretty likely to break valid usage.
>
> For example, when QEMU is configured to use pulseaudio as its audio
> backend, I believe this will want to read config files in normal
> $HOME and/or $XDG_{CONFIG|DATA}_HOME.
I'm glad you mentioned pulseaudio, it's a good example, because pulseaudio
should never run as root, instead, it will run in context of the 'qemu' user,
right? This is all fine in session mode, but in system mode, having set none of
the above apart from cache, pulseaudio might try to read from '/' as that's
QEMU's home dir. Any reasonable app should default to reading configs and data
from /etc or /usr/local if there's nothing found in HOME or XDG location. But
when it comes to writing, having apps write anything to root's home doesn't
seem like a good idea to me, so I believe that at least for system mode, we
want to override all of the variables.
I'd also be okay with not redefining the variables for session mode, but the
following motivated me to do so:
1) consistency, if we do it in 1 mode, why not the other (although
personally, I don't like enforcing session mode that much)
2) isolation, configs are fine, but any data an app wants to write, I'm
really not sure how they handle multiple instances, so I approached this
like non-shared filesystems, any 2 apps need to have their own view of
the location and I also don't want them to even think of trying to write
something to root's home
>
> Similary if using the GTK frontend these dirs are needed to load
> the toolkit preferences such as theme.
You mean for ? If so, we don't support GTK.
>
> I expect there are other relevant config files that would be
> affected too.
>
> >From a security POV these files should not be a problem since they
> would all be read-only from QEMU's POV.
Erik
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/3] Define XDG variables for hypervisor domains
On Wed, Mar 06, 2019 at 03:41:16PM +0100, Erik Skultety wrote:
> So, according to this report [1], Mesa enabled on-disk cache for its shaders
> which it tries to create either under XDG_CACHE_HOME/mesa_shader_cache or
> under
> HOME/.cache/mesa_shader_cache. Since libvirt doesn't set XDGs and HOME is only
> passed iff the QEMU process isn't run with SUID, Mesa will default to the home
> directory specified in /etc/passwd.
> Because of this, Mesa will fail to create the cache and QEMU refuses to start
> the VM (interestingly enough, Intel reports the problem too, but Mesa disables
> the cache and the VM starts). This series proposes usage of XDG variables to
> fix the problem by pointing XDG variables to hypervisor specific directory
> under libvirt's libDir. Additionally, HOME is also enforced for all VM
> processes and points to the base hypervisor libDir directory.
> To illustrate this further:
>
> system qemu:
> HOME=/var/lib/libvirt/qemu/domain-5-f-live \
> XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.local/share \
> XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.cache \
> XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.config \
>
> session qemu:
> HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live \
> XDG_DATA_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.local/share
> \
> XDG_CACHE_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.cache
> \
> XDG_CONFIG_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.config
> \
For the bug report IIUC we should only need to set XDG_CACHE_HOME
as that's the one which needs to be writable and which SELinux quite
rightly denies. It is also safe to redefine this because cache data
is liable to be purged at any time, so apps must expect to see an
empty cache directory.
I'm very wary about setting HOME or XDG_DATA_HOME or XDG_CONFIG_HOME
as I think that is pretty likely to break valid usage.
For example, when QEMU is configured to use pulseaudio as its audio
backend, I believe this will want to read config files in normal
$HOME and/or $XDG_{CONFIG|DATA}_HOME.
Similary if using the GTK frontend these dirs are needed to load
the toolkit preferences such as theme.
I expect there are other relevant config files that would be
affected too.
>From a security POV these files should not be a problem since they
would all be read-only from QEMU's POV.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1659484
>
> Erik Skultety (3):
> qemu: command: Introduce virCommandAddEnvXDG helper
> qemu: Introduce qemuCommandEnvSetup helper
> qemu: command: Override HOME variable for QEMU processes
>
> src/libvirt_private.syms | 1 +
> src/qemu/qemu_command.c | 26 ++-
> src/qemu/qemu_command.h | 3 +++
> src/util/vircommand.c | 21 +++
> src/util/vircommand.h | 2 ++
> .../aarch64-aavmf-virtio-mmio.args| 5 +++-
> tests/qemuxml2argvdata/aarch64-acpi-uefi.args | 5 +++-
> .../aarch64-cpu-passthrough.args | 5 +++-
> tests/qemuxml2argvdata/aarch64-gic-host.args | 5 +++-
> .../aarch64-gic-none-tcg.args | 5 +++-
> tests/qemuxml2argvdata/aarch64-gic-v2.args| 5 +++-
> tests/qemuxml2argvdata/aarch64-gic-v3.args| 5 +++-
> .../aarch64-kvm-32-on-64.args | 5 +++-
> .../aarch64-noacpi-nouefi.args| 5 +++-
> .../qemuxml2argvdata/aarch64-noacpi-uefi.args | 5 +++-
> .../qemuxml2argvdata/aarch64-pci-serial.args | 5 +++-
> .../aarch64-traditional-pci.args | 5 +++-
> .../aarch64-usb-controller-nec-xhci.args | 5 +++-
> .../aarch64-usb-controller-qemu-xhci.args | 5 +++-
> .../aarch64-video-default.args| 5 +++-
> .../aarch64-video-virtio-gpu-pci.args | 5 +++-
> .../aarch64-virt-2.6-virtio-pci-default.args | 5 +++-
> .../aarch64-virt-default-nic.args | 5 +++-
> .../aarch64-virt-headless.aarch64-latest.args | 5 +++-
> .../qemuxml2argvdata/aarch64-virt-virtio.args | 5 +++-
> .../aarch64-virtio-pci-default.args | 5 +++-
> .../aarch64-virtio-pci-manual-addresses.args | 5 +++-
> tests/qemuxml2argvdata/acpi-table.args| 5 +++-
> .../arm-vexpressa9-basic.args | 5 +++-
> .../arm-vexpressa9-nodevs.args| 5 +++-
> .../arm-vexpressa9-virtio.args| 5 +++-
> tests/qemuxml2argvdata/arm-virt-virtio.args | 5 +++-
> tests/qemuxml2argvdata/autoindex.args | 5 +++-
> .../qemuxml2argvdata/balloon-ccw-deflate.args | 5 +++-
> .../qemuxml2argvdata/balloon-device-auto.args | 5 +++-
> .../balloon-device-deflate-off.args | 5 +++-
> .../balloon-device-deflate.args | 5 +++-
> .../balloon-device-period.args| 5 +++-
> tests/qemuxml2argvdata/balloon-device.args| 5 +++-
>
[libvirt] [PATCH 0/3] Define XDG variables for hypervisor domains
So, according to this report [1], Mesa enabled on-disk cache for its shaders which it tries to create either under XDG_CACHE_HOME/mesa_shader_cache or under HOME/.cache/mesa_shader_cache. Since libvirt doesn't set XDGs and HOME is only passed iff the QEMU process isn't run with SUID, Mesa will default to the home directory specified in /etc/passwd. Because of this, Mesa will fail to create the cache and QEMU refuses to start the VM (interestingly enough, Intel reports the problem too, but Mesa disables the cache and the VM starts). This series proposes usage of XDG variables to fix the problem by pointing XDG variables to hypervisor specific directory under libvirt's libDir. Additionally, HOME is also enforced for all VM processes and points to the base hypervisor libDir directory. To illustrate this further: system qemu: HOME=/var/lib/libvirt/qemu/domain-5-f-live \ XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.local/share \ XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.cache \ XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.config \ session qemu: HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live \ XDG_DATA_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.local/share \ XDG_CACHE_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.cache \ XDG_CONFIG_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.config \ [1] https://bugzilla.redhat.com/show_bug.cgi?id=1659484 Erik Skultety (3): qemu: command: Introduce virCommandAddEnvXDG helper qemu: Introduce qemuCommandEnvSetup helper qemu: command: Override HOME variable for QEMU processes src/libvirt_private.syms | 1 + src/qemu/qemu_command.c | 26 ++- src/qemu/qemu_command.h | 3 +++ src/util/vircommand.c | 21 +++ src/util/vircommand.h | 2 ++ .../aarch64-aavmf-virtio-mmio.args| 5 +++- tests/qemuxml2argvdata/aarch64-acpi-uefi.args | 5 +++- .../aarch64-cpu-passthrough.args | 5 +++- tests/qemuxml2argvdata/aarch64-gic-host.args | 5 +++- .../aarch64-gic-none-tcg.args | 5 +++- tests/qemuxml2argvdata/aarch64-gic-v2.args| 5 +++- tests/qemuxml2argvdata/aarch64-gic-v3.args| 5 +++- .../aarch64-kvm-32-on-64.args | 5 +++- .../aarch64-noacpi-nouefi.args| 5 +++- .../qemuxml2argvdata/aarch64-noacpi-uefi.args | 5 +++- .../qemuxml2argvdata/aarch64-pci-serial.args | 5 +++- .../aarch64-traditional-pci.args | 5 +++- .../aarch64-usb-controller-nec-xhci.args | 5 +++- .../aarch64-usb-controller-qemu-xhci.args | 5 +++- .../aarch64-video-default.args| 5 +++- .../aarch64-video-virtio-gpu-pci.args | 5 +++- .../aarch64-virt-2.6-virtio-pci-default.args | 5 +++- .../aarch64-virt-default-nic.args | 5 +++- .../aarch64-virt-headless.aarch64-latest.args | 5 +++- .../qemuxml2argvdata/aarch64-virt-virtio.args | 5 +++- .../aarch64-virtio-pci-default.args | 5 +++- .../aarch64-virtio-pci-manual-addresses.args | 5 +++- tests/qemuxml2argvdata/acpi-table.args| 5 +++- .../arm-vexpressa9-basic.args | 5 +++- .../arm-vexpressa9-nodevs.args| 5 +++- .../arm-vexpressa9-virtio.args| 5 +++- tests/qemuxml2argvdata/arm-virt-virtio.args | 5 +++- tests/qemuxml2argvdata/autoindex.args | 5 +++- .../qemuxml2argvdata/balloon-ccw-deflate.args | 5 +++- .../qemuxml2argvdata/balloon-device-auto.args | 5 +++- .../balloon-device-deflate-off.args | 5 +++- .../balloon-device-deflate.args | 5 +++- .../balloon-device-period.args| 5 +++- tests/qemuxml2argvdata/balloon-device.args| 5 +++- .../balloon-mmio-deflate.args | 5 +++- tests/qemuxml2argvdata/bios-nvram-secure.args | 5 +++- tests/qemuxml2argvdata/bios-nvram.args| 5 +++- tests/qemuxml2argvdata/bios.args | 5 +++- .../blkdeviotune-group-num.args | 5 +++- .../blkdeviotune-max-length.args | 5 +++- tests/qemuxml2argvdata/blkdeviotune-max.args | 5 +++- tests/qemuxml2argvdata/blkiotune-device.args | 5 +++- tests/qemuxml2argvdata/blkiotune.args | 5 +++- tests/qemuxml2argvdata/boot-cdrom.args| 5 +++- tests/qemuxml2argvdata/boot-complex.args | 5 +++- tests/qemuxml2argvdata/boot-floppy-q35.args | 5 +++- tests/qemuxml2argvdata/boot-floppy.args | 5 +++- .../boot-menu-disable-drive.args | 5 +++- tests/qemuxml2argvdata/boot-menu-disable.args | 5 +++- .../boot-menu-enable-with-timeout.args| 5 +++- tests/qemuxml2argvdata/boot-menu-enable.args | 5 +++- tests/qemuxml2argvdata/boot-multi.args| 5 +++- tests/qemuxml2argvdata/boot-network.args | 5 +++-
