[RFC] The code that creates the TCG Event Log needs an audit
The TCG support code included in the EDK2 tree is in place to enable the two major features provided by a platform TPM. 1) To "seal" secrets in to TPM memory (i.e., Bitlocker keys), and 2) to enable remote attestation and verification of a platform's security status after boot ("measured boot").
The first feature is widely being used. Use of the second has been described in NIST SP 800-155 but not widely implemented. The industry and several standard groups are attempting to enable this attestation and verification process. To make that happen they need, not just the PCR recorded measurements, but also the accompanying event log. The even log is used by a verifier to understand the how PCR values were created and decide if those values have a negative security effect on a platform.
Researchers, attempting to implement proof-of-concept verifiers that can parse the event logs produced by the wide variety of platform types across the industry, have generally found they are unable to parse the logs. They have found problems with missing data, misunderstandings of what should have been logged, and outright code bugs.
Enablement of measured boot and verification is a primary purpose of the code in \SecurityPkg\Tcg and supporting functions. Since the EDK2 code is the implementation of this support most widely used across the industry, the community needs to make sure it provides its intended functionality.
We need to audit the existing code to make sure it is doing what it is supposed to do per specification and is as bug free as we can make it. And we need to make sure it continues to provide correct functionality as it is updated and maintained.
To make sure the code is doing what it is supposed to do, it has been suggested that the community audit the existing code and develop a design document describing the existing implementation, including each event type enumerated along with a specification of its contents. The process of reviewing the code to provide this document would have a positive side effect of doing a code inspection that may result in finding current implementation bugs.
It has been reported that the TCG specifications may be hard to understand and that may result in implementations that do not provide the intended functionality. Also, the TCG specs point to UEFI specs for some details and as the specifications drift over time, this may result in implementor confusion and errors.
With a document describing the EDK2 intent and implementation details, members of TCG workgroups and the team implementing the proof-of-concept parser/verifier can provide input on where implementation has diverged from the intent of the relevant specifications.
To insure the EDK2 code continues to function properly, the community also needs to provide tests for this code to reduce the likelihood of future regressions in functionality.
Dick Wilkins, Ph.D.
Principal Technology Liaison
Phoenix Technologies, Ltd.