Fdectl tpm-present fails with "pcr-oracle... Excess argument(s)"

Hello!

I have tried to check if my system has the proper TPM2 support to try out the “Unattended boot with TPM2”.

The fdectl tpm-present command fails somewhere in the middle, pcr-oracle complaining about Excess argument(s).

I saw just a couple of topics that mention this issue, so I thought I will open a separate one, perhaps it helps gather information for a bug report for who can do that.
It looks like pcr-oracle is executed with invalid arguments at some point.

Versions used:

fde-tools 0.7.2-5.2
pcr-oracle 0.5.4-6.2

Here is the full output:

sudo fdectl tpm-present 
[sudo] password for root: 
TPM self test succeeded.
Testing TPM seal/unseal
Sealing secret - this may take a moment
Sealed secret written to /dev/shm/fde.hrptGE/sealed_secret
Excess argument(s)
Usage:
pcr-oracle [options] pcr-index [updates...]

The following options are recognized:
  --from SOURCE          Initialize PCR predictor from indicated source (see below)
  -A name, --algorithm name
                         Use hash algorithm <name>. Defaults to sha256
  -F name, --output-format name
                         Specify how to display the resulting PCR values. The default is "plain",
                         which just prints the value as a hex string. When using "tpm2-tools", the
                         output string is formatted to resemble the output of tpm2_pcrread.
                         Finally, "binary" writes our the raw binary data so that it can be consumed
                         tpm2_policypcr.
  --stop-event TYPE=ARG
                         During eventlog based prediction, stop processing the event log at the indicated
                         event. Event TYPE can be one of grub-command, grub-file.
                         The meaning of event ARG depends on the type. Possible examples are
                         grub-command=cryptomount or grub-file=grub.cfg
  --after, --before
                         The default behavior when using --stop-event is to stop processing the
                         event log before the indicated event. Using the --after option instructs
                         pcr-oracle to stop after processing the event.
  --verify SOURCE        After applying all updates, compare the prediction against the given SOURCE (see below).
  --tpm-eventlog PATH
                         Specify a different TPM event log to process.

The pcr-index argument can be one or more PCR indices or index ranges, separated by comma.
Using "all" selects all applicable PCR registers.

Valid PCR sources for the --from and --verify options include:
  zero                   Initialize PCR state to all zero
  current                Set the PCR state to the current state of the host's PCR
  snapshot               Read the PCR state from a snapshot taken during boot (GrubPcrSnapshot EFI variable)
  eventlog               Predict the PCR state using the event log, by substituting current values. Only valid
                         as argument to --from.

The PCR index can be followed by zero or more pairs of data describing how to extend the PCR.
Each pair is a type, and and argument. These types are currently recognized:
  string                 The PCR is extended with the string argument.
  file                   The argument is taken as a file name. The PCR is extended with the file's content.
  eventlog               Process the eventlog and apply updates for all events possible.

After the PCR predictor has been extended with all updates specified, its value is printed to standard output.
cmp: /dev/shm/fde.hrptGE/recovered: No such file or directory
BAD: Unable to recover original secret
TPM seal/unseal does not seem to work; please take me to a parallel universe

Edit: there is a bug report on this: 1218390 – "fdectl tpm-present" fails with the combination fdectl v0.7.2 / pcr-oracle v0.5.4

Didn’t someone come up with a $15 hack that can read the key off of TPM ↔ mainboard communication lines on bootup? I believe this was with Windows but still it would be good to make sure the TPM ↔ mainboard comms are encrypted before heading down this path.

Thanks for sharing this, @pavinjoseph , I have found an article on arstechnica from 2021, it was a good read, including the recommendations on how to prevent issues like that.