Overcomming space limitations for fancy features

[itay-grudev]

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?

[tlaurion]

@itay-grudev Interesting idea, really.

What you are looking for is the code used to create nvram space and what is used to set and use Disk Unlock Key.

Some references:

• Using TPM secret (here TPM LUKS header + NVRAM passphrase to unseal secret and insert it in initrd)
• Sealing secrets into nvram space with a passphrase + external factor (here LUKS header) + measurements
• underlying code for unsealing TPM nvram space

[tlaurion]

I specifically like this idea since with default QubesOS boot partition with default layout of 1Gb, we have that space and could easily change it to fit our needs. That could easily be a LUKS encrypted loop container with LUKS header validated and unlocked automatically, if firmware was not tampered with? Raw thoughts here. Would need more thinking.

The TPM used PCRs have changed recently to fit upcoming coreboot 4.12 and future coreboot releases and their measurement scheme. Doc have been updated accordingly: linuxboot/heads-wiki@8e8a50e

EDIT: @itay-grudev questions that arises would be:

• How to deliver and update this external payload.
• Would that payload be an overlayfs applied on top of the tmpfs?

[tlaurion]

@flammit I feel your input here would be really interesting. Same for @osresearch

[tlaurion]

@flammit @osresearch @itay-grudev : Speak up :)

[itay-grudev]

Would that payload be an overlayfs applied on top of the tmpfs?

I say just normal files placed in /boot. This means there wouldn't be an extra validation step as the current system already validates and signs all files in /boot. Also it has the extra advantage of being easily editable for tweaking if required.

How to deliver and update this external payload?

The make install step can add all of the of the required files to /boot and we can follow the grub convention and place them in /boot/heads/. The tricky thing is splitting heads into two parts - the absolutely required libraries (on the flash chip) to validate the boot files and then everything else which is loaded afterwards. Updating it is as simple as replacing those files.

[tlaurion]

@itay-grudev hmm. Played a while ago with overlayfs on packetprotector. Worked really well. Was looking for a mounted file and if found (without further validation i nthat time) was just applying it on top of actual filesystem (where here its ramfs, would be even ideal since we could even override everything based on keys fused in rom).

Thoughts? It could be packaged by CI, and checked against signature fused inside of upgraded rom for a particular commit. It could also be copied over from QubesOS, while fwupd ( #834 ) could also deliver it in upgrade folder (under /boot) and validate signature prior of prompting for rom flash and moving the file (would have to talk to others about that though). Also linked to #523 .

@pietrushnic?

[Thrilleratplay]

Under #590, I was asked to weigh in on this subject but am not sure how much crossover my comment has here.

The only thing that come to mind is what could and could not be moved from the ROM to the /boot partition? A better way to ask this is, if Heads related functionality under /boot went missing/erased/corrupt/etc or a device is being initialized, what is the minimum needed for the user to configure the system?

A few other questions:

• Could kernel modules be loaded via insmod if found under specified directories in, for example, /boot/heads/modules/.
• Would doing this impact changes needed for kexec-select-boot: Find a way to not search whole partition #447?
• Would this prevent encrypting /boot

[tlaurion]

That is why I have a bit of passion about overlayfs, which would extend the filesystem, superseeding files already existing on fs and adding others, while being easy to deploy (even maybe for fwupd that could drop, side by side, overlayfs file to be mounted over / (so over ramfs / of heads), from signed /boot/heads, or as expected from fwupd under QubesOS, under /boot/updates

[tlaurion]

Some background on overlayfs, OpenWRT usecase.

[pietrushnic]

@tlaurion in concept this sounds like a try of implementing binary delta updates. Chromium pioneered the massive application of those. The important thing would be to have support for such a thing in the build system. Then issues are validation and reproducibility of results after patching.

[itay-grudev]

@tlaurion We are currently not signing releases and trusting them implicitly. Instead the user explicitly signs and trust a version they compiled. I think you are proposing we change that with the external storage and automated CI builds.

Furthermore I do agree, there may be some advantages in using overlayfs, but I thing the primary focus should be simplicity, easy of use and verifiability. If that is easily achievable with overlayfs - absolutely.