Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support

[Ross Philipson <Ross.Philipson@xxxxxxxxxx>]

> -----Original Message-----
> From: Cihula, Joseph [mailto:joseph.cihula@xxxxxxxxx]
> Sent: Tuesday, February 21, 2012 3:35 PM
> To: Ian Campbell; Ross Philipson
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
> 
> > From: xen-devel-bounces@xxxxxxxxxxxxx
> > [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Ian Campbell
> > Sent: Tuesday, February 21, 2012 7:21 AM
> >
> > On Tue, 2012-02-21 at 13:42 +0000, Ross Philipson wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
> > > > Sent: Tuesday, February 21, 2012 3:47 AM
> > > > To: Ross Philipson
> > > > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> > > > Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough
> > > > support
> > > >
> > > > On Tue, 2012-02-21 at 02:56 +0000, Ross Philipson wrote:
> > > > > Updates to the layout of the HVM parameter and information page
> > > > > defined in hvm_info_table.h. The SMBIOS pass-through tables are
> > > > > written to the bottom half of this page.
> > > >
> > > > We would like to eventually get rid of the HVM info page and would
> > > > certainly like to avoid adding anything further there. Could this
> > > > data not be supplied via xenstore? Certainly they could and should
> > > > be for the ones controlled by the flags entry which you add.
> > > >
> > > > Ian.
> > > >
> > >
> > > Ah I did not realize that. The original incarnation of this code
> > > came from 2+ years ago. I have no objection to using xenstore but I
> > > did not think xenstore was suitable for passing arbitrary blocks of
> > > binary data (i.e. the raw SMBIOS firmware tables). Perhaps I am
> > > incorrect in this assumption.
> >
> > I think in principal binary data is supported, but its use is
> > discouraged. docs/misc/xenstore.txt talks about it a bit.
> >
> > For well defined entries it should be reasonable to have human
> > readable content in xenstore which simply enable/disables the table
> and perhaps contains some configuration values as appropriate.
> >
> > For adding arbitrary tables I'm less sure what the right answer is.
> > Common header elements in human readable form, payload as hex encoded
> > strings or something? Seems a bit icky though.
> >
> > > I am not sure what other mechanisms could be employed. In other code
> > > I use in out hvmloader, I pass an ACPI SSDT to the hvmloader at
> runtime.
> > > I use a little DMAish interface I built into qemu to push the SSDT
> > > to hvmloader while it is building the ACPI tables. Something like
> > > this could be used but I don't really want to get qemu involved in
> > > this operation.
> >
> > Yes, I think we should avoid that too.
> >
> > > I guess a third option might be to have a facility to load extra
> > > modules/files into the new domain at start time and specify their
> > > gpa's in xenstore. They could then be discarded after the initial
> > > domain setup is complete.
> >
> > That might work. What do others around here think?
> >
> > Ian.
> 
> In deciding which approach to use, you should keep in mind that
> eventually it will be desirable to measure the VM (i.e. into a virtual
> TPM).  So if the data is going to be processed by code that is TPM-
> aware, then any approach to getting it the data should allow for
> measurement.  But if the processing code is not TPM-aware and is
> measured by the domain builder code, then the data should be provided in
> a way that the domain builder can easily measure it.
> 
> Joe

Joe, thanks for the feedback. From the other comments I have received, I 
believe I will use an approach where bits of virtual firmware like passed in 
SMBIOS tables (or other pieces I am working on like ACPI SSDTs that are passed 
in at runtime) will be loaded into the new guest as a set of modules. These 
modules will solely be for consumption by hvmloader. In light of this, I 
believe the latter of the two scenarios you mentioned will be the case; that a 
domain builder measures the initial building blocks like hvmloader any 
associated modules.

The area I am still considering though is dealing with platform firmware 
updates and how they would be reflected in a given set of hvmloader modules 
where obviously changing those modules would mean a different measurement. More 
broadly, I guess I don't know enough about how changes to platform firmware is 
handled with respect of platform measurements (and it seems to me the case of 
the guest and vTPMs is just an extension of this)?

Ross

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel