Enable node images to be run as virtual machines, improving data center adoption while continuing to support privacy-protecting subnets.
What you can do to help
- Ask questions
- Propose ideas
We need to enable our node images to be run as virtual machines to aid data center adoption and support privacy-protecting subnets. AMD SEV will allow us to do this with minimal R&D effort. It can provide confidentiality against a potentially buggy/malicious hypervisor and other code that may happen to coexist on the physical server. AMD SEV allows transparently encrypting the memory of each VM with a unique key and provides an attestation report that can help VM’s owner verify that the state is untampered and is being run on a genuine ADM SEV platform. This is especially relevant for IC, where IC-OS is deployed on remote servers that are not under our control. It can reduce the amount of trust needed to be placed in the hypervisor and the administrator of the host system.
Right now, there are 3 flavors of SEV:
- AMD SEV: Encrypt in-use data
- AMD SEV-ES (Encrypted State): Encrypt VM register state (Protect data in memory)
- AMD SEV-SNP (Secure Nested Paging): Provide strong memory integrity protection
Currently, our machines EPYC2 (Rome) have SEV enabled and SEV-ES can be enabled with a custom kernel. Whether we need a full-fledged SEV-SNP is something to be evaluated. SEV-SNP is available on EPYC2 (Milan) servers.
To have SEV functionality, we need the following requirements to be met:
- Agent providing secret: For each VM one agent (HW token, separate machine, etc.) knowing a secret whose disclosure is equivalent to SEV break
- Storage encryption: Each VM needs to encrypt its persistently stored data.
- Verified boot: Chain to verify that VM runs authorized software.
- Signed software builds: Authenticate the software towards verified boot.
- Bring up a QEMU image on an existing SEV machine and understand the tooling.
- Bring up an IC-OS node with AMD SEV
- Encryption of persistent storage
- Attestation (Does SEV-SNP help such that we don’t need an external attestation provider?)
- Verified Boot
- Keys and canister state have confidentiality and cryptographic integrity protection
- Ensure that host and guest isolation exists
- Only attested software is run as the Guest