tpm2_eventlog: error Cannot allocate memory when using --eventlog-version=2

[GastoonMeghi]

I'm having this issue while running it on a docker container with fedora's latest version.

docker pull fedora inside the container installed tpm2-tools as follows: sudo dnf install tpm2-tools.x86_64

I copied a binary_bios_measurements file from another machine to the container to perform the test, since it already failed in RHEL8, and run the following command: tpm2_eventlog --eventlog-version=2 ./binary_bios_measurements

The first part of the output seems to be okay but at the end I see:

ERROR: Failled to allocate data: Cannot allocate memory

ERROR: failed to parse tpm2 eventlog ERROR: Unable to run tpm2_eventlog

I have the complete output if need, I executed it on a VM so I think it shouldn't be security sensitive. Let me know if it's useful and I can include it in the issue.

tpm2_eventlog -v tool="tpm2_eventlog" version="5.2" tctis="libtss2-tctildr" tcti-default=tcti-device

[idesai]

@GastoonMeghi can you share the binary_bios_measurements file?

[GastoonMeghi]

@idesai Yes! sure. You can find it attached.

binary_bios_measurements.zip

[kgoldman]

Events 7 and 8 are a bit peculiar. Do you have any specifications on this so I can improve my parser. Here's the best I can do: Variable GUID: 605dab50-e046-4300-abb6-3dd810dd8b23 SHIM_LOCK_GUID Variable: SbatLevel VariableDataLength: 18 SignatureLength: 0

Variable GUID: 605dab50-e046-4300-abb6-3dd810dd8b23 SHIM_LOCK_GUID Variable: MokListTrusted VariableDataLength: 1 SignatureLength: 0

[kkaarreell]

Update: The issue below is not tpm2-tools one, most likely the root cause is in shim package.

I am observing similar issue

# tpm2_eventlog --eventlog-version=2 /sys/kernel/security/tpm0/binary_bios_measurements

- EventNum: 29
  PCRIndex: 7
  EventType: EV_EFI_VARIABLE_AUTHORITY
  DigestCount: 1
  Digests:
  - AlgorithmId: sha256
    Digest: "5f62a2107fa11ce0485fd252d2e6c603cb8ed075861f9513bfed0a26bf6ed62b"
  EventSize: 61
  Event:
    VariableName: 605dab50-e046-4300-abb6-3dd810dd8b23
    UnicodeNameLength: 14
    VariableDataLength: 1
    UnicodeName: MokListTrusted
    VariableData:
ERROR: Failled to allocate data: Cannot allocate memory

ERROR: failed to parse tpm2 eventlog
ERROR: Unable to run tpm2_eventlog

binary_bios_measurements.gz

[snits]

@idesai What is the release schedule looking like? This is impacting us due to another project depending on the parsing of the eventlog.

I'm also wondering if the solution should be more general, because there is at least one more variable, SbatLevel, which I don't think follows the uefi_variable_data is uefi_signature_data pattern. It has a length longer than 16 so it doesn't hit the calloc failure.

[THS-on]

I'm also wondering if the solution should be more general, because there is at least one more variable, SbatLevel, which I don't think follows the uefi_variable_data is uefi_signature_data pattern. It has a length longer than 16 so it doesn't hit the calloc failure.

I just noticed this too #3145.

[idesai]

@idesai What is the release schedule looking like? This is impacting us due to another project depending on the parsing of the eventlog.

I'm also wondering if the solution should be more general, because there is at least one more variable, SbatLevel, which I don't think follows the uefi_variable_data is uefi_signature_data pattern. It has a length longer than 16 so it doesn't hit the calloc failure.

@snits we made a release very recently. We can create a bug fix release for this in a couple of weeks. Does that work?

[snits]

@idesai What is the release schedule looking like? This is impacting us due to another project depending on the parsing of the eventlog. I'm also wondering if the solution should be more general, because there is at least one more variable, SbatLevel, which I don't think follows the uefi_variable_data is uefi_signature_data pattern. It has a length longer than 16 so it doesn't hit the calloc failure.

@snits we made a release very recently. We can create a bug fix release for this in a couple of weeks. Does that work?

I think once a final fix is accepted into some branch that is good enough, and we can apply it as a patch. So a bug fix release would work, or as long as it is queued up in a branch to go into a release should work as well.

[snits]

It would probably also be worthwhile to put a check before the calloc() call to verify that variableDataLength is greater than sizeof(EFI_GUID), or check that a little further up when it is decided that it should be a EFI_SIGNATURE_DATA struct, and bail out if the check fails.