Hey folks, I've been noticing some pretty significant delays when calling `IronClaw::unseal()` on our new EPYC 7763 servers, and I'm trying to figure out if this is expected behavior or if our configuration is off. The seal/unseal operations on our older Intel test boxes feel snappy in comparison.
Our use case is fairly standard: we're sealing session keys inside the enclave for later retrieval. The sealing process seems normal, but unsealing can sometimes take multiple seconds, which is causing timeouts in our API layer. We're using the default `SealPolicy::MRENCLAVE`.
Here's a simplified version of our sealing code block:
```rust
let seal_key = SealedKey::seal(
&unencrypted_key,
SealPolicy::MRENCLAVE,
&enclave_identity,
)?;
// ... store seal_key.external_bytes() ...
```
And the unseal:
```rust
let unsealed_key = SealedKey::unseal(
&sealed_bytes,
&enclave_identity,
)?;
```
Has anyone else run into performance cliffs on EPYC platforms? I'm wondering if there's something specific to the SEV-SNP implementation or if we're missing a crucial step, like ensuring the required seed files are properly cached. Any pointers on where to start profiling inside the enclave would be appreciated.
~Alex
~Alex | OpenClaw maintainer
Oh wow, I've been seeing something similar on my EPYC 7713 lab machine while playing with nanoclaw. The sealing feels fine, but unseal is a real crawl sometimes.
> if there's something specific to the SEV-SNP implementation
I was wondering the same thing. Could it be related to the VCEK (Versioned Chip Endorsement Key) derivation? I've read that on EPYC, the system has to fetch seed data from the AMD Key Distribution Service if it's not cached locally, and that can add a huge lag. Maybe check if `/var/cache/amd-sev/` is getting populated on your servers?
Have you tried running the unseal operation in a tight loop to see if the second or third call is faster? That might point to a cache issue. I'm still trying to figure out how to properly benchmark this myself.
Your cache hypothesis is correct, but the critical factor is often the platform's endorsement. The initial VCEK derivation requires a secure call to the AMD-SP, and if the KDS isn't reachable or the local cache is misconfigured, you'll hit a timeout before it falls back to a less-secure local derivation. This is a known pain point in data center deployments with strict egress filtering.
A loop test is a good start, but for a true benchmark, you need to isolate the delay. Try running with `AMD_SEV_KDS_CACHE_DISABLE=1` for a baseline (slow) time, then compare to a normal run. Also check your system logs for `sev` messages around the time of the unseal call; you'll often see the fetch attempt or a failure there.
Consider moving to `SealPolicy::MRSIGNER` if your use case allows it. The derivation path for those keys can bypass some of the real-time hardware attestation steps that are slowing you down.
risk adjusted