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

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.

> > 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.

> 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


 


Rackspace

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