Skip to content
TPM2 Access Broker & Resource Management Daemon implementing the TCG spec.
C Makefile Shell M4 C++
Branch: master
Clone or download
williamcroberts and flihp ci: add --disable-defaultflags for codecov build
With optimizations enabled, codecov cannot gather the
data it needs. So turn off "default" flags.

Signed-off-by: William Roberts <william.c.roberts@intel.com>
Latest commit ac2a5a4 Aug 29, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
coverity Fix bad SPDX-License-Identifier. May 17, 2019
dist build: Remove unnecessary pthread lib from TCTI dependencies. Jul 2, 2019
doc Fix Spelling Errors Apr 5, 2018
m4 build: improve detection of stack protector support Dec 6, 2018
man tcti-dynamic: Make the tss2 device TCTI library SONAME the default Jul 10, 2018
scripts Fix bad SPDX-License-Identifier. May 17, 2019
selinux [SELinux] Remove gen_require part from tpm-abrmd2 policy. Feb 2, 2018
src util: fix command size range check Sep 2, 2019
test tcti: Use libtss2-tctildr instead of our custom TCTI loading code. Aug 20, 2019
.codecov.yml ci: switch from coveralls to codecov Apr 25, 2019
.gitignore build: Ignore m4 file imported by autoconf *_EXTENSIONS Jun 7, 2019
.lgtm.yml
.travis.yml ci: add --disable-defaultflags for codecov build Sep 5, 2019
CHANGELOG.md
CONTRIBUTING.md
INSTALL.md docs: Update references to required libraries from tpm2-tss. Jul 3, 2019
LICENSE Add BSD 2-clause license in LICENSE file. Prepend to sources. Apr 11, 2017
Makefile.am tcti: Use libtss2-tctildr instead of our custom TCTI loading code. Aug 20, 2019
README.md ci: add LGTM Aug 20, 2019
RELEASE.md Fix Spelling Errors Apr 5, 2018
bootstrap Fix bad SPDX-License-Identifier. May 17, 2019
configure.ac

README.md

Build Status Coverity Scan codecov Language grade: C/C++

TPM2 Access Broker & Resource Manager

This is a system daemon implementing the TPM2 access broker (TAB) & Resource Manager (RM) spec from the TCG. The daemon (tpm2-abrmd) is implemented using Glib and the GObject system. In this documentation and in the code we use tpm2-abrmd and tabrmd interchangeably.

Build & Install

Instructions to build and install this software are available in the INSTALL.md file.

tpm2-abrmd

tpm2-abrmd is a daemon. It should be started as part of the OS boot process. Communication between the daemon and clients using the TPM is done with a combination of DBus and Unix pipes. DBus is used for discovery, session management and the 'cancel', 'setLocality', and 'getPollHandles' API calls (mostly these aren't yet implemented). Pipes are used to send and receive TPM commands and responses (respectively) between client and server.

The daemon owns the com.intel.tss2.Tabrmd name on dbus. It can be configured to connect to either the system or the session bus. Configuring name selection would be a handy feature but that's future work.

Check out the man page TPM2-ABRMD(8) for the currently supported options.

libtcti-tabrmd

This repository also hosts a client library for interacting with this daemon. It is intended for use with the SAPI library (libtss2-sapi) like any other TCTI. The initialization function for this library is hard coded to connect to the tabrmd on the system bus as this is the most common configuration.

Check out the man page TSS2-TCTI-TABRMD(7) and TSS2_TCTI_TABRMD_INIT(3).

tpm2-abrmd vs in-kernel RM

The current implementations are mostly equivalent with a few differences. Both provide isolation between objects & sessions created by different connections which is the core functionality required by applications. The reason we have both is that the in-kernel RM was only added very recently (4.12) and we have TPM2 users in environments with kernels going back to the 3.x series. So the user space RM will be around at least till everyone is using the kernel RM.

For the short term we're recommending that developers stick to using the tabrmd as the default to get the most stable / widest possible support. If you structure your code properly you'll be able to switch in / out TCTI modules with relative ease and migrating to the in-kernel RM should be pretty painless. Eventually, all of the required features will end up in the kernel RM and it will become the default.

How we get to the ideal future of a single RM in the kernel: our current plan is to prototype various features in user space as a way to get them tested / validated. There's a lot of stuff in the related TCG spec that we haven't yet implemented and we all agree that it's generally a bad ideal to to put features into the kernel before we:

  1. understand how they work
  2. how they're going to be used by applications
  3. agree we want the feature at all

A good example of this are the asynchronous portions of the SAPI. Right now with the kernel RM you can use the async API but it won't really be asynchronous: Calls to functions that should be async will block since the kernel doesn't supply user space with an async / polling I/O interface. For the short term, if you want to use the SAPI in an event driven I/O framework you will only get async I/O from the user space resource manager. In the long run though, if this feature is important to our users, we can work to upstream support to the in-kernel RM. The plan is to treat future features in the same way.

This was the subject of a talk that was given @ the Linux Plumbers Conference 2017: http://linuxplumbersconf.com/2017/ocw//system/presentations/4818/original/TPM2-kernel-evnet-app_tricca-sakkinen.pdf

Related Specifications

You can’t perform that action at this time.