This possible vulnerability was brought up by @dvdplm in a conversation on slack.

The host operator of is able to read and write the disk volume the entropy-tss CVM uses. We protect the CVM by keeping almost everything in a measured ramdisk. Except for things which require persistence accross reboots.

Everything we store in persistent storage is encrypted using authenticated encryption, so we have some integrity protection. But @dvdplm points out this is still vulnerable to rollback attacks where the attacker replaces the storage with a previous valid state.

I think for this reason we should avoid reading from storage unless we have no choice. The only time we have no choice is following a reboot.

Normally, when we read the keyshare from the kvdb, it will read a cached copy from the last write from memory. But this relies on the internal behavior of sled and is not guaranteed to be the case. For this reason i propose to keep the keyshare in memory as part of application state. When mutating it, we should also write the latest state to the kvdb, but reading it should always come from memory only.

There may also be some integrity checks we can do when restoring backups to check whether it appears to be the most recent state.