there's probably zero chance of us exposing the host TPM to the VM

we're investigating vtpm support, but i'm not sure we have a bug to track that.  maybe Tom has something offhand for it.

respect to having hardware back ssh keys, that's already possible in CrOS today without using Crostini:
https://chromium.googlesource.com/apps/libapps/+/HEAD/nassh/doc/hardware-keys.md

vTPM meaning "it looks like a TPM inside the guest, but actually it's just a file on disk on the host"?

The support linked there is for the SSH app; for a variety of reasons I want to have hardware backed keys inside the VM, most importantly scripting and VCS integration.

> vTPM meaning "it looks like a TPM inside the guest, but actually it's just a file on disk on the host"?

basically. the file would live in the user's encrypted storage which is backed by the real tpm.

Tom hasn't responded, so I'm just going to create a bug and dupe into that.

if you look through the docs I linked, the hwkeys work with any ssh client. so once we have USB pass thru, you can use that to pass the hwkey in. or if you're creative, could probably have an ssh-agent app expose access over the local network for the VM to use.

either way, direct access to the real TPM from VMs is off the table.

Ok. I think that reasonably meets my threat model -- I'd like to be resilient to path traversal and other arbitrary read vulnerabilities. Obviously doesn't protect against them on the host, but that should be a significantly thicker attack surface (no curl | bash there!).