List view

• next (3.0.1)

  - Fixed: - Reduce permissions in SELinux policy by using init_nnp_daemon_domain over init_daemon_domain

  No due date

  •1/3 issues closed
  33% complete2 open1 closed

• command filtering

  Filtering TPM commands is another use case we had in mind when designing the command / response processing pipeline.

  No due date

  •0/2 issues closed
  0% complete2 open0 closed

• Use TSS2 2.0 features

  The tabrmd pre-dates the TSS2 2.0 release. This release added useful APIs / libraries that would have been useful. Generally the functionality required was reimplemented in the tabrmd directly and should be removed in favor of the upstream implementation.

  No due date

  •1/3 issues closed
  33% complete2 open1 closed

• TCTI command passing

  The tabrmd currently handles the TCTI transmit / receive commands as expected. The 'cancel' and 'setLocality' commands however are not. This milestone includes all issues related to implementing *all* TCTI command where appropriate.

  No due date

  •0/2 issues closed
  0% complete2 open0 closed

• flight recorder

  I've been in a few situations where having a "flight recorder" mode for the tpm2-abrmd would be helpful. By "flight recorder" I mean a mechanism to record, in chronological order, the command buffers sent to the tpm, and the response buffers received back. These should be recorded on disk, in files (maybe a single file, maybe one file for each command / response buffer with a timestamp in the name). A first step may be storing just the raw buffer but this leaves a lot to be desired as far as readability goes (we don't have any tools to "pretty print" these buffers). Using something like libpcap might be the right thing to do here if we can pair this with a wireshark plugin or something of the sort to do the pretty printing for us. For the implementation to be complete it will be necessary to record command / response buffers from clients as well as from the commands executed by the tabrmd itself. This is more work than capturing just client commands / responses but it's necessary to get a full picture of what's going on.

  No due date

  •0/3 issues closed
  0% complete3 open0 closed

• IPC generalization

  The current IPC (dbus) mechanism used by the tabrmd for communication with clients is tightly integrated into the $(srcdir)/src/tabrmd.c (aka "main") module. This works but it's horribly inflexible. This 'milestone' covers the generalization of the IPC backend (or is it a frontend?) into a set of GObjects such that the details of the IPC mechanism are hidden from the main daemon. This should look a lot like the way we currently instantiate TCTI modules using the abstract Tcti class in $(srcdir)/src/tcti.c

  No due date

  •4/9 issues closed
  44% complete5 open4 closed