[libvirt] [PATCH] qemu: use 'bochs' video type by default for UEFI domains
The 'bochs' video device doesn't have any legacy vga emulation so the attack surface is much lower. It works with OVMF, so UEFI guests should not see any functional difference to VGA. https://bugzilla.redhat.com/show_bug.cgi?id=1707119 Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> --- NOTE: You may run into an error when trying to use the bochs video device. For example: error: internal error: process exited while connecting to monitor: 2019-08-28T21:32:20.134546Z qemu-system-x86_64: -device bochs-display,id=video0,vgamem=16384k,bus=pcie.0,addr=0x1: failed to find romfile "vgabios-bochs-display.bin" This should be solved in e.g. Fedora 31 with newer releases of seabios/qemu. As a temporary workaround, you can symlink the appropriate vgabios file under /usr/share/qemu/. src/qemu/qemu_domain.c | 19 +++++---- src/qemu/qemu_domain.h | 1 + .../video-default-nouefi.x86_64-latest.args | 36 +++++++++++++++++ .../qemuxml2argvdata/video-default-nouefi.xml | 20 ++++++++++ .../video-default-uefi.x86_64-latest.args | 40 +++++++++++++++++++ tests/qemuxml2argvdata/video-default-uefi.xml | 22 ++++++++++ tests/qemuxml2argvtest.c | 2 + 7 files changed, 133 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxml2argvdata/video-default-nouefi.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/video-default-nouefi.xml create mode 100644 tests/qemuxml2argvdata/video-default-uefi.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/video-default-uefi.xml diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 4998474dc9..7ecb89ac84 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -4584,6 +4584,14 @@ qemuDomainValidateCpuCount(const virDomainDef *def, } +static bool +qemuDomainDefIsUEFI(const virDomainDef *def) +{ + return ((def->os.firmware == VIR_DOMAIN_OS_DEF_FIRMWARE_EFI || + (def->os.loader && def->os.loader->type == + VIR_DOMAIN_LOADER_TYPE_PFLASH))); +} + static int qemuDomainDefValidate(const virDomainDef *def, virCapsPtr caps ATTRIBUTE_UNUSED, @@ -4606,10 +4614,7 @@ qemuDomainDefValidate(const virDomainDef *def, } /* On x86, UEFI requires ACPI */ - if ((def->os.firmware == VIR_DOMAIN_OS_DEF_FIRMWARE_EFI || - (def->os.loader && - def->os.loader->type == VIR_DOMAIN_LOADER_TYPE_PFLASH)) && - ARCH_IS_X86(def->os.arch) && + if (qemuDomainDefIsUEFI(def) && ARCH_IS_X86(def->os.arch) && def->features[VIR_DOMAIN_FEATURE_ACPI] != VIR_TRISTATE_SWITCH_ON) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("UEFI requires ACPI on this architecture")); @@ -4619,9 +4624,7 @@ qemuDomainDefValidate(const virDomainDef *def, /* On aarch64, ACPI requires UEFI */ if (def->features[VIR_DOMAIN_FEATURE_ACPI] == VIR_TRISTATE_SWITCH_ON && def->os.arch == VIR_ARCH_AARCH64 && - (def->os.firmware != VIR_DOMAIN_OS_DEF_FIRMWARE_EFI && - (!def->os.loader || - def->os.loader->type != VIR_DOMAIN_LOADER_TYPE_PFLASH))) { + !qemuDomainDefIsUEFI(def)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("ACPI requires UEFI on this architecture")); goto cleanup; @@ -7452,6 +7455,8 @@ qemuDomainDeviceVideoDefPostParse(virDomainVideoDefPtr video, qemuDomainIsRISCVVirt(def) || ARCH_IS_S390(def->os.arch)) video->type = VIR_DOMAIN_VIDEO_TYPE_VIRTIO; + else if (qemuDomainDefIsUEFI(def)) + video->type = VIR_DOMAIN_VIDEO_TYPE_BOCHS; else video->type = VIR_DOMAIN_VIDEO_TYPE_CIRRUS; } diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index 37a00323a7..c6deab1c52 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -923,6 +923,7 @@ bool qemuDomainHasBuiltinIDE(const virDomainDef *def); bool qemuDomainNeedsFDC(const virDomainDef *def); bool qemuDomainSupportsPCI(virDomainDefPtr def, virQEMUCapsPtr qemuCaps); +bool qemuDomainIsUEFI(const virDomainDef *def); void qemuDomainUpdateCurrentMemorySize(virDomainObjPtr vm); diff --git a/tests/qemuxml2argvdata/video-default-nouefi.x86_64-latest.args b/tests/qemuxml2argvdata/video-default-nouefi.x86_64-latest.args new file mode 100644 index 0000000000..f0c9e36594 --- /dev/null +++ b/tests/qemuxml2argvdata/video-default-nouefi.x86_64-latest.args @@ -0,0 +1,36 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/tmp/lib/domain--1-guest \ +USER=test \ +LOGNAME=test \ +XDG_DATA_HOME=/tmp/lib/domain--1-guest/.local/share \ +XDG_CACHE_HOME=/tmp/lib/domain--1-guest/.cache \ +XDG_CONFIG_HOME=/tmp/lib/domain--1-guest/.config \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-x86_64 \ +-name guest=guest,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,\ +file=/tmp/lib/domain--1-guest/master-key.aes \ +-machine q35,accel=tcg,usb=off,dump-guest-core=off \ +-cpu Haswell \ +-m 1024 \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid 26b73eb7-f8c4-4541-ae6f-06607a1b21c3 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=1729,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,\ +multifunction=on,addr=0x2 \ +-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \ +-device qemu-xhci,id=usb,bus=pci.1,addr=0x0 \ +-device cirrus-vga,id=video0,bus=pcie.0,addr=0x1 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,\ +resourcecontrol=deny \ +-msg timestamp=on diff --git a/tests/qemuxml2argvdata/video-default-nouefi.xml b/tests/qemuxml2argvdata/video-default-nouefi.xml new file mode 100644 index 0000000000..7db2bedf6c --- /dev/null +++ b/tests/qemuxml2argvdata/video-default-nouefi.xml @@ -0,0 +1,20 @@ +<domain type='qemu'> + <name>guest</name> + <uuid>26b73eb7-f8c4-4541-ae6f-06607a1b21c3</uuid> + <memory unit='KiB'>1048576</memory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='q35'>hvm</type> + </os> + <features> + <acpi/> + </features> + <cpu mode='custom'> + <model>Haswell</model> + </cpu> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <memballoon model='none'/> + <video/> + </devices> +</domain> diff --git a/tests/qemuxml2argvdata/video-default-uefi.x86_64-latest.args b/tests/qemuxml2argvdata/video-default-uefi.x86_64-latest.args new file mode 100644 index 0000000000..75c599f321 --- /dev/null +++ b/tests/qemuxml2argvdata/video-default-uefi.x86_64-latest.args @@ -0,0 +1,40 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/tmp/lib/domain--1-guest \ +USER=test \ +LOGNAME=test \ +XDG_DATA_HOME=/tmp/lib/domain--1-guest/.local/share \ +XDG_CACHE_HOME=/tmp/lib/domain--1-guest/.cache \ +XDG_CONFIG_HOME=/tmp/lib/domain--1-guest/.config \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-x86_64 \ +-name guest=guest,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,\ +file=/tmp/lib/domain--1-guest/master-key.aes \ +-machine q35,accel=tcg,usb=off,dump-guest-core=off \ +-cpu Haswell \ +-drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,\ +readonly=on \ +-drive file=/var/lib/libvirt/qemu/nvram/guest_VARS.fd,if=pflash,format=raw,\ +unit=1 \ +-m 1024 \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid 26b73eb7-f8c4-4541-ae6f-06607a1b21c3 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=1729,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,\ +multifunction=on,addr=0x2 \ +-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \ +-device qemu-xhci,id=usb,bus=pci.1,addr=0x0 \ +-device bochs-display,id=video0,vgamem=16384k,bus=pcie.0,addr=0x1 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,\ +resourcecontrol=deny \ +-msg timestamp=on diff --git a/tests/qemuxml2argvdata/video-default-uefi.xml b/tests/qemuxml2argvdata/video-default-uefi.xml new file mode 100644 index 0000000000..59e880c78c --- /dev/null +++ b/tests/qemuxml2argvdata/video-default-uefi.xml @@ -0,0 +1,22 @@ +<domain type='qemu'> + <name>guest</name> + <uuid>26b73eb7-f8c4-4541-ae6f-06607a1b21c3</uuid> + <memory unit='KiB'>1048576</memory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='q35'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/guest_VARS.fd</nvram> + </os> + <features> + <acpi/> + </features> + <cpu mode='custom'> + <model>Haswell</model> + </cpu> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <memballoon model='none'/> + <video/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 9395cc19a2..671e79e631 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -2045,6 +2045,8 @@ mymain(void) DO_TEST("video-none-device", QEMU_CAPS_VNC); DO_TEST_PARSE_ERROR("video-invalid-multiple-devices", NONE); + DO_TEST_CAPS_LATEST("video-default-uefi"); + DO_TEST_CAPS_LATEST("video-default-nouefi"); DO_TEST("virtio-rng-default", QEMU_CAPS_DEVICE_VIRTIO_RNG, -- 2.21.0
On Wed, Aug 28, 2019 at 16:52:39 -0500, Jonathon Jongsma wrote:
The 'bochs' video device doesn't have any legacy vga emulation so the attack surface is much lower. It works with OVMF, so UEFI guests should not see any functional difference to VGA.
https://bugzilla.redhat.com/show_bug.cgi?id=1707119
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> ---
Historically we did not allow change of behaviour when filling in defaults unless the old configuration stopped to be supported by qemu and we could detect it. I don't thik this case can be excused.
NOTE: You may run into an error when trying to use the bochs video device. For example:
error: internal error: process exited while connecting to monitor: 2019-08-28T21:32:20.134546Z qemu-system-x86_64: -device bochs-display,id=video0,vgamem=16384k,bus=pcie.0,addr=0x1: failed to find romfile "vgabios-bochs-display.bin"
This should be solved in e.g. Fedora 31 with newer releases of seabios/qemu. As a temporary workaround, you can symlink the appropriate vgabios file under /usr/share/qemu/.
Similarly I don't think this is acceptable.
src/qemu/qemu_domain.c | 19 +++++---- src/qemu/qemu_domain.h | 1 + .../video-default-nouefi.x86_64-latest.args | 36 +++++++++++++++++ .../qemuxml2argvdata/video-default-nouefi.xml | 20 ++++++++++ .../video-default-uefi.x86_64-latest.args | 40 +++++++++++++++++++ tests/qemuxml2argvdata/video-default-uefi.xml | 22 ++++++++++ tests/qemuxml2argvtest.c | 2 + 7 files changed, 133 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxml2argvdata/video-default-nouefi.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/video-default-nouefi.xml create mode 100644 tests/qemuxml2argvdata/video-default-uefi.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/video-default-uefi.xml
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 4998474dc9..7ecb89ac84 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -4584,6 +4584,14 @@ qemuDomainValidateCpuCount(const virDomainDef *def, }
+static bool +qemuDomainDefIsUEFI(const virDomainDef *def) +{ + return ((def->os.firmware == VIR_DOMAIN_OS_DEF_FIRMWARE_EFI || + (def->os.loader && def->os.loader->type == + VIR_DOMAIN_LOADER_TYPE_PFLASH))); +} + static int qemuDomainDefValidate(const virDomainDef *def, virCapsPtr caps ATTRIBUTE_UNUSED, @@ -4606,10 +4614,7 @@ qemuDomainDefValidate(const virDomainDef *def, }
/* On x86, UEFI requires ACPI */ - if ((def->os.firmware == VIR_DOMAIN_OS_DEF_FIRMWARE_EFI || - (def->os.loader && - def->os.loader->type == VIR_DOMAIN_LOADER_TYPE_PFLASH)) && - ARCH_IS_X86(def->os.arch) && + if (qemuDomainDefIsUEFI(def) && ARCH_IS_X86(def->os.arch) && def->features[VIR_DOMAIN_FEATURE_ACPI] != VIR_TRISTATE_SWITCH_ON) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("UEFI requires ACPI on this architecture")); @@ -4619,9 +4624,7 @@ qemuDomainDefValidate(const virDomainDef *def, /* On aarch64, ACPI requires UEFI */ if (def->features[VIR_DOMAIN_FEATURE_ACPI] == VIR_TRISTATE_SWITCH_ON && def->os.arch == VIR_ARCH_AARCH64 && - (def->os.firmware != VIR_DOMAIN_OS_DEF_FIRMWARE_EFI && - (!def->os.loader || - def->os.loader->type != VIR_DOMAIN_LOADER_TYPE_PFLASH))) { + !qemuDomainDefIsUEFI(def)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("ACPI requires UEFI on this architecture")); goto cleanup;
The three hunks above are refactors not functionally connected with the behaviour change later, thus they should be in a separate patch.
@@ -7452,6 +7455,8 @@ qemuDomainDeviceVideoDefPostParse(virDomainVideoDefPtr video, qemuDomainIsRISCVVirt(def) || ARCH_IS_S390(def->os.arch)) video->type = VIR_DOMAIN_VIDEO_TYPE_VIRTIO; + else if (qemuDomainDefIsUEFI(def)) + video->type = VIR_DOMAIN_VIDEO_TYPE_BOCHS;
'bochs-display' seems to be supported starting qemu 3.0.0, but pflash/ovmf starting qemu 1.7, so this can result in invalid configuration for older qemu versions.
else video->type = VIR_DOMAIN_VIDEO_TYPE_CIRRUS; }
On Thu, 2019-08-29 at 08:22 +0200, Peter Krempa wrote:
On Wed, Aug 28, 2019 at 16:52:39 -0500, Jonathon Jongsma wrote:
@@ -7452,6 +7455,8 @@ qemuDomainDeviceVideoDefPostParse(virDomainVideoDefPtr video, qemuDomainIsRISCVVirt(def) || ARCH_IS_S390(def->os.arch)) video->type = VIR_DOMAIN_VIDEO_TYPE_VIRTIO; + else if (qemuDomainDefIsUEFI(def)) + video->type = VIR_DOMAIN_VIDEO_TYPE_BOCHS;
'bochs-display' seems to be supported starting qemu 3.0.0, but pflash/ovmf starting qemu 1.7, so this can result in invalid configuration for older qemu versions.
Agreed, we can't just change the default like this. If we want new guests to use bochs-display, then that needs to be wired up in virt-manager in a way that's conditional to support being available both on the host and in the guest. Incidentally, and I haven't followed this closely so apologies if I'm asking a silly question, if the point of bochs-display is to have a video device without legacy VGA emulation then why aren't we using the existing virtio-gpu, which has been around a lot longer and has better support throughout the stack, instead? Please by all means *do* send the patch introducing qemuDomainDefIsUEFI() separately, it's a pretty nice cleanup. -- Andrea Bolognani / Red Hat / Virtualization
Hi,
Incidentally, and I haven't followed this closely so apologies if I'm asking a silly question, if the point of bochs-display is to have a video device without legacy VGA emulation then why aren't we using the existing virtio-gpu, which has been around a lot longer and has better support throughout the stack, instead?
Well, virtio-gpu (on x86) actually is "-device virtio-vga". That comes with legacy VGA emulation, for the boot display ... For UEFI guests with virtio-gpu support it is possible to use "-display virtio-gpu-pci" instead (simliar to arm). Only drawback is that you can't have a EFI GOB with virtio-gpu-pci, so efifb doesn't work. Linux kernel console shows up after the virtio-gpu driver loads, which is rather late compared to efifb. For UEFI guests without virtio-gpu support "-device virtio-gpu-pci" will not work due to the lack of EFI GOB support. For these guests "-display bochs-display" should preferred over "-device VGA", to get rid of the unused legacy VGA emulation (and thereby reduce the attack surface). Also note that bochs-display can be plugged into pcie slots (that is true for virtio-gpu-pci too btw). Not sure whenever implementing this works better in libvirt or libosinfo. cheers, Gerd
On Thu, Aug 29, 2019 at 12:19:49PM +0200, Gerd Hoffmann wrote:
Hi,
Incidentally, and I haven't followed this closely so apologies if I'm asking a silly question, if the point of bochs-display is to have a video device without legacy VGA emulation then why aren't we using the existing virtio-gpu, which has been around a lot longer and has better support throughout the stack, instead?
Well, virtio-gpu (on x86) actually is "-device virtio-vga". That comes with legacy VGA emulation, for the boot display ...
For UEFI guests with virtio-gpu support it is possible to use "-display virtio-gpu-pci" instead (simliar to arm). Only drawback is that you can't have a EFI GOB with virtio-gpu-pci, so efifb doesn't work. Linux kernel console shows up after the virtio-gpu driver loads, which is rather late compared to efifb.
For UEFI guests without virtio-gpu support "-device virtio-gpu-pci" will not work due to the lack of EFI GOB support. For these guests "-display bochs-display" should preferred over "-device VGA", to get rid of the unused legacy VGA emulation (and thereby reduce the attack surface).
Also note that bochs-display can be plugged into pcie slots (that is true for virtio-gpu-pci too btw).
BTW a while ago you did a really helpful blog post describing best usage for each display type https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/ there's been quite a few changes since then with virtio-vga and bochs-display arriving, so it would be awesome if you wrote an updated blog post, or even added something to the main qemu-doc.texi doc giving recommandations for what to use for guests. 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 :|
On Thu, Aug 29, 2019 at 12:21 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
Hi,
Incidentally, and I haven't followed this closely so apologies if I'm asking a silly question, if the point of bochs-display is to have a video device without legacy VGA emulation then why aren't we using the existing virtio-gpu, which has been around a lot longer and has better support throughout the stack, instead?
Well, virtio-gpu (on x86) actually is "-device virtio-vga". That comes with legacy VGA emulation, for the boot display ...
For UEFI guests with virtio-gpu support it is possible to use "-display virtio-gpu-pci" instead (simliar to arm). Only drawback is that you can't have a EFI GOB with virtio-gpu-pci, so efifb doesn't work. Linux kernel console shows up after the virtio-gpu driver loads, which is rather late compared to efifb.
For UEFI guests without virtio-gpu support "-device virtio-gpu-pci" will not work due to the lack of EFI GOB support. For these guests "-display bochs-display" should preferred over "-device VGA", to get rid of the unused legacy VGA emulation (and thereby reduce the attack surface).
Also note that bochs-display can be plugged into pcie slots (that is true for virtio-gpu-pci too btw).
Not sure whenever implementing this works better in libvirt or libosinfo.
I do believe this piece should go to libosinfo. However, the decision of what exactly to use due to lack of this or that device, should be done in the management apps, in a similar way of what was done for the q35 work.
cheers, Gerd
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Aug 29, 2019 at 08:22:55AM +0200, Peter Krempa wrote:
On Wed, Aug 28, 2019 at 16:52:39 -0500, Jonathon Jongsma wrote:
The 'bochs' video device doesn't have any legacy vga emulation so the attack surface is much lower. It works with OVMF, so UEFI guests should not see any functional difference to VGA.
https://bugzilla.redhat.com/show_bug.cgi?id=1707119
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> ---
Historically we did not allow change of behaviour when filling in defaults unless the old configuration stopped to be supported by qemu and we could detect it. I don't thik this case can be excused.
Yep, we can't do this, and in any case modern guests should likely be given virtio-vga instead, which can be decided via libosinfo rules. 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 :|
participants (6)
-
Andrea Bolognani -
Daniel P. Berrangé -
Fabiano Fidêncio -
Gerd Hoffmann -
Jonathon Jongsma -
Peter Krempa