New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tpm2: whenever we measure, also write a tpm log record #29004
Conversation
This is split out of #28891, but makes a ton of sense of its own. In fact, when we added the measurement in userspace we should have added this right away. I am pretty confident that this is the way to go, in the interest of any tools that want to do remote attestation or similar. I wanted to implement CEL-JSON 1:1 for this, but ultimately decided against it, because the format isn't a perfect fit: writing the record number out each time would mean we'd have to keep a counter somewhere, and probably to analyze the firmware event log first, to initialize it to the right value. but that's inefficient and sucks. Hence I opted to simply write the records out without record numbers, expecting the consumers to append the numbers implicitly when reading it. The other change is that this uses CEL-JSON records joined in an JSON-seq (RFC7464) sequence rather than in a JSON array. This is also done for efficiency, and to make sure our logs are append-only, and we do not need to read the whole logs into memory before writing out another record. conversion from this format to proper CEL-JSON is trivial: just read the objects, wrap them in a JSON array, and insert a recnum field counting up to each object. That's all. |
Can you add a test for this in TEST-70-TPM2? To verify that the format is what it should be, etc |
3021964
to
79bb8f7
Compare
test still missing |
79bb8f7
to
e7df2b6
Compare
added test. |
Previously we only logged our measurements to the journal. This is not a great solution though, since regular logs are subject to rotation, which is something we really cannot have for measurements (as it means we can never reproduce the PCR values from the data). Hence, let's maintain an explicit log. Ideally, we'd just use the TCG Canonical Event Log format 1:1 (https://trustedcomputinggroup.org/resource/canonical-event-log-format/). However it's not a perfect fit fo us, for various reasons. But let's follow it (in its JSON incantation) as closely at it makes sense, so that it can easily be converted to the full format by programs consuming it. Code comments explain where we deviate from the TCG CEL-JSON, and what to do about it when reading the data.
e7df2b6
to
b515fc5
Compare
b515fc5
to
a4e941e
Compare
CI failures unrelated. Taking liberty to merge, since the code was already reviewed, and only the test was missing, which however is in place now. |
Previously we only logged our measurements to the journal. This is not a great solution though, since regular logs are subject to rotation, which is something we really cannot have for measurements (as it means we can never reproduce the PCR values from the data). Hence, let's maintain an explicit log.
Ideally, we'd just use the TCG Canonical Event Log format 1:1 (https://trustedcomputinggroup.org/resource/canonical-event-log-format/). However it's not a perfect fit fo us, for various reasons. But let's follow it (in its JSON incantation) as closely at it makes sense, so that it can easily be converted to the full format by programs consuming it.
Code comments explain where we deviate from the TCG CEL-JSON, and what to do about it when reading the data.