|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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-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. 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 domain 0 is a good solution. The recommendation in the documents is really about access to the physical TPM, which interferes with the vtpmmgr domain. 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 Using libtpms does not prevent having a root of trust, but it does greatly increase the size of the required trusted computing base to include all the software with sufficient privilege in domain 0 (and relevant configurations). This can be measured by a properly configured IMA policy, although it is more difficult to perform local attestation with IMA (the exact ordering of IMA records is often not deterministic, meaning you cannot reasonably seal secrets to a state that includes the IMA PCR). One of the features of Xen's vTPM architecture is that it is possible to have a domU that trusts as little of domain 0 as possible. With a domain builder to bootstrap the domU into a trusted state, this does not need to include any management software or even the hardware domain's kernel. However, this level of independence is not useful to most guests because it requires that a guest perform its own disk/network encryption, which conflicts with useful features such as cloning a guest. Migration also becomes more complex (requiring a separate migration domain). - Daniel 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 -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |