Good suggestion. Thanks Dick.
toggle quoted messageShow quoted text
Vincent and I have plan to refresh our TPM2 whitepaper recently.
We will definitely take it into consideration, to add more detail on describing the EDK2 intent and implementation.
From: firstname.lastname@example.org <email@example.com> On Behalf Of Dick Wilkins
Sent: Wednesday, November 18, 2020 2:23 AM
Subject: [edk2-rfc] The code that creates the TCG Event Log needs an audit
[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
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
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.