chrisfenner / tpm-spam Goto Github PK

There are 3 packages:

• eighttree, which contains one 54-line file
• helpers, which contains two files:
  • hashing.go, 18 lines
  • policy.go, 589 lines

The Policy.go part of helpers should be broken up into some smaller libraries, e.g.:

• helpers for checking satisfiability of a policy given some TpmState
• helpers for running TPM policy commands
• helpers for calculating TPM policies
• helpers for normalizing spam policies
• helpers for tree-izing normalized spam policies

There should not be a library called helpers. They are all helpers.

For a 64-byte NV index, having a policy hash bloats the size in flash by around 50% (attributes, size, and other small bits of metadata aside).

If there is a way to make spams write-once in practice without a policy, we should switch to it. For example, we could use WriteLock to lock the index after writing it, and use TPMA_NV_WRITE_STCLEAR to ensure that WRITTEN and WRITELOCKED both get cleared on TPM reset or restart.

This might increase the number of Orderly spams supported by the reference implementation (#22) from 6 to 8 or 9.

• All packages should have good descriptions
• Go imports should be chunked up into (standard library, other github, local) chunks consistently from file to file
• All exported functions should have good descriptions
• Use method receivers consistently and where it cleans up the calling patterns
• Resolve all the TODOs sprinkled around the code
• Improve errors returns and checks using go1.13 improvements and error types instead of fmt.Errorf

With the initial barebones implementation complete, I see some interesting things:

• The TPM reference code simulator allocates 512B for Orderly NV, limiting us to 6 (if they have Policy) Orderly spams.
• Using Orderly spams still triggers one write to all the NV indices during clean shutdown, same as if they were not Orderly
• TPM implementations are permitted not to allow Orderly Ordinary indices

There are a couple of options:

1. • Switch over to non-orderly spams
2. • Support both orderly and non-orderly spams transparently by adding more OR branches during Normalize

The only reason I can think of to do (2) other than "someone else might think of a reason later, we could just be universally compatible from time t=0" is that some firmware TPM implementations have a "dark period" where writes to NV and DA counters have to fail (because there is actually no access to persistent NV during this time).

proto is nice for imagining policies that come from a machine, but as can be seen in the examples, it's pretty heavyweight for human-readable spam policies.

Consider something like YAML:

• Uses indentation instead of braces
• More commonly hand-written than textproto
• Improve readability with anchoring and aliasing
  • e.g., define "good kernel" as some sub-policy, then reference it from elsewhere in the policy, maybe even from multiple places

vs. JSON:

• Less visual clutter - allows keys to not be quoted
• JSON doesn't support anchoring/aliasing
• JSON is a bit more standard of an interchange format, but for policies that might come from an RPC proto is the clear winner anyway

Open question: should there be a way to invalidate a previously-written spam? For example, a kernel might need to kexec another kernel, but invalidate its own spam. This would need to not result in the spam becoming writable again.

For example, every spam could have a policy that allows writing all zeros into it, even if written. This would mean sticking with the NvWritten policy and not switching over to a lock mechanism (#23).