Re: [Xen-devel] Architecture for dom0 integrity measurements.
On Jan 12, 5:25pm, Daniel De Graaf wrote: } Subject: Re: [Xen-devel] Architecture for dom0 integrity measurements. Hi Daniel, thanks for taking time to respond. Hope your week is going well. > >> -Original Message- > >> From: xen-devel-boun...@lists.xen.org > >> [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Dr. Greg Wettstein > >> Sent: Saturday, January 10, 2015 10:59 PM > >> To: xen-devel@lists.xen.org > >> 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. > > Ideally, domain 0 would use its own vTPM to record IMA measurements. > However, it is not currently possible to use IMA with a vTPM that is > started after the domain 0 kernel has booted. In addition, the > current vTPM emulator requires working disk I/O and a working vTPM > Manager domain before it will accept commands. For those reading along at home, a quick summary of the current TPM virtualization architecture, Daniel correct me if I'm wrong. There can be only one physical projection of the TPM hardware resources by the hypervisor. This is done to a management process (vtpmmgr) which is an application running in a small isolated OS instance (mini-os). This process is responsible for issueing the ordinals (commands) to the physical TPM which are needed to use the security/trust guarantees provided by that hardware. Separate isolated OS instances are created for each 'virtual TPM'. These OS instances run TPM simulation software (Berlios) whose functionality is presented to standard OS guests (Linux/Windows) through a hypervisor mediated shared memory interface. For Linux integrity management to work the kernel needs to have access from the moment it starts to a TPM in order to add the measurements of any resources it accesses, which are determined to being security sensitive by the security policy, to the TPM. So we are in a 'Catch-22'. The dom0 kernel is responsible for starting the virtual TPM infrastructure but needs access to a TPM if its own security status is to be measured. Since properly starting the virtual TPM infrastructure is a security critical operation the virtual TPM's presented to the guests are technically insecure unless the integrity of dom0 is measured/monitored. In a standard Xen implementation dom0 is usually a regular Linux distribution which is a pretty big piece of software to leave unmeasured, or to even measure as far as that goes. The challenge is how to address this 'Catch-22'. > Architecture 1: > > Domain 0 boots with access to the physical TPM (via tpm_tis) and > uses it to store IMA measurements. During boot, the vTPM Manager > domain and a vTPM for domain 0 are started. Since the vTPM Manager > currently uses locality 2 while Linux uses locality 0, concurrent > access is possible without needing a cross-domain lock. The TPM > driver in both minios and Linux will wait long enough for a short > command (such as a PCR extend) to complete when submitting their > commands. > > Once the vTPM has been started, the physical TPM can be > hot-unplugged from domain 0, causing future TPM commands to be > directed to the vTPM. The vTPM for domain 0 should be configured to > mirror hardware PCRs on startup so that the early IMA measurements > are reflected in the vTPM. > > One problem with this: the process of switching from physical to > virtual TPM needs to happen during a quiescent period for IMA > measurements. This will result in the vTPM's PCR10 containing the > full IMA log and the pTPM's PCR10 containing an earlier, truncated > version. If IMA events happen during the switch, there will be some > mea
Re: [Xen-devel] Architecture for dom0 integrity measurements.
> -Original Message- > From: Dr. Greg Wettstein [mailto:g...@wind.enjellic.com] > Sent: Wednesday, January 14, 2015 10:25 AM > To: Xu, Quan; g...@enjellic.com; xen-devel@lists.xen.org > Cc: Daniel De Graaf; stefano.stabell...@eu.citrix.com > 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-boun...@lists.xen.org > > > [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Dr. Greg > > > Wettstein > > > Sent: Saturday, January 10, 2015 10:59 PM > > > To: xen-devel@lists.xen.org > > > 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. >
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-boun...@lists.xen.org > > [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Dr. Greg Wettstein > > Sent: Saturday, January 10, 2015 10:59 PM > > To: xen-devel@lists.xen.org > > 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
Re: [Xen-devel] Architecture for dom0 integrity measurements.
On 01/12/2015 10:53 AM, Xu, Quan wrote: Hi, Dr. G.W. Wettstein cc Graaf who is vTPM / XSM maintainer. Also cc Stefano. -Original Message- From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Dr. Greg Wettstein Sent: Saturday, January 10, 2015 10:59 PM To: xen-devel@lists.xen.org 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. Ideally, domain 0 would use its own vTPM to record IMA measurements. However, it is not currently possible to use IMA with a vTPM that is started after the domain 0 kernel has booted. In addition, the current vTPM emulator requires working disk I/O and a working vTPM Manager domain before it will accept commands. Architecture 1: Domain 0 boots with access to the physical TPM (via tpm_tis) and uses it to store IMA measurements. During boot, the vTPM Manager domain and a vTPM for domain 0 are started. Since the vTPM Manager currently uses locality 2 while Linux uses locality 0, concurrent access is possible without needing a cross-domain lock. The TPM driver in both minios and Linux will wait long enough for a short command (such as a PCR extend) to complete when submitting their commands. Once the vTPM has been started, the physical TPM can be hot-unplugged from domain 0, causing future TPM commands to be directed to the vTPM. The vTPM for domain 0 should be configured to mirror hardware PCRs on startup so that the early IMA measurements are reflected in the vTPM. One problem with this: the process of switching from physical to virtual TPM needs to happen during a quiescent period for IMA measurements. This will result in the vTPM's PCR10 containing the full IMA log and the pTPM's PCR10 containing an earlier, truncated version. If IMA events happen during the switch, there will be some measurements only present in the hardware TPM with the remaining only be present in the vTPM. While it is possible to reconstruct the values of each PCR during verification, this is more complex and should be avoided if possible. In either case, a verifier should check both physical and virtual TPM's PCR10 values for validity against the dom0 IMA log. Architecture 2: A more disaggregated system can use a domain 0 that uses no permanent state: its root filesystem would be a ramdisk optionally supplemented with a dm-verity disk image. This type of domain does not need to use IMA, and so can avoid any TPM access until both the vTPM Manager and vTPMs are created. Normal domain 0 functions would actually be performed by a toolstack domain distinct from domain 0. This is the architecture that I have primarily used in testing. Architecture 3 (requires changes to the vTPM domain): A domain builder (stub domain) creates an initial set of domains including Xenstore, vTPM Manager, hardware domain, and a vTPM for the hardware domain. The vTPM must be capable of performing PCR extend operations and other commands prior to being able to access its disk image, which will be attached (xl block-attach) during the hardware domain's boot process. Boot event order here: 1. Xen startup (pre-dom0) 2. Domain builder starts as dom0 3. Creation of xenstore, vtpmmgr, vtpm-hwdom, hwdom 4. Wire up vTPM connection for hwdom in Xenstore 5. Unpause vtpm-hwdom and hwdom 6. Hardware domain boots, uses vtpm-hwdom for IMA logging 7. Disk images for vtpmmgr and vtpm-hwdom attached 8. Unpause vtpmmgr domain 9. Start trousers and/or use kernel trusted-keys operations 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. Right, measuring domain 0 is important in getting useful assurance from a platform. Using other TPM functionality within domain 0 may also be useful, which is why I think making a vTPM available to do
Re: [Xen-devel] Architecture for dom0 integrity measurements.
Hi, Dr. G.W. Wettstein cc Graaf who is vTPM / XSM maintainer. Also cc Stefano. > -Original Message- > From: xen-devel-boun...@lists.xen.org > [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Dr. Greg Wettstein > Sent: Saturday, January 10, 2015 10:59 PM > To: xen-devel@lists.xen.org > 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 58102development. > PH: 701-281-1686 > FAX: 701-281-3949 EMAIL: g...@enjellic.com > -- > "Against stupidity the Gods themselves contend in vain." > -- Freidrich von Schiller > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel tpm2_machine.dmidecode Description: tpm2_machine.dmidecode ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[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. 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. 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. 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. We have also been considering whether or not to implement the multiple TPM states in the context of the dom0 hardware virtualization instance. Once again not as 'technically secure' but it does cut out a lot of complexity with the current model, 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??? 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 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -- "Against stupidity the Gods themselves contend in vain." -- Freidrich von Schiller ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
