this article was originally published at https://x.com/heytdep/status/1978172938206802036 sharing here for more visibility within the TEE community.
I suggest reading the whole post but the discussion I want to kickstart here is regarding this section:
TDX can generally be considered to have a smaller attack surface than SGX simply because the host/guest duality is completely different due to the underlying design of each of these technologies.
NB: this applies for enclaves/VMs in general.
That said, we do indeed expose interface for our trusted domains as well, it’s just being done differently … we can focus on VM state and I/O.
VM state. we can monitor vm state like vcpu entry, exit on TDG.VP.VMCALL (and re-entry) although these are much less informative than ecalls/ocalls on sgx due to the difference in the development workflow around how the host/guest duality works.
I/O. If you’re familiar with how the TDX base module deals with I/O you know that the guest can rely on (i) paravirtualization (ii) directly assigning devices to the TD and that it is the VMM/hypervisor (i.e., the td provider) that provides I/O to the guest and where safety must be ensured guest side (e.g., through encryption). This means that I/O does indeed cross TD boundaries. Paravirtualization which is becoming the most used approach by the VMM to provision I/O basically enables the TD to use devices that are owned and managed by the hypervisor through a VMCALL function. Disk I/O access, and network I/O (including calls to the quoting enclave) are exposed to the untrusted host which is the reason why we either seal or sign data that exits the TD boundaries.
For example, if you look at the dstack qemu configuration function , you can see that the host is instrumented with access (only covering some of the interesting parts here not all boundaries that are being crossed) to (i) disk I/O on rootfs (readonly), the virtual hard disk and the shared folder (ii) virtio-net so host captures all guest egress (iii) vsock for the quoting enclave comms (iv) vm entries, exits, re-entry (v) page access patterns.
Of course, this is all fine and expected as long as the guest correctly deals with encryption (as dstack does! it has also been audited) but it means that we do have an exposure of the interfaces, and actually TDX leaks more than SGX in certain domains, e.g., still leaking page faults to the VMM while running a whole VM means more pages so increased risk.
I haven’t performed the attack myself but am interested in spinning up a TDX machine and experiment with it. Also happy to collaborate on this! The scope of the work would in fact be mostly proving that selective censorship is possible for a near-zero attack cost on a P2P TEE solution and potentially exploring edge cases where secrets that undermine integrity safety can be inferred (e.g., making brute-force attack on application secrets feasible) + correlate if applicable granularity in the censorship filter to the attack complexity and different common code patterns.
Question is, has anyone ever trying to formalize such attacks on TDX with a clear methodology, code, interposers, etc? Also, has anyone been thinking about implementing generic obfuscation without degrading performance as in a proxy between the TD’s boundaries <> app logic? Imagine a proxy you can instruct to trigger on certain filters and with certain behavior to perform spatial obfuscation (this one’s easy) + carry out temporal obfuscation by enforcing logic to execute diff branches with decoys?