[libvirt] [PATCH 1/3] firmware: include arch and features in firmware file list

[Richard W.M. Jones]

On Mon, Oct 03, 2016 at 04:49:47PM +0100, Daniel P. Berrange wrote:
> --- a/src/qemu/qemu.conf
> +++ b/src/qemu/qemu.conf
> @@ -595,16 +595,22 @@
>  # using this master file as image. Each UEFI firmware can,
>  # however, have different variables store. Therefore the nvram is
>  # a list of strings when a single item is in form of:
> -#   ${PATH_TO_UEFI_FW}:${PATH_TO_UEFI_VARS}.
> +#
> +#   ${PATH_TO_UEFI_FW}:${PATH_TO_UEFI_VARS}:${ARCH}[:${FEATURE}:...].
> +#
> +# Current valid features include:
> +#
> +#   'secboot' - the firmware has secure boot enabled
> +#
>  # Later, when libvirt creates per domain variable store, this list is
>  # searched for the master image. The UEFI firmware can be called
>  # differently for different guest architectures. For instance, it's OVMF
>  # for x86_64 and i686, but it's AAVMF for aarch64. The libvirt default
>  # follows this scheme.
>  #nvram = [
> -#   "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd",
> -#   "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd",
> -#   "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd"
> +#   "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd:x86_64",
> +#   "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd:x86_64:secboot",
> +#   "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd:aarch64"

This is all good, and could remove a duplicate copy of this database
which is currently stored in libguestfs & virt-v2v:

https://github.com/libguestfs/libguestfs/blob/master/generator/uefi.ml#L30

The flags (arch, secboot) even precisely match the ones we currently
need to store.

Unfortunately it's a case of so near and yet so far.  You're proposing
this essentially static and non-secret data be stored in
/etc/libvirt/qemu.conf, which is not readable as non-root.  virt-v2v
(which can run as non-root) would still need to store a duplicate copy
of the data.

I don't see any need for config files to default to unreadable, it's
just security through obscurity (and not even obscure), but assuming
that isn't going to change, please put this into a different file
which can be read as non-root.  There is literally nothing possibly
secret about it, it's just the location of some files.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org