You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The gist of the proposal is to replace Keylime's reliance on the tpm2_eventlog command with native Python code.
Motivation
The current implementation of measured boot attestation in Keylime has two major drawbacks: (a) its reliance on a foreign tool to parse the binary boot event log (b) a custom-built policy engine that separates "policy" from "policy instances", with the additional awkwardness that policy is written as python code compiled into keylime and cannot be changed at runtime.
The current proposal addresses problem (a) -- the dependency on a foreign tool, and the instability that results from trying to keep up with the evolution of said tool. There are dual problems of bugs in the code as well as arbitrary changes in the output format (nominally YAML). Wide variations in accepted input files and formatted output have been observed over relatively small changes in point releases of tpm2-tools.
Is this a good thing(tm) to do?
Advantages: bugs get fixed in the Keylime timeline, and outcome variability driven by minor version changes in external tools disappears. Post-processing output with libefivar becomes a natural built-in element rather than an afterthought (as currently implemented).
Disadvantage: an extra 707 lines of code (as of writing this document), including maintenance thereof.
Neutral: no real performance disadvantage; the typical binary event log is ~ 15KB long and takes 1ms to parse into JSON.
The mitigation argument to counteract the disadvantage of having 700 extra lines of code to maintain is that (a) the TCG and EFI documents regarding the formatting of the boot event log are crystal clear, change slowly and are easy to implement (b) there are really only two well known implementations of the event log parser, and both of them have issues (c) the event log parser code written in Python is considerably easier to read than its equivalent in C, because of the ability to use Python class hierarchies and parse binaries with struct.
A proposal for how to proceed
The current implementation of the python event log parser is here. It has its own CI with unit tests. Following an initial discussion with @mpeters and @maugustosilva I propose to
move the event log parser as a new project into the keylime space
provide separate packaging as pypy, rpm and deb package
use it as a dependency in the keylime project
The text was updated successfully, but these errors were encountered:
Replacing the boot event log parser (a call-out to the Intel TPM2 tool kit) with native python code
The proposal
The gist of the proposal is to replace Keylime's reliance on the
tpm2_eventlog
command with native Python code.Motivation
The current implementation of measured boot attestation in Keylime has two major drawbacks: (a) its reliance on a foreign tool to parse the binary boot event log (b) a custom-built policy engine that separates "policy" from "policy instances", with the additional awkwardness that policy is written as python code compiled into keylime and cannot be changed at runtime.
The current proposal addresses problem (a) -- the dependency on a foreign tool, and the instability that results from trying to keep up with the evolution of said tool. There are dual problems of bugs in the code as well as arbitrary changes in the output format (nominally YAML). Wide variations in accepted input files and formatted output have been observed over relatively small changes in point releases of
tpm2-tools
.Is this a good thing(tm) to do?
libefivar
becomes a natural built-in element rather than an afterthought (as currently implemented).The mitigation argument to counteract the disadvantage of having 700 extra lines of code to maintain is that (a) the TCG and EFI documents regarding the formatting of the boot event log are crystal clear, change slowly and are easy to implement (b) there are really only two well known implementations of the event log parser, and both of them have issues (c) the event log parser code written in Python is considerably easier to read than its equivalent in C, because of the ability to use Python class hierarchies and parse binaries with
struct
.A proposal for how to proceed
The current implementation of the python event log parser is here. It has its own CI with unit tests. Following an initial discussion with @mpeters and @maugustosilva I propose to
The text was updated successfully, but these errors were encountered: