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

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

Hi, Dr. G.W. Wettstein

cc Graaf who is vTPM / XSM maintainer.
Also cc Stefano. 

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

>I understand the motivation for running the TPM hardware
> manager in an IO emulation domain but unless I miss something in the current
> discussions, this architecture precludes the ability of the dom0 kernel to
> physically access the TPM which in turn prevents
> dom0 from implementing a hardware referenced measurement state via IMA.
> 

Graaf can answer it.

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

> 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.
> 
IBM'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 
Suggestion. 

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 

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 

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

>Once
> again not as 'technically secure' but it does cut out a lot of complexity 
> with the
> current model,

Yes, agree with this point.

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

Quan

> 
> Thanks for any reflections the group may have.
> 
> Best wishes for a productive week.
> 
> Greg
> 
> 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
> ------------------------------------------------------------------------------
> "Against stupidity the Gods themselves contend in vain."
>                                 -- Freidrich von Schiller
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

Attachment: tpm2_machine.dmidecode
Description: tpm2_machine.dmidecode

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