Recently I came across a blog article named The Flawed Design of Intel TDX written by Julian Stecklina when I was googling about TDX’s internal designs and working mechanisms. I quickly read the blog and found many claims unsound, at least from the perspective of a security researcher. I will elaborate on my views later in this article.
Quick recap: Intel’s Trust Domain Extensions (TDX) is an instruction set extension, Intel’s latest attempt at implementing a Trusted Execution Environment (TEE).
Julian’s main concern over TDX can be split into two, one is the increased complexity of the hardware and the non-transparent nature of the design that may block developers from contributing to the security of Intel-shipped softwares such as TDX modules. While I to some extent agree with Julian, an important assumption and real-world threats have been widely ignored.
TDX increases hardware complexity? This is unarguably true, but there is simply no free lunch when you want a more secure system. The security implication here is that the added complexity might introduce some unforeseen bugs or vulnerabilities such as Spectre or Meltdown. What I want to comment on such views is that new technology always serves as a double-edged sword, but if the benefits and advantages can overweigh the potential security risks, then people are willing to accept. If we are overly cautious about any new features being added, then nothing can be truly trusted without formal verification. Since the design of the TDX modules has been heavily investigated and many security researchers have contributed to the prototype, the chance that TDX has major flaws is relatively low, while it addresses a lot of trust issues in the area of cloud computing. The overall benefits make TDX acceptable.
TDX locks out any other provider of the microhypervisor in charge of the system by requiring the TDX module to come with an Intel signature, and TDX gives the end user an extremely poor experience for security issues. This is TRUE. We hate monopoly, but here the problem is that we have to beg for Intel’s mercy to publish correct software and microcode. TDX’s security heavily relies on the correct implementation of the TDX module for handling SEAMCALLs and TDCALLs and other cryptographic primitives. If the TDX module has flaws then the whole system is precarious. Interestingly, one of my idea during my internship at TikTok aligns with this. If we cannot trust Intel, then we verify it. Although there are many technical challenges and issues, it is worthwhile.
TDX module is probably written in shoddy C. This sounds tricky. How are you gonna reason about the security of Linux Kernel? Do you think Linux kernel is written in shoddy C?
Would you want the software you base all your security hopes on to be written in the least secure programming language?
Do you trust Linux? While making Linux kernel trustworthy seems formidable, making TDX module might be a feasible practice. This is because TDX module (and SVSM for AMD SEV-SNP) is minimal since it only handles critical TEE operations (SEAMCALLs and TDCALLs). We can instead apply program analysis, formal methods, etc. when we actually want to verify the correctness of the implementation. Although I am in favor of other safe languages (i.e., Rust), I don’t think Rust eliminates all the issues. A lot of attacks are not based on memory safety problems but are based on implementation errors due to slips made by developers. Rust is no more helpful than other vanilla languages.
Intel already provide all the building blocks of a solution that gives you the benefits of TDX with far fewer downsides.
Boot your secure microhypervisor as a normal baremetal hypervisor. The boot process can be secured via Secure Boot. You can perform remote attestation as well. For this Intel TXT comes in handy. The microhypervisor can defend itself at runtime using an IOMMU and defend VMs using TME-MK.
This is an interesting point of view.