Re: The code that creates the TCG Event Log needs an audit

Zimmer, Vincent

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Tuesday, November 17, 2020 9:55 PM
To:; dick_wilkins@...
Cc: Yao, Jiewen <jiewen.yao@...>; Zimmer, Vincent <vincent.zimmer@...>
Subject: RE: The code that creates the TCG Event Log needs an audit

Good suggestion. Thanks Dick.
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.

Thank you
Yao Jiewen

-----Original Message-----
From: <> On Behalf Of Dick
Sent: Wednesday, November 18, 2020 2:23 AM
Subject: [edk2-rfc] The code that creates the TCG Event Log needs an

[RFC] The code that creates the TCG Event Log needs an audit Problem
Statement 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.
+1-425-503-4639 Cell

Join to automatically receive all group messages.