[RFC] Compare the current TPM events with the predicted events

[lcp]

When investigating the TPM unsealing failure, it'd be easier to identify the issue by comparing the predicted event log and the current event log. With '--create-testcase', the system status is snapshotted and '--replay-testcase' can reconstruct the events to be predicted.

This commit adds a new option, --compare-current, to compare the current TPM event log with the predicted events. It goes through the specified PCR indices in both current event log and the predicted events to identify the first different event.

The sample output:

# ./pcr-oracle --from eventlog --replay-testcase pcr-oracle.test \
        --compare-current --stop-event "grub-file=grub.cfg" --after \
        predict 0,2,4,7,9
Predicted event:
04168: event type=EFI_BOOT_SERVICES_APPLICATION pcr=4 digests=4 data=86 bytes
Boot Service Application; device path:
  file-path  "/EFI/opensuse/grub.efi"
  end
  sha256     086787b1bc5731794be3a117e568ddae4e6c7a587628daf406a00c8d540f5a3f
  Data:
        0000  18 a0 8e 7d 00 00 00 00 50 56 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 36 00 00 00 00 00 00 00 ...}....PV..............6.......
        0020  04 04 32 00 5c 00 45 00 46 00 49 00 5c 00 6f 00 70 00 65 00 6e 00 73 00 75 00 73 00 65 00 5c 00 ..2.\.E.F.I.\.o.p.e.n.s.u.s.e.\.
        0040  67 00 72 00 75 00 62 00 2e 00 65 00 66 00 69 00 00 00 7f ff 04 00                               g.r.u.b...e.f.i.......
Actual event:
0486c: event type=EFI_BOOT_SERVICES_APPLICATION pcr=4 digests=4 data=86 bytes
  sha1       7251f041609f1b1b2e25236be94e4cfde2f16cd9
  sha256     a7e3ac45de9877c56ec30b3fa07a76bddb31905aff3f19af6bafbd196079f08c
  sha384     1f6ffd64830fe9eccaf86ce8211f1f88c8aa3814283eb50ceaf11d50e593b0558fde036c5fd3065e9e91f7a770af8550
  sha512     82579ebe47a13da1f054551889402a1b3cca426e980e270a8a6c5e406f093767408baa4d3dadb85bf825d81cb6581ba5309a363636d16b768fd5d4d445752d36
  Data:
        0000  18 a0 8d 7d 00 00 00 00 70 57 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 36 00 00 00 00 00 00 00 ...}....pW..............6.......
        0020  04 04 32 00 5c 00 45 00 46 00 49 00 5c 00 6f 00 70 00 65 00 6e 00 73 00 75 00 73 00 65 00 5c 00 ..2.\.E.F.I.\.o.p.e.n.s.u.s.e.\.
        0040  67 00 72 00 75 00 62 00 2e 00 65 00 66 00 69 00 00 00 7f ff 04 00                               g.r.u.b...e.f.i.......

Predicted event:
002ab: event type=EFI_VARIABLE_DRIVER_CONFIG pcr=7 digests=4 data=53 bytes
  --> EFI variable SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c: 1 bytes of data
  sha256     115aa827dbccfb44d216ad9ecfda56bdea620b860a94bed5b7a27bba1c4d02d8
  Data:
        0000  61 df e4 8b ca 93 d2 11 aa 0d 00 e0 98 03 2b 8c 0a 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 a.............+.................
        0020  53 00 65 00 63 00 75 00 72 00 65 00 42 00 6f 00 6f 00 74 00 00                                  S.e.c.u.r.e.B.o.o.t..
Actual event:
002ab: event type=EFI_VARIABLE_DRIVER_CONFIG pcr=7 digests=4 data=53 bytes
  sha1       d4fdd1f14d4041494deb8fc990c45343d2277d08
  sha256     ccfc4bb32888a345bc8aeadaba552b627d99348c767681ab3141f5b01e40a40e
  sha384     2cded0c6f453d4c6f59c5e14ec61abc6b018314540a2367cba326a52aa2b315ccc08ce68a816ce09c6ef2ac7e514ae1f
  sha512     94a377e9002be6e1d8399bf7674d9eb4e931df34f48709fddd5e1493bfb96c19ee695387109a5a5b42f4871cbee8e32a9f3282636e99a8890762ee45bd7b34b7
  Data:
        0000  61 df e4 8b ca 93 d2 11 aa 0d 00 e0 98 03 2b 8c 0a 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 a.............+.................
        0020  53 00 65 00 63 00 75 00 72 00 65 00 42 00 6f 00 6f 00 74 00 01                                  S.e.c.u.r.e.B.o.o.t..

By comparing the predicted events and the actual events, it shows that there are unexpected events in PCR 4 and PCR 7. Both the predicted and actual PCR 4 events pointer to the same EFI application, grub.efi, but with different digests, so the change of grub.efi is detected. As for PCR 7 events, the difference in the 'Data' section indicates that the Secure Boot was enabled later.

[aplanas]

This week I spend a lot of time debugging an issue when the EFI binary measured is the one pointed in the event log, instead of a new one that is stored in a different place (new kernel).

I realized that the best tool to diagnose the issue is to collect the PCR extended in order that calculate the policy hash (https://github.com/okirch/pcr-oracle/pull/47).

In my PR this is a matter of adding one single debug output, but this required to be collected later from the debug output.