Re: OVMF Secure Boot variable storage issue

[Konrad Rzeszutek Wilk <konrad@kernel.org>]

On Thu, Jul 06, 2017 at 02:55:27PM -0400, Jason Dickens wrote:
> 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.
> 

That can be changed - it already has the mechanism to "slurp" binary
blobs from the host. The only reason it does that right now is mostly
historic - all BIOS images where compiled in 'hvmloader'.

> 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
> 
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel