Following are notes I jotted down following the March 2, 2011 meeting between IBM and Red Hat that may be of general interest to the list.
Known Attendees:
Rajiv Andrade Stefan Berger Ken Goldman Steve Grubb Anthony Liguori Frank Novak Eric Paris Dimitrios Pendarakis Jack Rieden Dave Safford Lee Terrell Dan Walsh George Wilson Lee Wilson Chris Wright Kent Yoder Mimi Zohar
Meeting Summary:
- IBM has been open sourcing various Trusted Computing components over the last several years that are fairly uninteresting in an of themselves. - However, we have been doing so to to build out the ecosystem. - We have long had TPM device drivers in the kernel, TrouSerS, tpm-tools, and the PKCS#11 TPM token. - The big missing piece has been trusted boot, and due to that deficiency, TrouSerS has remained in Tech Preview status for quite some time. - Red Hat had stated several years ago that they were uninterested in an SRTM given the more scalable DRTM approach. - However, a DRTM bootloader that works with TXT was thwarted by the Fedora requirement not to carry or reference the 3rd party BLOB that is the sinit AC module. - During talks last year that included the System x organization, we were able to get System x to agree to put the ACM into flash much as is done for the BIOS. - That allowed us to make a statement, and for tboot to be contributed to Fedora. - Eric stated that he's having trouble getting tboot to come up on the boards he has tried. - Given we can get past the tboot issues, there will finally be a complete Trusted Computing stack that supports trusted boot on Intel TXT capable machines. - The support can be exploited by IMA in the kernel, and tpm-tools and the PKCS#11 TPM token in userspace. - Now it is time to turn our attention towards other issues: IMA appraisal, EVM, PTS, an attestation management server, and a CA. - It is possible that a PTS implementation will be open sourced by IBM Research in the near future. - That could be integrated with the TNC package to created an attested TNC in the TCG sense using freeRADIUS and wpa_supplicant. - Those pieces would provide a complete bare metal or KVM host ecosystem for the first time. - The other place that requires attention is the virtual space. - IBM Research open sourced it's gold standard software TPM, and Ken has ported it to freebl, the lower lower of NSS. - Ken is still seeing an issue and will contact Bob Relyea to help resolve, likely in a conference call. - There will need to be a new version of NSS with cleanups Ken requires. - It appears to be working fairly well and largely surviving torture tests. - Stefan has turned it into libtpms and libtpms-devel packages, which have undergone review. - The software TPM library work is preparatory to submitting patches to the Qemu community so that community members can "yum install libtpms libtpms-devel" and proceed with building the patches. - The patches are a large chunk of code somewhat akin to SPICE in terms of size and complexity. - However, they ware working for Stefan. - It is expected to take some time for them to undergo review but the approach appears viable. - We still need a way to do measured launches of guests. - The hope is to use the same tboot GRUB module for guests as we use for the host by emulating TXT instructions in Qemu. - A measured launch would complete the guest ecosystem. - Another piece of the puzzle to consider is EVM. - IMA appraisal makes little sense without EVM. - Eric will take a look at Mimi's patches.
Component Status Summary:
Substantially Complete: - tpm_tis - TrouSerS - tpm-tools - PKCS #11 TPM token
May Need Work: - tboot in the bare metal or host case
Potentially Open Sourced Soon: - OpenPTS from IBM Research
Work in Progress: - IBM's Software TPM port to freebl - Transformation of IBM's Software TPM into a vTPM library and devel package - Qemu integration of the vTPM
Work Not Yet Planned: - Qemu emulation of TXT - Virtual sinit AC module - Any virtual BIOS work required to support TXT - Other features upon which TXT emulation may be dependent - Attestation management - vTPM enrollment
Regards, George Wilson IBM Linux Technology Center Security Architect & Team Lead 512-286-9271
On Fri, 2011-03-11 at 10:31 -0600, George Wilson wrote:
- Red Hat had stated several years ago that they were uninterested in
an SRTM given the more scalable DRTM approach.
- However, a DRTM bootloader that works with TXT was thwarted by the
Fedora requirement not to carry or reference the 3rd party BLOB that is the sinit AC module.
- During talks last year that included the System x organization, we
were able to get System x to agree to put the ACM into flash much as is done for the BIOS.
- That allowed us to make a statement, and for tboot to be contributed
to Fedora.
- Eric stated that he's having trouble getting tboot to come up on the
boards he has tried.
- Given we can get past the tboot issues, there will finally be a
complete Trusted Computing stack that supports trusted boot on Intel TXT capable machines.
I'm glad to see progress on enabling the use of DRTM, and agree that it is preferable when it can be supported by the hardware. I'm not sure though that it is necessarily a good idea to exclude SRTM as an option for users, particularly when DRTM isn't fully supported on all hardware yet. What are the obstacles to enabling use of SRTM in Linux? TrustedGRUB has certainly existed for quite some time.
On Mon, 2011-03-21 at 16:45 -0400, Stephen Smalley wrote:
On Fri, 2011-03-11 at 10:31 -0600, George Wilson wrote:
- Red Hat had stated several years ago that they were uninterested in
an SRTM given the more scalable DRTM approach.
- However, a DRTM bootloader that works with TXT was thwarted by the
Fedora requirement not to carry or reference the 3rd party BLOB that is the sinit AC module.
- During talks last year that included the System x organization, we
were able to get System x to agree to put the ACM into flash much as is done for the BIOS.
- That allowed us to make a statement, and for tboot to be contributed
to Fedora.
- Eric stated that he's having trouble getting tboot to come up on the
boards he has tried.
- Given we can get past the tboot issues, there will finally be a
complete Trusted Computing stack that supports trusted boot on Intel TXT capable machines.
I'm glad to see progress on enabling the use of DRTM, and agree that it is preferable when it can be supported by the hardware. I'm not sure though that it is necessarily a good idea to exclude SRTM as an option for users, particularly when DRTM isn't fully supported on all hardware yet. What are the obstacles to enabling use of SRTM in Linux? TrustedGRUB has certainly existed for quite some time.
My understanding is that SRTM issues revolve around about 3 major problems. The first being that the upstream grub project, FSF and GNU have wholly rejected the idea of 'treacherous computing' and refuse to consider it's inclusion. Period. Full stop. The fact that trusted computing could potentially be used for positive activities does not appear to matter, especially since no realistic solutions which might broadly make trusted computing useful to the loan hacker seem close to light. Maybe if trusted computing use cases and solutions to problems were ever completed, coded, and made useful and manageable for the applicable "deciders" in that upstream community their support might change, but my understanding is that it doesn't seem likely.
When last I looked the second major issue was that trusted grub is not a patch. It's a tar ball without a clear base and without a reasonable ability to review. Red Hat did try to pick apart what was trusted grub, what was unrelated grub changes, and what was related to trusted grub and failed. It hasn't been ported to any recent grub. It's possible that if the trusted grub functionality were presented in a small succinct well documented patch or series of patches which makes its operation easy to implement and review that distros might agree to carry it even if upstream refused. Both I and Red Hat's grub maintainer have ask parties interested in trusted grub if this would be possible, but I have not heard of any potential progress. But the burden on the distro must be very very low because:
The third major issue is that the Red Hat grub maintainer doesn't have a lot of time and this isn't a high priority for him. He isn't going to try to tease out and reverse engineer the code from the trusted grub project and he isn't going to take on the responsibility for forward porting that functionality to new grub versions as time moves forward. That's just a blunt assessment of my understanding of the facts surrounding his workload and priorities.
The SRTM support is (hopefully) feasible mostly because interested parties (Intel) was and is willing to support and maintain the burden of dealing with the tboot package. Mind you I'm 0/6 on a working system using TXT but at least we think we might get there someday.
-Eric
On Mon, 2011-03-21 at 17:13 -0400, Eric Paris wrote:
When last I looked the second major issue was that trusted grub is not a patch. It's a tar ball without a clear base and without a reasonable ability to review. Red Hat did try to pick apart what was trusted grub, what was unrelated grub changes, and what was related to trusted grub and failed. It hasn't been ported to any recent grub. It's possible that if the trusted grub functionality were presented in a small succinct well documented patch or series of patches which makes its operation easy to implement and review that distros might agree to carry it even if upstream refused. Both I and Red Hat's grub maintainer have ask parties interested in trusted grub if this would be possible, but I have not heard of any potential progress. But the burden on the distro must be very very low because:
The third major issue is that the Red Hat grub maintainer doesn't have a lot of time and this isn't a high priority for him. He isn't going to try to tease out and reverse engineer the code from the trusted grub project and he isn't going to take on the responsibility for forward porting that functionality to new grub versions as time moves forward. That's just a blunt assessment of my understanding of the facts surrounding his workload and priorities.
Any chance you could just separately package TrustedGRUB as an optional package, much the same as you would package tboot? It is effectively a fork of grub, as you said, and they had to remove certain functionality (CHS code) to make everything fit, so I don't know if you can completely get rid of grub.
Or alternatively how does GRUB-IMA compare?
The SRTM support is (hopefully) feasible mostly because interested parties (Intel) was and is willing to support and maintain the burden of dealing with the tboot package. Mind you I'm 0/6 on a working system using TXT but at least we think we might get there someday.
Guessing you mean DRTM above. Have you reported the failures to tboot-devel?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/22/2011 07:44 AM, Stephen Smalley wrote:
On Mon, 2011-03-21 at 17:13 -0400, Eric Paris wrote:
When last I looked the second major issue was that trusted grub is not a patch. It's a tar ball without a clear base and without a reasonable ability to review. Red Hat did try to pick apart what was trusted grub, what was unrelated grub changes, and what was related to trusted grub and failed. It hasn't been ported to any recent grub. It's possible that if the trusted grub functionality were presented in a small succinct well documented patch or series of patches which makes its operation easy to implement and review that distros might agree to carry it even if upstream refused. Both I and Red Hat's grub maintainer have ask parties interested in trusted grub if this would be possible, but I have not heard of any potential progress. But the burden on the distro must be very very low because:
The third major issue is that the Red Hat grub maintainer doesn't have a lot of time and this isn't a high priority for him. He isn't going to try to tease out and reverse engineer the code from the trusted grub project and he isn't going to take on the responsibility for forward porting that functionality to new grub versions as time moves forward. That's just a blunt assessment of my understanding of the facts surrounding his workload and priorities.
Any chance you could just separately package TrustedGRUB as an optional package, much the same as you would package tboot? It is effectively a fork of grub, as you said, and they had to remove certain functionality (CHS code) to make everything fit, so I don't know if you can completely get rid of grub.
Or alternatively how does GRUB-IMA compare?
The SRTM support is (hopefully) feasible mostly because interested parties (Intel) was and is willing to support and maintain the burden of dealing with the tboot package. Mind you I'm 0/6 on a working system using TXT but at least we think we might get there someday.
Guessing you mean DRTM above. Have you reported the failures to tboot-devel?
Who would support that? Who is going to maintain it and make sure new features and security fixes get back ported into it?
On Tue, 2011-03-22 at 09:03 -0400, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/22/2011 07:44 AM, Stephen Smalley wrote:
On Mon, 2011-03-21 at 17:13 -0400, Eric Paris wrote:
When last I looked the second major issue was that trusted grub is not a patch. It's a tar ball without a clear base and without a reasonable ability to review. Red Hat did try to pick apart what was trusted grub, what was unrelated grub changes, and what was related to trusted grub and failed. It hasn't been ported to any recent grub. It's possible that if the trusted grub functionality were presented in a small succinct well documented patch or series of patches which makes its operation easy to implement and review that distros might agree to carry it even if upstream refused. Both I and Red Hat's grub maintainer have ask parties interested in trusted grub if this would be possible, but I have not heard of any potential progress. But the burden on the distro must be very very low because:
The third major issue is that the Red Hat grub maintainer doesn't have a lot of time and this isn't a high priority for him. He isn't going to try to tease out and reverse engineer the code from the trusted grub project and he isn't going to take on the responsibility for forward porting that functionality to new grub versions as time moves forward. That's just a blunt assessment of my understanding of the facts surrounding his workload and priorities.
Any chance you could just separately package TrustedGRUB as an optional package, much the same as you would package tboot? It is effectively a fork of grub, as you said, and they had to remove certain functionality (CHS code) to make everything fit, so I don't know if you can completely get rid of grub.
Or alternatively how does GRUB-IMA compare?
The SRTM support is (hopefully) feasible mostly because interested parties (Intel) was and is willing to support and maintain the burden of dealing with the tboot package. Mind you I'm 0/6 on a working system using TXT but at least we think we might get there someday.
Guessing you mean DRTM above. Have you reported the failures to tboot-devel?
Who would support that? Who is going to maintain it and make sure new features and security fixes get back ported into it?
TrustedGRUB is maintained by Sirrix AG. https://projects.sirrix.com/trac/trustedgrub/
Not much different than saying that GRUB is maintained by GNU, or that tboot is maintained by Intel. It just becomes yet another package that tracks its own separate upstream.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/22/2011 09:11 AM, Stephen Smalley wrote:
On Tue, 2011-03-22 at 09:03 -0400, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/22/2011 07:44 AM, Stephen Smalley wrote:
On Mon, 2011-03-21 at 17:13 -0400, Eric Paris wrote:
When last I looked the second major issue was that trusted grub is not a patch. It's a tar ball without a clear base and without a reasonable ability to review. Red Hat did try to pick apart what was trusted grub, what was unrelated grub changes, and what was related to trusted grub and failed. It hasn't been ported to any recent grub. It's possible that if the trusted grub functionality were presented in a small succinct well documented patch or series of patches which makes its operation easy to implement and review that distros might agree to carry it even if upstream refused. Both I and Red Hat's grub maintainer have ask parties interested in trusted grub if this would be possible, but I have not heard of any potential progress. But the burden on the distro must be very very low because:
The third major issue is that the Red Hat grub maintainer doesn't have a lot of time and this isn't a high priority for him. He isn't going to try to tease out and reverse engineer the code from the trusted grub project and he isn't going to take on the responsibility for forward porting that functionality to new grub versions as time moves forward. That's just a blunt assessment of my understanding of the facts surrounding his workload and priorities.
Any chance you could just separately package TrustedGRUB as an optional package, much the same as you would package tboot? It is effectively a fork of grub, as you said, and they had to remove certain functionality (CHS code) to make everything fit, so I don't know if you can completely get rid of grub.
Or alternatively how does GRUB-IMA compare?
The SRTM support is (hopefully) feasible mostly because interested parties (Intel) was and is willing to support and maintain the burden of dealing with the tboot package. Mind you I'm 0/6 on a working system using TXT but at least we think we might get there someday.
Guessing you mean DRTM above. Have you reported the failures to tboot-devel?
Who would support that? Who is going to maintain it and make sure new features and security fixes get back ported into it?
TrustedGRUB is maintained by Sirrix AG. https://projects.sirrix.com/trac/trustedgrub/
Not much different than saying that GRUB is maintained by GNU, or that tboot is maintained by Intel. It just becomes yet another package that tracks its own separate upstream.
Well until it gets into RHEL and we have to maintain it for 10 years. In order to add a new package we have to justify the support cost.
On Tue, 2011-03-22 at 07:44 -0400, Stephen Smalley wrote:
On Mon, 2011-03-21 at 17:13 -0400, Eric Paris wrote:
The SRTM support is (hopefully) feasible mostly because interested parties (Intel) was and is willing to support and maintain the burden of dealing with the tboot package. Mind you I'm 0/6 on a working system using TXT but at least we think we might get there someday.
Guessing you mean DRTM above. Have you reported the failures to tboot-devel?
Yes, I meant DRTM/TXT. I reported the failures to the Fedora tboot maintainer. He actually supplied a patch which might have fixed it on 3 of the 6 platforms, but I only had access to those platforms for a couple hours and didn't have the ability to test the kernel patch.
-Eric
On Fri, 2011-03-11 at 10:31 -0600, George Wilson wrote:
- Now it is time to turn our attention towards other issues: IMA
appraisal, EVM, PTS, an attestation management server, and a CA.
- It is possible that a PTS implementation will be open sourced by IBM
Research in the near future.
- That could be integrated with the TNC package to created an attested
TNC in the TCG sense using freeRADIUS and wpa_supplicant.
- Those pieces would provide a complete bare metal or KVM host
ecosystem for the first time.
This sounds interesting. The lack of even basic tool support for creating AIKs and generating TPM quotes has been a hindrance to leveraging a key part of the TPM functionality. You may already be aware, but a set of tools for this purpose has recently been open sourced, tpm-quote-tools [1]. They have been submitted for possible inclusion as part of the trousers open source project [2] but seemingly without any movement there, and separately as a Fedora package [3].
[1] http://www.ccs.neu.edu/home/ramsdell/tools/ [2] http://sourceforge.net/tracker/?func=detail&atid=704361&aid=3161939&... [3] https://bugzilla.redhat.com/show_bug.cgi?id=683127
It would have been more accurate for me to state that OpenPTS is an important component in a developing a complete infrastructure. We will still need an enrollment workflow. I hadn't seen the Ramsdell TPM tools. Thanks much for the reference. I'll discuss with Rajiv Andrade whether it would be appropriate to adopt them into TrouSerS.
Seiji Munetoh of IBM Research recently open sourced OpenPTS v0.2.3: http://sourceforge.jp/projects/openpts/
Regards, George Wilson IBM Linux Technology Center Security Architect & Team Lead 512-286-9271
Stephen Smalley sds@tycho.nsa.gov wrote on 03/21/2011 03:53:44 PM:
On Fri, 2011-03-11 at 10:31 -0600, George Wilson wrote:
- Now it is time to turn our attention towards other issues: IMA
appraisal, EVM, PTS, an attestation management server, and a CA.
- It is possible that a PTS implementation will be open sourced by IBM
Research in the near future.
- That could be integrated with the TNC package to created an attested
TNC in the TCG sense using freeRADIUS and wpa_supplicant.
- Those pieces would provide a complete bare metal or KVM host
ecosystem for the first time.
This sounds interesting. The lack of even basic tool support for creating AIKs and generating TPM quotes has been a hindrance to leveraging a key part of the TPM functionality. You may already be aware, but a set of tools for this purpose has recently been open sourced, tpm-quote-tools [1]. They have been submitted for possible inclusion as part of the trousers open source project [2] but seemingly without any movement there, and separately as a Fedora package [3].
[1] http://www.ccs.neu.edu/home/ramsdell/tools/ [2] http://sourceforge.net/tracker/? func=detail&atid=704361&aid=3161939&group_id=126012 [3] https://bugzilla.redhat.com/show_bug.cgi?id=683127
-- Stephen Smalley National Security Agency
On Fri, 2011-03-11 at 10:31 -0600, George Wilson wrote:
Work in Progress:
- Transformation of IBM's Software TPM into a vTPM library and devel
package
- Qemu integration of the vTPM
Work Not Yet Planned:
- Qemu emulation of TXT
- Virtual sinit AC module
- Any virtual BIOS work required to support TXT
- Other features upon which TXT emulation may be dependent
- Attestation management
- vTPM enrollment
I don't know if you follow it anymore, but there has been quite a bit of recent work in vTPM support for Xen that may be applicable, see: http://marc.info/?l=xen-devel&m=129988248524500&w=2
Thanks, Steve. I hadn't seen that recent work and agree that we can learn a great deal from the Xen vTPM. Stefan Berger is definitely bringing Xen Trusted Computing experience to his QEMU vTPM integration work.
Regards, George Wilson IBM Linux Technology Center Security Architect & Team Lead 512-286-9271
Stephen Smalley sds@tycho.nsa.gov wrote on 03/21/2011 03:59:28 PM:
On Fri, 2011-03-11 at 10:31 -0600, George Wilson wrote:
Work in Progress:
- Transformation of IBM's Software TPM into a vTPM library and devel
package
- Qemu integration of the vTPM
Work Not Yet Planned:
- Qemu emulation of TXT
- Virtual sinit AC module
- Any virtual BIOS work required to support TXT
- Other features upon which TXT emulation may be dependent
- Attestation management
- vTPM enrollment
I don't know if you follow it anymore, but there has been quite a bit of recent work in vTPM support for Xen that may be applicable, see: http://marc.info/?l=xen-devel&m=129988248524500&w=2
-- Stephen Smalley National Security Agency
trusted-computing@lists.fedorahosted.org
-
Daniel J Walsh -
Eric Paris -
George Wilson -
Stephen Smalley