Overcomming space limitations for fancy features

Nobody has claimed this yet.

One of the most popular type of issue here looks like this:

> Can we add library _X_ to allow _Y_, because it will be _(really cool/more secure/easier to use/etc.)_.

And the most popular type of answer is:

> Sure, but that adds _N>1MB_ of storage and it definitely won't work on the X320 as it only has 4MB of storage on the flash chip.

But the whole point of `heads` is that it validates user signed content which it subsequently kexecs into. So how about loading modules from the boot partition, signed with a key stored on the _TPM_?

_Heads_ will be able to validate the integrity and signatures of the modules stored in the boot directory prior to loading them using the secret stored in the _TPM_. If we can protect the secret so it is not exposed to the subsequently booted OS, this system would allow for lot of bloat and plenty of storage for additional features. We will still be encouraged to minimise the total size of modules as it would slow down boot times, but it will give us more freedom, especially on older systems like the X320.

So the core question is whether we can protect a secret on the _TPM_ and reserve it exclusively for _Heads_? Are there any major problems I'm missing?

Start by reviewing Heads' TPM integration and the path that validates and kexecs signed content, then check how modules in the boot directory are discovered. Determine whether a TPM secret can be reserved for Heads and kept from the subsequently booted OS; done means documenting the security constraints and a feasible design.

Written by the indexing model from the issue text.