From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from placid.grammatech.com (placid1.grammatech.com [98.159.213.246]) (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 0DBCF21CE740B for ; Thu, 6 Jul 2017 11:53:48 -0700 (PDT) Received: from placid.grammatech.com (placid1 [192.168.219.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by placid.grammatech.com (Postfix) with ESMTPS id 23DDAB20A7; Thu, 6 Jul 2017 14:55:28 -0400 (EDT) Received: from [10.233.218.30] (barracuda.grammatech.com [192.168.219.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by placid.grammatech.com (Postfix) with ESMTPSA id 1838DB20A4; Thu, 6 Jul 2017 14:55:28 -0400 (EDT) To: Bill Paul , edk2-devel@lists.01.org References: <6703d38b-e99b-c11e-0126-ad24239dacee@grammatech.com> <201707061130.26384.wpaul@windriver.com> From: Jason Dickens Message-ID: <401a788a-49ea-f68f-7ee1-32daa21af3ee@grammatech.com> Date: Thu, 6 Jul 2017 14:55:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <201707061130.26384.wpaul@windriver.com> 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 18:53:48 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Thanks for the response Bill. If I should recognize your name, I'm sorry, I'm bad with names, but I have been doing a lot of work with Wind River recently (and in the past) so its possible I should. Actually, I should have mentioned I'm using Xen with full virtualization. This means that OVMF firmware can't change without rebuilding Xen. For reasons I don't know, it seems the Xen build uses the firmware image by first converting it to a C array and then compiling it in. However, I'm not sure that's the real issue. As far as I'm aware, OVMF implements NvVars on the VM image to provide non-volatile storage instead of actually modifying the image. As I mentioned, "some" configuration changes do persist such as changing the screen resolution in the OVMF settings. Also I can see that NvVars is updating its modification time after setting secure boot variables. What I'm trying to determine is if there a particular reason or implementation problem that causes secure boot settings not persist. On 7/6/2017 2:30 PM, 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.) > > -Bill > >> I know this was an issue in the past, but I haven't found the resolution? >> >> Jason >> >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel