keylime / keylime/enhancements

Swapping boot event log parsing to pure python

Open
#96 0 comments 3 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
3
Forks
22
PR merge metrics
No merged PRs in 30d

Description

# Replacing the boot event log parser (a call-out to the Intel TPM2 tool kit) with native python code
- One-line enhancement description (can be used as a release note): as the title says,
- Keylime Enhancement Proposal: https://github.com/keylime/enhancements/pull/97
- Primary contact (assignee): @galmasi,
- Backup: @maugustosilva
- Known-to-be-interested parties: @THS-on @mpeters
- Enhancement target:
- Alpha release target (6.7.x, TBD)
- Beta release target (6.8)
- Stable release target (7.0)

## 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?

* 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](https://github.com/galmasi/python3-uefi-eventlog). 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

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reviewing the Keylime Enhancement Proposal and the existing python3-uefi-eventlog project, including its CI and unit tests. The work is complete when the parser is moved into the Keylime space, packaged separately, and used as a Keylime dependency without relying on tpm2_eventlog.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.