From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2EF2621A143F5 for ; Thu, 6 Jul 2017 12:06:58 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 48A4BC045761; Thu, 6 Jul 2017 19:08:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 48A4BC045761 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 48A4BC045761 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-108.phx2.redhat.com [10.3.116.108]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3E3C65450A; Thu, 6 Jul 2017 19:08:37 +0000 (UTC) To: Bill Paul , edk2-devel@lists.01.org Cc: Jason Dickens References: <6703d38b-e99b-c11e-0126-ad24239dacee@grammatech.com> <201707061130.26384.wpaul@windriver.com> From: Laszlo Ersek Message-ID: Date: Thu, 6 Jul 2017 21:08:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <201707061130.26384.wpaul@windriver.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 06 Jul 2017 19:08:38 +0000 (UTC) Subject: Re: OVMF Secure Boot variable storage issue X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 19:06:58 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/06/17 20:30, Bill Paul wrote: > Of all the gin joints in all the towns in all the world, Jason Dickens > had to walk into mine at 10:31:18 on Thursday 06 July 2017 and say: > >> All, >> >> I'm trying to understand why the secure boot variables (PK, KEK, db, >> etc) when using the OVMF build are not retained across reboot? It >> seems that this code uses roughly the same SetVariable, GetVariable2 >> approach as say the PlatformConfig uses to store screen resolution >> (which is retained). Additionally, the NvVars file is being at least >> touched by the secure boot configuration. So why are none of the keys >> retained on the next reboot? > > If you're running OVMF in the QEMU simulator, and you're using the > -bios option, try using the -pflash option instead. > > I know that when using -bios, QEMU only pretends to allow writes to > the firmware region, and if you stop QEMU all changes are discarded. > The same might be true if you just trigger a hard reboot in the > simulator too. > > If you use -pflash instead, your changes will be saved. Note that this > means your OVMF image will be modified, so keep a copy of the original > elsewhere so that you can start over fresh again if you need to. > > (Unfortunately I don't think OVMF has a "load factor defaults" option > in its internal menus.) Libvirt has a good pile of functionality built on top of the split image that I described earlier. For example: In /etc/libvirt/qemu.conf, you can provide an "nvram map", listing several different firmware binaries, with a matching variable store template for each. (Different fw binaries may require different varstore formats: for example, you can run aarch64 guests in emulation (TCG) mode, using the ArmVirtQemu edk2 platform as your virtual firmware, and x86_64 guests in hw virtualization (KVM) mode, using OVMF as your virtual firmware, on the same x86_64 host. These firmwares expect a different flash layout, so they need different varstore templates. Another example is that you can build OVMF with 1M, 2M or 4M (unified) image sizes, and the 4M layout uses a different (much larger) varstore -- so the template is different for that fw binary.) When defining a new VM, a subset of the libvirt client tools allows you to pick a specific firmware binary. And when starting a VM that has no varstore file under /var/lib/libvirt/qemu/nvram, libvirt will map its fw binary to the matching varstore template, and instantiate the VM's own varstore from the template. As a side benefit, if you are fed up with the current contents of your varstore, simply shut down the VM, and delete its varstore file from under /var/lib/libvirt/qemu/nvram. When you next start the VM, libvirtd will re-create the varstore from the pristine template. Libvirt is an insanely powerful and great project -- I can praise it without holding back, as I personally almost never contribute to it --, and I do all my virt development (incl. edk2 development) exclusively with guests that are managed by libvirt. While the QEMU project is similarly powerful and great :) , the QEMU command line is *not* a human interface. (This is not to say that libvirt only composes command lines for the VMMs that it supports -- it does a whole lot of other host management too, such as SELinux labeling of images, setting up migration across the network, configuring virtual networks, handling assigned physical PCI devices, and much more.) Thanks, Laszlo