[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC] OVMF NVRAM Variable Retention



On Thu, Jun 07, 2018 at 09:59:10AM +0100, Ross Lagerwall wrote:
> On 06/06/2018 04:01 PM, aaron.young@xxxxxxxxxx wrote:
> >    Any comments/suggestions/opinions/caveats on this approach?
> 
> I did this a while back. It is easy enough to do:
> 
> 1) Have Xen load OVMF_code.fd rather than the combined blob.
> 
> 2) Tweak the location in guest memory where hvmloader loads the blob.
> 
> 3) Tweak QEMU to load the OVMF_vars.fd blob at the correct location.
> 
> 4) Start QEMU with emulated flash for OVMF_vars.fd only.
> 
> Tweaking the locations ensures that the various parts of OVMF are at the
> location it expects. If you want, I could probably dig up some patches
> (hacks) which do this.

I don't like to tie UEFI (OVMF) to QEMU. We want to also run guests
with UEFI firmware without QEMU, see below.

> > 
> >    Or any other suggested approaches on how to fix this issue?
> 
> However... I did not like this approach for two reasons:
> 
> 1) Having an emulated flash blob is difficult to manage outside of the guest
> (i.e. populating initial state, updating variables if needed). For
> XenServer, we want more flexibility.
> 
> 2) While Secure Boot can be enabled with this implementation, it is not
> sufficiently secure because the guest is able to write anything it wants to
> the emulated flash. KVM solved this problem with SMM mode but I don't like
> that solution either.
> 
> So I am busy implementing:
> 
> A UEFI driver frontend which implements variable services by proxying
> requests to a backend running in dom0 (could be part of QEMU). This ensures
> security because the guest cannot directly write to the variable storage and
> the authentication checks are done outside of guest context. It allows
> flexibility because the backend can store the variables in any form (e.g. an
> sqlite database) rather than being restricted to an emulated flash blob.

This seems like a good idea, specially because that means we don't
need QEMU to load anything into the guest, and this approach could be
likely used by PVH guests running with UEFI also.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.