Thank you for the thought-inspiring questions, Andrew.
Re: AMD SEV
Yes, there are a bunch of VM-based TEEs out there now, including ARM CCA and IBM PEF, beyond AMD SEV/SEV-SNP, and Intel TDX. The Intel TDX Demystified paper (linked in Further Reading) has a comparison of some of these peer technologies.
Re: SCONE/Enarx/Gramine
I was not aware of Enarx and SCONE. All three sound like complementary deployment platforms for apps wanting to use one of several TEEs. As of now, it is unclear what the security level differences are for VM vs Process-based TEEs outside of the developer experience, which it seems like these software frameworks already seem to bridge. This could be an avenue for future research and probably depends heavily on specific TEE implementations. Great question though!
In particular, I do know that Intel TDX does come with several side-channel mitigations based on lessons learned from the last decade of Intel SGX vulnerabilities. E.g. mitigations for timer interrupt-based / replay attacks like SGX-Step/Microscope
This depends on which integrity mode is used. Logical integrity (LI) is weaker and just uses the TD Owner bit, whereas Cryptographic integrity (CI) also involves the memory controller recomputing and verifying MACs for loads, that are stored in ECC memory. Since these mitigations are applied in the memory controller, it will be able to detect writes from the hypervisor as being executed in the untrusted (non-SEAM mode) and clear the TD Owner bit in ECC memory. This can be surmounted using Rowhammer. Furthermore, the hypervisor cannot directly obtain ciphertext since reads return all 0s. This might work with a malicious TD that is also running in SEAM mode (similar to the setting I described for the ciphertext side-channel attack).
From my current understanding, I believe replay attacks would need to be done using physical access (to get around memory controller-level protections and ECC memory).
x86_64 processors use the SYSCALL instruction to run system calls, whereas x86_32 processors use interrupts – this is a special case which bridges these two worlds. The fix in the kernel was to disable 32-bit emulation mode by default, which can be enabled with a flag if needed. One would want to check if the kernel used in Yocto has this mode disabled, which would restrict TDX Guests to run only 64-bit OSes and applications.
If I understand correctly, you’re asking how we can technically enforce this. I don’t know the answer off the top of my head. The place to control this would be in the TDX Module, which is responsible for managing TDs and their private memory. Either enforcing using a specific version of a signed TDX module, or including TDX module configurations in attestation quotes in a high-integrity manner would be two ways to approach this. As of now, I believe only Intel can deploy changes to the (signed) TDX Module.
Mitigations with where it makes to integrate them
- Constant time programming (application / library)
- Data operand independent timing (DOIT) bits (application / library)
- SMT off (already attestable since it is a BIOS setting that shows up in the quotes)
- ORAM (application / system)
- Secret masking (application would need an extra binary instrumentation step)
Mitigations 1-3 should always be done and are recommended for security-sensitive code by multiple vendors.
Mitigation 4 would be necessary on successful exploitation of the page blocking oracle, which would leak memory access patterns.
Mitigation 5 would be necessary on successful exploitation of ciphertext side-channels on TDX. This would have a significantly higher bar compared to AMD SEV-SNP and Intel SGX, given the difficulty of accessing ciphertext from a TD by another component (malicious TD/VMM), the ability of applications to use multiple encryption keys, and the fact that each TD has its own address space, EPT, and private HKID needed to access memory. A physical attack could undermine some of these protections, but further research is needed.