Re: [Xen-devel] Architecture for dom0 integrity measurements.

["Xu, Quan" <quan.xu@xxxxxxxxx>]

> -----Original Message-----
> From: Dr. Greg Wettstein [mailto:greg@xxxxxxxxxxxxxxxxx]
> Sent: Wednesday, January 14, 2015 10:25 AM
> To: Xu, Quan; greg@xxxxxxxxxxxx; xen-devel@xxxxxxxxxxxxx
> Cc: Daniel De Graaf; stefano.stabellini@xxxxxxxxxxxxx
> Subject: RE: [Xen-devel] Architecture for dom0 integrity measurements.
> 
> On Jan 12,  3:53pm, "Xu, Quan" wrote:
> } Subject: RE: [Xen-devel] Architecture for dom0 integrity measurements.
> 
> > Hi, Dr. G.W. Wettstein
> 
> Hi Quan, thanks for taking the time to reply.
> 
> > cc Graaf who is vTPM / XSM maintainer.
> > Also cc Stefano.
> 
> Greetings to everyone else as well.
> 
> > > -----Original Message-----
> > > From: xen-devel-bounces@xxxxxxxxxxxxx
> > > [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Dr. Greg
> > > Wettstein
> > > Sent: Saturday, January 10, 2015 10:59 PM
> > > To: xen-devel@xxxxxxxxxxxxx
> > > Subject: [Xen-devel] Architecture for dom0 integrity measurements.
> 
> > > Hi, I hope the weekend is going well for everyone.
> > >
> > > We have been watching the discussions on the list over the holiday
> > > on the refinement and enhancement of the TPM architecture for Xen,
> > > including support for TPM 2.0.  We are active in measured platform
> > > development and I wanted to pose what is perhaps a philosophical
> > > question to everyone.
> > >
> > > Our systems boot from a hardware root of trust via TXT and we
> > > heavily leverage the Linux Integrity Measurement Architecture
> > > (IMA) for mutual remote attestation.
> 
> > Is it based on TBoot / OpenAttestation ?
> 
> Yes, we leverage TBOOT to implement the root of trust for our security
> supervisor.
> 
> We have worked with OAT but our development efforts have been focused on
> something we refer to as POSSUM.  We are heavily invested in the concept of
> intrinsically linking identity to authentication and ephemeral key exchange
> through mutual device attestation.
> 

Interesting, thanks. 
Could you share some more information about POSSUM?

 
> > > Others may disagree but I wouldn't even contemplate delivering an
> > > integrity certified platform without including all of the dom0
> > > infrastructure into > the platform measurement status.  We heavily
> > > leverage the current 4.4.x vTPM implementation for testing and
> > > development and the documentation states clearly to not integrate
> > > TPM/TIS support into the dom0 OS.
> 
> > Ditto.
> 
> Everyone seems to agree on this point.
> 
> > > The obvious model is to run a software TPM simulator in dom0 and
> > > have the vTPM I/O domains link to that.  We are heavily invested in
> > > IBM's software TPM simulator and have been tossing around the idea
> > > of building up a proof of concept based on that.  I wanted to make
> > > sure we were not misunderstanding anything with the current or
> > > proposed architecture before we invest the resources.
> 
> > BM's software TPM simulator, is it libtpms?
> >
> > For all I know, the libtpms is a library that targets the integration
> > of TPM functionality into hypervisors.  In this mode, libtpms is
> > dynamic linking library, so there is no root of trust.
> > If you really want to enable it, I have some=20 Suggestion.
> 
> It is Ken Goldman's work at IBM and the library name is libtpm.  It is a 
> library of
> TPM functionality which is used to implement a TPM simulator/server.  Trousers
> talks to the server and for testing and development we have been able to move
> our codebase between it and hardware without modification.
> 
> > 1. vTPM I/O domains is now needed in this mode, QEMU can implement
> > another TPM Backend to link libtpms. Try to refer to
> > http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg00674.html=
> > 20
> >
> > 2. Enabling seabios for HVM virtual machine.
> > Refer to patch ' vTPM: add TPM TCPA and SSDT for HVM virtual machine'
> > And https://github.com/virt2x/seabios2=20
> 
> Thanks for the references, we are following up on .
> 
> >> We have also been considering whether or not to implement the
> >> multiple TPM states in the context of the dom0 hardware
> >> virtualization instance.
> 
> > Does it mean initial states from libtpms? Such as clear/save/.etc.
> > Correct me, if I am wrong..
> 
> I believe we are talking about the same conept/technology.  The library
> initializes its TPM 'state' but the state is not anchored in hardware.
> 
> >> Once again not as 'technically secure' but it does cut out a lot of
> >> complexity with the current model,
> 
> > Yes, agree with this point.
> 
> Yes, it doesn't take very much work on this technology to appreciate the
> reproducibility, flexibility and debuggability of a simulator.
> 
> It is not, as I noted above, capable of implementing a hardware root of trust 
> like a
> hardware TPM but the same rules apply to it as the vTPM/vtpmmgr architecture.
> If the simulator and its database is aanchored to a hardware root of trust it 
> should
> be possible to have its simulation services be trusted by a guest.
> 
> We've started work on going through the code and building up a prototype which
> is capable of running multiple TPM instances, each of which could be coupled 
> to a
> guest domain.  We will see where that leads us with respec to couping it via
> XEN's tpm front/back drivers to a guest.
> 
> > > with the added benefit of that infrastructure being covered by a
> > > hardware rooted IMA state.
> > >
> > > Also we are extremely interested in what hardware and motherboards
> > > with TPM 2.0 support are being used for this development, obviously
> > > with TXT being a requirement.  It wasn't too long ago we were
> > > advised directly by Intel that physical hardware was not available,
> > > perhaps that was a miscommunication.  Given the work being done, and
> > > the Intel e-mail addresses on the patches, > there is obviously
> > > access to 2.0 compliant hardware or is all this being done with
> > > simulators???
> 
> > NOT simulator, it is on TPM 2.0 hardware.  The attach file is the
> > output of ' dmidecode' on physical machine with TPM 2.0.  These 2
> > machine are from Huawei/Nationz. I can ask them for more information.
> 
> Interesting, I assume its based on an Intel chipset and vPRO capable with TXT
> support?  If so we would be interested in any information on availability of
> hardware for testing and development.


The following is from colleague:
"Anyway, in general, Intel Grantley server platforms can support TPM2/TXT. Most 
of OEMs from China can support Nationz TPM2 chip.
Intel Broadwell client NUC platforms will support TPM2/vPro/TXT features. BTW, 
the vPro is the client feature not server"

-Quan 

> 
> > Quan
> 
> Thanks again for the reflections.
> 
> Have a good week.
> 
> Greg
> 
> }-- End of excerpt from "Xu, Quan"
> 
> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.           Specializing in information infra-structure
> Fargo, ND  58102            development.
> PH: 701-281-1686
> FAX: 701-281-3949           EMAIL: greg@xxxxxxxxxxxx
> ------------------------------------------------------------------------------
> "You and Uncle Pete drank the whole thing?  That was a $250.00 bottle  of
> whisky.
> 
>  Yeah, it was good."
>                                 -- Rick
>                                    Resurrection.

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