Some output from the tpm2-get-cap-fixed.efi example application produces weird output. This is most likely caused by the TPM2 returning chars while all of UEFI uses wchars. Probably something we can convert using mbstowcs.

Not sure how to run the efi applications. I'm sure I'm missing something here.

UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDK II, 0x00010000)
Mapping table
      FS0: Alias(s):HD1a1:;BLK3:
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)
     BLK2: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
     BLK4: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
     BLK0: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
     BLK1: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
Press ESC in 5 seconds to skip startup.nsh or any other key to continue.
Shell> fs0:
FS0:\> ls
Directory of: FS0:\
12/13/2018  11:43                 207  compat.h
12/13/2018  11:43              49,909  get-capability.efi
12/13/2018  11:43           2,856,248  tpm2-get-capability.so
12/13/2018  10:43              32,768  get-capability.o
12/13/2018  10:27              10,959  tpm2-get-capability.c
12/13/2018  10:27                 545  tss2-util.h
12/13/2018  11:43             273,292  tpm2-get-capability.efi
12/13/2018  10:27               1,227  get-capability.c
12/13/2018  11:43              55,608  tpm2-get-capability.o
12/13/2018  10:27                 408  compat.c
12/13/2018  11:43 <DIR>         8,192  .deps
12/13/2018  10:43              36,688  tss2-util.o
12/13/2018  09:26               3,075  tss2-util.c
12/13/2018  19:43               1,958  NvVars
12/13/2018  11:43           2,213,168  get-capability.so
12/13/2018  10:43              27,896  compat.o
         15 File(s)   5,563,956 bytes
          1 Dir(s)
FS0:\> tpm2-get-capability.efi
LibLocateProtocol status: 0xE
FS0:\> get-capability
LibLocateProtocol status: 0xE
FS0:\> load get-capability.efi
Image 'FS0:\get-capability.efi' is not a driver.
FS0:\>

This was a typo: 'digest' should be 'Digest'.

Figure out how to integrate this library (and the required tss2 ones) into edk2. Edk2 is not particularly friendly to integrating external libraries. The assumption of static linking seems to have caused a similar assumption about all code being "in-tree". We should probably look to the OpenSSL integration as a reference.

Running the example UEFI applications under Qemu with OVMF is super handy (see #21) . The remaining tasks to turn this approach into a proper integration test harness should be considered / discussed here.

Has anyone ported this project into aarch64 platform?

We get this data from the TCG2 protocol driver GetActivePcrBanks function. Display the data in a "human readable" format.

#48 added a tool to dump the event log but it only supports the SHA1-only format. The OVMF firmware supports the newer format (I think), and the spec for the format is in the TCG EFI Protocol Specification in section 5.2. Just need to write the code.

I wrote something similar as a grub shell command a long time ago. Use this as a starting point: https://github.com/flihp/meta-measured/blob/morty/recipes-bsp/grub/files/0002-tpm2cmd-Add-new-commands-for-basic-interaction-with-.patch

forgot to do one of these

we exit the efi shell correctly now, no need for timeout

The build process for UEFI applications, or at least the process I've used for this project, is a bit convoluted. This was based on the build process described here: http://www.rodsbooks.com/linux-uefi/. Having to use objdump to transform the shared object to the EFI executable using this method works but ideally we'd be able to use the target triple. I don't know "the right way" to do this though. There's probably a good example out there I just haven't found it. The build system for Grub2 may be a good reference.

Upstream changes in swtpm build seem to be causing CI failures. Previously if libseccomp wasn't installed the build would disable the code that required it. Doesn't seem to be the case any longer though.

Just had a look at the code and noticed that this should probably be the binary & instead of the boolean &&:

The integration test script needs to grow up a bit. The most useful output from the test cases ends up in a log file under /tmp. This is a lot harder to find than it needs to be. Try to get this into the default .log file for the test. If that's a PITA a new log file under $(srcdir)/test named appropriately is a close second.