Debian Bug report logs - #764918
Please split into OVMF_VARS.fd and OVMF_CODE.fd

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libvirt-daemon-system: nvramoptions

Date: Sat, 11 Oct 2014 16:53:19 +0200

Package: libvirt-daemon-system
Version: 1.2.9-2
Severity: normal


Hi.

As of now qemu.conf supports NVRAM options:
# Location of master nvram file
#
# When a domain is configured to use UEFI instead of standard
# BIOS it may use a separate storage for UEFI variables. If
# that's the case libvirt creates the variable store per domain
# 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}.
# Later, when libvirt creates per domain variable store, this
# list is searched for the master image.
#nvram = [ "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" ]


1) The locations of the respective Debian package’s file (ovmf)
seems to be different:
$ dpkg -L ovmf 
/usr/share/ovmf/OVMF.fd


2) With respect to the OVMF_VARS.fd I'm a bit unsure whether I
understand it correctly.
Is this just a "template" for the UEFI variables (i.e. how
the ones for a new VM are initialised)? Or is it the storage
for the variables from the VMs?
Anyway,... in the first case it seems this file should rather
go to /etc/libvirt/, and in the second case it seems it should
go to /var/lib/libvirt/

Cheers,
Chris.

Message #10 received at 764834@bugs.debian.org (full text, mbox, reply):

From: Guido Günther <agx@sigxcpu.org>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 764834@bugs.debian.org

Subject: Re: [Pkg-libvirt-maintainers] Bug#764834: libvirt-daemon-system: nvramoptions

Date: Sat, 11 Oct 2014 18:28:13 +0200

severity 764834 minor
thanks

On Sat, Oct 11, 2014 at 04:53:19PM +0200, Christoph Anton Mitterer wrote:
> Package: libvirt-daemon-system
> Version: 1.2.9-2
> Severity: normal
> 
> 
> Hi.
> 
> As of now qemu.conf supports NVRAM options:
> # Location of master nvram file
> #
> # When a domain is configured to use UEFI instead of standard
> # BIOS it may use a separate storage for UEFI variables. If
> # that's the case libvirt creates the variable store per domain
> # 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}.
> # Later, when libvirt creates per domain variable store, this
> # list is searched for the master image.
> #nvram = [ "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" ]
> 
> 
> 1) The locations of the respective Debian package’s file (ovmf)
> seems to be different:
> $ dpkg -L ovmf 
> /usr/share/ovmf/OVMF.fd
> 
> 
> 2) With respect to the OVMF_VARS.fd I'm a bit unsure whether I
> understand it correctly.
> Is this just a "template" for the UEFI variables (i.e. how
> the ones for a new VM are initialised)? Or is it the storage
> for the variables from the VMs?
> Anyway,... in the first case it seems this file should rather
> go to /etc/libvirt/, and in the second case it seems it should
> go to /var/lib/libvirt/
> 
> Cheers,
> Chris.
> 
> _______________________________________________
> Pkg-libvirt-maintainers mailing list
> Pkg-libvirt-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers

Message #15 received at 764834@bugs.debian.org (full text, mbox, reply):

From: Laszlo Ersek <lersek@redhat.com>

To: 764834@bugs.debian.org

Subject: split files

Date: Sat, 11 Oct 2014 23:51:40 +0200

OVMF_VARS.fd and OVMF_CODE.fd are split files. OVMF.fd is a unified
file. Concatenating the first two yields the third.

OVMF_VARS.fd is a variable store template. OVMF_CODE.fd is the fimrware
executable. When you create a new VM, libvirt instantiates the VM's own,
private variable store by copying OVMF_VARS.fd. And, all VMs share the
OVMF_CODE.fd binary.

When you update the OVMF package, the varstore template and the
executable are both replaced, but the VMs preserve their own, private
variable stores. This was the reason for implementing the split files --
so that the firmware be possible to update centrally on a host, but the
VMs' varstores remain unaffected.

(If you use a unified file, then the varstore part of that file is not a
template, but a live variable store, and if you replace the entire file,
then the VM loses its variables. In addition, each VM would have a
separate copy of the executable part as well, which would require
touching each VM's copy when updating the firmware on a host system, to
get a central update.)

Regarding the place of OVMF_VARS.fd and OVMF_CODE.fd in the filesystem
-- you put them wherever you want in Debian I guess, but they *really*
correspond to each other. For example, a Secure Boot enabled
OVMF_CODE.fd will not work with varstores copied from an OVMF_VARS.fd
that was the output of a Secure Boot disabled build. IOW, OVMF_VARS.fd
is not a config file for the user to update, it's really the counterpart
of OVMF_CODE.fd.

https://github.com/tianocore/edk2/commit/1c50db8a

Debian's OVMF package should probably be updated, and the installed
files should include the split files (preferably: *only* the split files).

Message #20 received at 764834@bugs.debian.org (full text, mbox, reply):

From: Guido Günther <agx@sigxcpu.org>

To: Laszlo Ersek <lersek@redhat.com>, 764834@bugs.debian.org, ovmf@packages.debian.org

Cc: control@bugs.debian.org

Subject: Re: Bug#764834: split files

Date: Sun, 12 Oct 2014 11:10:04 +0200

clone 764834 -1
retutile -1 Please split into OVMF_VARS.fd and OVMF_CODE.fd
block 764834 -1
severity -1 wishlist
thanks

Hi Lazlo, dear ovmf maintainer,
On Sat, Oct 11, 2014 at 11:51:40PM +0200, Laszlo Ersek wrote:
> OVMF_VARS.fd and OVMF_CODE.fd are split files. OVMF.fd is a unified
> file. Concatenating the first two yields the third.
> 
> OVMF_VARS.fd is a variable store template. OVMF_CODE.fd is the fimrware
> executable. When you create a new VM, libvirt instantiates the VM's own,
> private variable store by copying OVMF_VARS.fd. And, all VMs share the
> OVMF_CODE.fd binary.
> 
> When you update the OVMF package, the varstore template and the
> executable are both replaced, but the VMs preserve their own, private
> variable stores. This was the reason for implementing the split files --
> so that the firmware be possible to update centrally on a host, but the
> VMs' varstores remain unaffected.
> 
> (If you use a unified file, then the varstore part of that file is not a
> template, but a live variable store, and if you replace the entire file,
> then the VM loses its variables. In addition, each VM would have a
> separate copy of the executable part as well, which would require
> touching each VM's copy when updating the firmware on a host system, to
> get a central update.)
> 
> Regarding the place of OVMF_VARS.fd and OVMF_CODE.fd in the filesystem
> -- you put them wherever you want in Debian I guess, but they *really*
> correspond to each other. For example, a Secure Boot enabled
> OVMF_CODE.fd will not work with varstores copied from an OVMF_VARS.fd
> that was the output of a Secure Boot disabled build. IOW, OVMF_VARS.fd
> is not a config file for the user to update, it's really the counterpart
> of OVMF_CODE.fd.
> 
> https://github.com/tianocore/edk2/commit/1c50db8a
> 
> Debian's OVMF package should probably be updated, and the installed
> files should include the split files (preferably: *only* the split files).

thanks a lot for the detailed explanation. Dear ovmf maintainer, can
the files be split?
Cheers,
 -- Guido

Message #37 received at 764918-done@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 764918-done@bugs.debian.org

Subject: Re: Please split into OVMF_VARS.fd and OVMF_CODE.fd

Date: Thu, 2 Apr 2015 12:03:00 -0700

[Message part 1 (text/plain, inline)]

Hello,

I'm closing this bug as 'wontfix'.  I had not wanted to implement this as
described, because "/usr/share" is clearly the wrong place to store the
nvram variable settings as these are obviously per-VM and also not
necessarily owned by root.

However, it appears that recent versions of ovmf also have support for
reading their state from a file named NvVars on the ESP of the configured
disk.  This is a much better option than having a fixed location in /usr.
It also appears to work completely transparently, as my VMs have started
using this feature apparently with no action on my part, and my nvram values
now persist across VM restarts.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #42 received at 764918@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@gmail.com>

To: Steve Langasek <vorlon@debian.org>

Cc: 764918@bugs.debian.org

Subject: Re: Please split into OVMF_VARS.fd and OVMF_CODE.fd

Date: Fri, 03 Apr 2015 01:46:34 +0200

On Thu, 2015-04-02 at 12:03 -0700, Steve Langasek wrote:

> I'm closing this bug as 'wontfix'.  I had not wanted to implement this as
> described, because "/usr/share" is clearly the wrong place to store the
> nvram variable settings as these are obviously per-VM and also not
> necessarily owned by root.
Isn't that just what I've said in the beginning? And now that you're not
going to fixing the issue it will continue to stay at:
/usr/share/ovmf/OVMF.fd
??

Cheers,
Chris.

Message #47 received at 764918@bugs.debian.org (full text, mbox, reply):

From: "Ersek, Laszlo" <lacos@caesar.elte.hu>

To: 764918@bugs.debian.org

Cc: control@bugs.debian.org, lersek@redhat.com

Subject: you do need to provide the split files

Date: Sat, 4 Apr 2015 19:41:57 +0200 (CEST)

reopen 764918
thanks

Hi,

upstream OVMF co-maintainer here again. (From a personal email address this
time, rather than my Red Hat one; I'm on vacation.)

Please read the recently released OVMF whitepaper:

http://www.linux-kvm.org/page/OVMF

Specifically, please search it for occurrences of the string "OVMF_". It
should give you a clear picture.  Please read it carefully.

Anyway, here's a short summary.

(1) The NvVars file on the ESP dates back to the time when we had no working
pflash emulation in qemu + KVM; also no driver for it in OVMF.  NvVars is a
fake variable store that is only writeable before ExitBootServices().

If you update non-volatile UEFI variables in the guest before
ExitBootServices(), they are saved in NvVars immediately.  If you update
them from the runtime OS, the changes are only saved in memory.  If you
reboot the guest (inside the same qemu instance), then the memory changes
are flushed to NvVars.  If you power off the VM after making changes to the
non-volatile variables from the runtime guest OS, then those changes will be
lost.

In short, NvVars is a kludge that used to be necessary for faking
non-volatile UEFI variables to some extent.  It allowed UEFI guest OS
installers to work (because most of those installers reboot the system after
setting up Boot#### and BootOrder).  But it is gravely inferior to a
flash-based varstore, both due to the lifecycle issues mentioned above, and
due to not supporting persistent authenticated variables at all (ie. 
SecureBoot related stuff, PK, KEK, db/dbx).

(2) We *do* have flash chip emulation now, in all of KVM, QEMU, and OVMF. 
Everyone needs to stop using -bios at once (search the whitepaper for it as
well), and start using '-drive if=pflash'.  This is all explained in the
whitepaper.  If you do this, then the UEFI runtime variable services will
work in OVMF as expected -- changes will be made permanent at guest OS
runtime too, and persistent Secure Boot related variables will be available
as well (assuming you build OVMF with -D SECURE_BOOT_ENABLE of course).

(3) Okay, we can now discuss the split files. As I said in an earlier
comment, OVMF.fd is a unified file that contains both a live varstore and a
firmware binary.  This was the only build output file originally, but it is
unsuitable for managing several guests on the same host:

(3a) first, you can't share OVMF.fd between guests. Each of those will want
to store its own private set of variables in the varstore part.  So you'd
have to copy the full file for each guest.

(3b) That would break central firmware updates though. Namely, same as with
SeaBIOS, you might want to update the firmware centrally on a host, by
upgrading the OVMF package, and then each VM should see that update at its
next boot.  However, if you have copied OVMF.fd for each guest, due to (3a),
then the package update would have to replace the relevant (ie.  firmware
executable) portion of each VM's copy.  This cannot work, obviously.

So the solution was to introduce OVMF_CODE.fd and OVMF_VARS.fd as build
output files.  The first file is mapped read-only and shared by all VMs on a
host system.  The second file is *not* mapped at all -- it is a
*template*. When you create a new virtual machine with libvirt-based tools
(virt-manager or virt-install), then libvirt *copies* the varstore template
to a VM-specific file; the pattern for the target file is
"/var/lib/libvirt/qemu/nvram/guestname_VARS.fd".

If you use qemu directly instead, ie. without libvirt, then you are
responsible for this copying step yourself.  (And you can place the copy
wherever you like.)

The end result is that an OVMF package update will update the OVMF_CODE.fd
and OVMF_VARS.fd files, the first of which will be "picked up" by each guest
at its next boot, whereas the updated template will affect (should there be
any changes in it at all) *brand new* VMs only.  Preexistent VMs will see
the firmware binary update (ie.  OVMF_CODE.fd), but they will keep their
private varstores intact.

Again, /usr/share does not store live varstores; only the *template* resides
there.  The OVMF_VARS.fd file stored there should be owned by root:root, and
have file mode bits 0644.  The live varstores will reside under
/var/lib/libvirt/qemu/nvram/, if managed by libvirt (which is the 
recommended way), or wherever else the user chooses to store them, if he 
or she uses qemu directly.

Summary:

- please peruse the OVMF whitepaper,

- "-bios" and NvVars are *strongly* deprecated, and we might even remove
  NvVars in upstream OVMF going forward -- instead, please use two instances
  of the "-drive if=pflash" option; the first for OVMF_CODE.fd, the second
  for the VM-specific *copy* of OVMF_VARS.fd,

- all distributions shipping OVMF should provide OVMF_CODE.fd and
  /OVMF_VARS.fd under usr/share, with the permissions usual for that
  directory tree.  In addition, the unified OVMF.fd should not be provided
  at all, if possible; it only leads to confusion.

Thanks
Laszlo

Message #54 received at 764918@bugs.debian.org (full text, mbox, reply):

From: Yann Dirson <ydirson@free.fr>

To: 764918@bugs.debian.org

Subject: Please split into OVMF_VARS.fd and OVMF_CODE.fd

Date: Sun, 19 Jul 2015 21:12:45 +0200

AFAICT, the UEFI support in libvirt is dependant on the split layout,
and it looks for them in /usr/share/OVMF/, not /usr/share/ovmf/, so a
path adjustment might b in order for vcompatibility with the rest of
the world.

$ strings /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so |grep OVMF
/usr/share/OVMF/OVMF_CODE.fd
/usr/share/OVMF/OVMF_VARS.fd

Because of this, virt-manager 1.2.1 shows UEFI as not usable on
Debian.  Installing split OVMF files in these locations do enable
virt-manager to create UEFI VMs.

Message #61 received at 764918-close@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 764918-close@bugs.debian.org

Subject: Bug#764918: fixed in edk2 0~20150106.5c2d456b-2

Date: Wed, 09 Sep 2015 22:00:17 +0000

Source: edk2
Source-Version: 0~20150106.5c2d456b-2

We believe that the bug you reported is fixed in the latest version of
edk2, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 764918@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Steve Langasek <vorlon@debian.org> (supplier of updated edk2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Thu, 03 Sep 2015 22:08:41 +0000
Source: edk2
Binary: ovmf qemu-efi
Architecture: source all
Version: 0~20150106.5c2d456b-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QEMU Team <pkg-qemu-devel@lists.alioth.debian.org>
Changed-By: Steve Langasek <vorlon@debian.org>
Description:
 ovmf       - UEFI firmware for virtual machines
 qemu-efi   - UEFI firmware for virtual machines
Closes: 764918 796928
Changes:
 edk2 (0~20150106.5c2d456b-2) unstable; urgency=medium
 .
   [ Steve Langasek ]
   * Build-depend on gcc-aarch64-linux-gnu and make qemu-efi an Arch: all
     package.
   * Ship OVMF_CODE.fd and OVMF_VARS.fd for proper EFI variable support.
     Closes: #764918.  Continue shipping OVMF.fd too for now, for
     compatibility.
 .
   [ dann frazier ]
   * qemu-efi: Switch to Intel BDS. This supports a fallback to the removable
     media path (i.e. \EFI\BOOT\BOOTaa64.EFI) as required by the Linaro VM
     Specification.  Closes: #796928.
   * debian/patches/arm64-no-expensive-optimizations.patch: Workaround
     ARM64 compiler issue by disabling certain optimizations.
     Closes: LP #1489560
Checksums-Sha1:
 8fc6bc70911a408f8fa400f2d7a0fd498c8fe848 2154 edk2_0~20150106.5c2d456b-2.dsc
 d828864e2802f2f31a854e1811692176c3017b8a 12452 edk2_0~20150106.5c2d456b-2.debian.tar.xz
 58c9fecf27d62ae67aadf01bdee7d4d7fbdf36e6 971894 ovmf_0~20150106.5c2d456b-2_all.deb
 4f0785c1dd89b0ed149a061f13651eb9b6802652 587324 qemu-efi_0~20150106.5c2d456b-2_all.deb
Checksums-Sha256:
 5abc77d5fb7fef7338471f20cb9f3e606f4417691b967dde7929026da1442996 2154 edk2_0~20150106.5c2d456b-2.dsc
 81ca1933f8e69902dba343417890c9ebee1e52a90858e8138faed6f126e8a663 12452 edk2_0~20150106.5c2d456b-2.debian.tar.xz
 e9a1d623c05e3d3cf36ae49eff1b831659ee34eb5bc3c523d3c53ed49a3f4789 971894 ovmf_0~20150106.5c2d456b-2_all.deb
 ff402c5dfd03750d24dd113181cde07823d4c26f65be1c864ff6fbf7e5dd198c 587324 qemu-efi_0~20150106.5c2d456b-2_all.deb
Files:
 a8c9d87300900bcbf15e927ab68268f9 2154 non-free/misc extra edk2_0~20150106.5c2d456b-2.dsc
 9c4d50fcf35865429de56039e9eb7d8e 12452 non-free/misc extra edk2_0~20150106.5c2d456b-2.debian.tar.xz
 e649d67ad21c9a8c5663ed1a5051f1f7 971894 non-free/misc extra ovmf_0~20150106.5c2d456b-2_all.deb
 48e5fbfb662b49560bf17c2663bce714 587324 non-free/misc extra qemu-efi_0~20150106.5c2d456b-2_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJV6MafAAoJEFaNMPMhshM978wP/j7IgpxdplmbE2V3t9W3fEII
A8fSQCMjixJwijOZHrrqSR6JJzjcFb5lSvQk6fzuVcUDLNxbHOsMAf7Iqo/mU+Ph
cOiZ/belSJ4PLvxpspcT/ekq3JCilli1R6JEkoNKH1LdAMVYrQvjOsgSeTVdVj7y
F71ROFzm7JJhtxNaefTUJ5zPgcwlK11foz7sfyL4uFuqqmqGygcU6tE2FIfmdlFX
z6vjhnnzylym4wgH+iFGLnUQf4/jBbYx55cmP4gZCNdlHFR502tE2ciT61lqe4Yo
45racohnl/pIq7EL8PSsuAzAab9c3KfCW5isupHjDvpaESRrOoblykDIKJVFg3O1
aRLULP+84gfu/z5BH/VZbmNBaq23Ra4Gif5oB4xwsJ6zKK8mojprRpSUdC6P/yFA
lpPjwNNwyNsJElZx1sZkxJmfAMPcReaVOLnsEXHzUoAQpjfD4sTGcXmHRUfG7X6J
OF3lqNmSwBJtw1EgWpQs0LEpf7EAlqL7G1GoIV1v5YzYjpyhaTOSWZn05DFy1lpQ
r5bUSJcMN30RHZg6jP8imIHOMxTXG/5KqeuJ9TGap3AI/ChqIkt5leb/K7BTldYi
i2lv2ZTS9X9A+m/zVVE6KqAjbhMXtopcCeO9vuLhAW3aTLct2Iacx0nQMDv0vf6J
gcJ/s93yx2uLCbARrCA8
=lyKx
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.