Hardware
This section benchmarks the confidential Knative and SEV architectures. All benchmarks use the same application, which is a Rust web server with an API endpoint. At startup, an ED25519 key pair is generated and passed to the endpoint. The endpoint signs any message with the private key and returns a signature. The sample application is used because the coding of the wallet was not complete at the time of the benchmark. Therefore, the sample application is used to simulate a transaction authorization that includes a signing process.
SGX Architecture (confidential Knative)
In the case of confidential Knative, containerd is used as the container runtime and the application is grammarized. The bare metal machine supports SGX2 and is used here. This is made possible by the new version of Gramine and I updated the Gramine OS from enclaive to the latest version 1.4. Additionally, before the web server starts, a pre-main is started that connects to a vault using RA-TLS to get a secret. This secret is not used. However, this still simulates secret key provisioning well, since the first time the wallet is started, the wallet key is also generated inside the enclave and not in the vault. Thanks to Enclaive for letting me use their SGX2 ready bare metal machine. The machine was equipped with an Intel Xeon Silver 4310 CPU with a base frequency of 2.1 GHz, 12 cores and a maximum turbo frequency of 3.3 GHz.
SEV Architecture
For SEV, containerd is also used as the container runtime for better comparability. Again, before the web server starts, an mTLS connection is made to the vault to retrieve a secret. Istio uses the node agent for certificate provisioning. In addition, a single cVM was used to provision the entire cluster for cost savings. This should only be a few milliseconds faster because there is no node-to-node travel time. As you can see from the graphs below, this would not have made any visual difference.
Unfortunately, bare-metal machines are very expensive and can only be rented on a monthly basis, so this is too expensive for a short benchmark. For SEV, an Azure VM was used, namely the standard DC4as_v5 with 4 vCPU's and 16 GiB of memory. This cVM uses AMD's third-generation EPYC 7763v processor with a base frequency of 2.5 GHz and a maximum boosted frequency of 3.5 GHz. As a result, the SEV measurements are not fully comparable to the bare-metal machine, which had significantly more cores available, but at a lower frequency. Also, the isolation between the serverless containers is not quite comparable to Gramine in the case of SEV. The original plan was to use Kata containers to provide isolation through hardware virtualization, but Azure does not allow nested virtualization. Therefore, the simple Kata benchmark is mostly used to compare with Gramine. However, some of the results are surprising.
The main difference between serverless containers and normal containers is the constant up and down of serverless containers. This is what the benchmarks focus on. So serverless containers are just like regular containers after startup, benchmarks done after startup are the same as regular benchmarks. I decided to create 10 to 75 Knative services simultaneously and measure the time it takes for all serverless containers to be up and running. Initially, the serverless container is always started when a Knative service is created. The main purpose of this benchmark was to select a trusted computing technology for the next chapter. There, each crypto wallet gets its own serverless container after registration, so the benchmark simulates the processing of simultaneous registrations.
Security Properties
Internal Threat excluded
✅
✅
External Threat excluded
✅
✅
Control-plane untrusted
✅
❌
Strong isolation of containers
✅
❌
Guest OS untrusted
✅
❌
Container-level attestation
✅
❌
Last updated