I've played around with this for quite some time and wanted to get some more eyes on this code.  I've created a draft PR with "ZFS on Linux", asking for a discussion of methodology.  Likely, the people on this list can speak to the utilization of TPM2-tools and help with the security aspects more than the filesystems focused developers there.

Please have a look and submit comments here or the PR itself.
https://github.com/zfsonlinux/zfs/pull/9852

Many thanks,
Garrett Fields

On Mon, Dec 9, 2019 at 11:15 PM Garrett Fields <ghfields@gmail.com> wrote:
Back in the end of July, I wrote a message on this discussion list titled "PCR Policy enforcement when using nvram".  In that, I asked for a way to have both a PCR check AND a password lock an nvram range (not an OR).  I really appreciated everyone's help, especially William Roberts, who gave some sample code of using a session to accomplish this goal.

Now that Ubuntu has updated its repositories for the upcoming 20.04 LTS release and included TPM-tools v4.x, I figured it was time to take another look.

My goal is to provide a method to auto-unlock a ZFS encrypted root filesystem.  Currently, ZFS allows for unlocking via a prompt or file containing a raw, hex, or passphrase values.  The mechanisms are already inplace to prompt on startup.

So far I have just done a proof of concept.  It probably loads of bad code and tons of polish needed:  https://github.com/ghfields/zfs/compare/master...ghfields:tpm2-autounlock

I forked the zfs project, expanded the its initramfs hooks to include the required tpm2-tools binaries, and added another stanza to init script's decrypting section.  I also created a pair of scripts that configures the system and tests readback.

The nvram index and the PCRs used are stored/read from the zfs filesystem properties.  I used the  filesytem's GUID as the required password as another check to verify the NVRAM range was intended for that filesystem.   I also intend to issue an nvreadlock to prevent snooping once the key is used.

I'd be interested in a critique of the method overall  I expect there ways to make this more secure.  With enough effort, one could issue a break=premount on the kernel line and manually extract the password from the TPM.  Any way to tighten that up?

I'm a total novice at TPM in general, but am completely open to advise and guidance.

Thanks,
Garrett Fields