Intel TDX — Trust Domain Extensions
Một Triết Lý Thiết Kế Khác: Tách Lớp Thay Vì Mở Rộng Tiệm Tiến
Ở file trước, chúng ta thấy AMD giải quyết bài toán Confidential Computing bằng cách mở rộng tiệm tiến cơ chế ảo hóa sẵn có (SEV → SEV-ES → SEV-SNP), mỗi thế hệ vá thêm một lớp tấn công cụ thể trên cùng nền tảng ASID-bound key và C-bit. Intel tiếp cận bài toán theo một hướng kiến trúc khác hẳn: thay vì mở rộng VMX (công nghệ ảo hóa gốc của Intel, tương đương AMD-V), Intel tạo ra một chế độ hoạt động hoàn toàn mới của CPU gọi là SEAM (Secure Arbitration Mode), nằm tách biệt về đặc quyền so với cả VMX root mode (nơi hypervisor chạy) lẫn VMX non-root mode (nơi guest OS chạy). SEAM host một thành phần phần mềm đặc biệt được Intel gọi là TDX Module — đoạn code được chính Intel ký số và load vào SEAM, đóng vai trò trung gian bắt buộc giữa hypervisor và mọi guest VM chạy dưới dạng Trust Domain.
Sự khác biệt này không chỉ là chi tiết kỹ thuật — nó phản ánh hai cách tiếp cận về ai chịu trách nhiệm thực thi chính sách cách ly. Với AMD SEV/SEV-SNP, hypervisor (KVM) vẫn trực tiếp quản lý vòng đời VM qua các lệnh CPU mở rộng, còn AMD-SP chỉ đóng vai trò giữ khóa và (với SEV-SNP) trọng tài kiểm soát RMP. Với Intel TDX, TDX Module đứng giữa hypervisor và guest cho mọi thao tác quản lý VM nhạy cảm — hypervisor không còn được phép trực tiếp gọi các lệnh quản lý VM (VMLAUNCH, VMRESUME tương đương) lên một Trust Domain; mọi yêu cầu đều phải đi qua TDX Module, module này kiểm tra tính hợp lệ của yêu cầu trước khi thực thi thay mặt hypervisor.
Trust Domain (TD): Đơn Vị Cách Ly Cơ Bản Của TDX
Trong thuật ngữ TDX, một guest VM chạy dưới bảo vệ được gọi là một Trust Domain (TD) — tương đương khái niệm "Confidential VM" nhưng là thuật ngữ kỹ thuật chính xác ở tầng CPU. Theo tài liệu Google Cloud, Intel TDX "creates an isolated trust domain (TD) within a VM, and uses hardware extensions for managing and encrypting memory" (Confidential VM overview). Mỗi TD được gán một TD ID duy nhất (khái niệm tương đương ASID của AMD), và TDX Module sinh một khóa mã hóa bộ nhớ ephemeral ràng buộc riêng với TD đó — hoàn toàn tương tự nguyên lý "khóa sinh trong phần cứng, không rời khỏi phần cứng" đã trình bày ở file 01, chỉ khác là ở đây đơn vị quản lý khóa là TDX Module chạy trong SEAM thay vì AMD Secure Processor.
Về mặt threat model, TDX được thiết kế đặc biệt nhấn mạnh khả năng chống lại tấn công vật lý vào DRAM — Google Cloud mô tả TDX "specifically addresses physical access threats, defending against DRAM-based attacks including memory capture and modification" (Confidential VM overview). Điều này bao gồm cả các kịch bản mà kẻ tấn công có quyền truy cập vật lý vào máy chủ — ví dụ gắn thiết bị bus snooping vào khe DIMM hoặc thực hiện cold boot attack (làm lạnh RAM để trì hoãn quá trình mất dữ liệu sau khi tắt nguồn, sau đó đọc trực tiếp nội dung) — vì mọi nội dung ghi xuống DRAM vật lý đều đã được mã hóa transparent bởi memory controller được TDX Module cấu hình, độc lập hoàn toàn khỏi việc hệ điều hành host hay hypervisor có bị xâm phạm hay không.
Cấu Trúc Đo Lường Toàn Vẹn: MRTD Và RTMR
Đây là điểm khác biệt kỹ thuật rõ rệt nhất giữa TDX và mô hình attestation "lai" của AMD SEV/SEV-SNP đã trình bày ở file trước. Với TDX, toàn bộ quy trình đo lường (measurement) đều do TDX Module thực hiện và lưu trữ trong chính module đó — không có bước trung gian qua vTPM phần mềm như SEV/SEV-ES. Tài liệu chính thức phân loại attestation của TDX là "xác minh phần cứng" thuần túy: "Mô-đun TDX đo firmware, tất cả phép đo được lưu trong mô-đun TDX" (Remote attestation overview).
Cụ thể, các phép đo được chia thành hai loại thanh ghi:
- MRTD (Measurement of Trust Domain): một thanh ghi đo lường cố định (immutable measurement), ghi lại trạng thái ban đầu của TD tại thời điểm khởi tạo — bao gồm nội dung firmware ảo và cấu hình ban đầu được nạp vào. MRTD được tính toán một lần duy nhất khi TD được build và không thể thay đổi sau đó trong suốt vòng đời của TD.
- RTMR (Runtime Measurement Registers): một tập các thanh ghi đo lường có thể cập nhật dần trong quá trình runtime — tương tự triết lý PCR (Platform Configuration Register) của TPM truyền thống, cho phép guest OS hoặc firmware ảo tiếp tục "extend" (nối thêm) các phép đo mới vào chuỗi hash hiện có khi hệ thống load thêm các thành phần (bootloader giai đoạn sau, kernel, initrd, thậm chí cả ứng dụng nếu được thiết kế để tự đo). Theo mô tả kỹ thuật, "measurements split between MRTD (firmware) and RTMR registers (runtime)" (From clicks to clusters).
Sự phân tách MRTD/RTMR cho phép một mô hình attestation linh hoạt hơn: một verifier có thể kiểm tra riêng "firmware ban đầu có đúng như kỳ vọng không" (qua MRTD) độc lập với "chuỗi phần mềm đã load sau đó có đúng như kỳ vọng không" (qua RTMR) — hữu ích khi bạn muốn phân biệt rõ lỗi cấu hình firmware (hiếm khi thay đổi) với lỗi ở tầng ứng dụng/OS (thay đổi thường xuyên hơn theo mỗi lần deploy). Google Cloud Attestation chịu trách nhiệm populate và verify các thanh ghi RTMR này: "RTMR Integration: Runtime Measurement Registers populated and verified by Google Cloud Attestation" (From clicks to clusters).
Launch Endorsement: Chứng Minh Firmware Là Của Google, Không Bị Giả Mạo
Một câu hỏi tinh vi hơn trong attestation: làm sao verifier biết được rằng MRTD đo được thực sự phản ánh firmware chính hãng do Google build và ký số, chứ không phải một firmware độc hại đã được tinh chỉnh để tạo ra measurement giả mạo trùng khớp? Câu trả lời là launch endorsement — với các Confidential VM dùng SEV-SNP hoặc Intel TDX, Google cung cấp khả năng "retrieve a Google-signed launch endorsement... A launch endorsement contains precomputed and signed measurements related to the firmware. Verify the launch endorsement by comparing against architecture-specific measurements" (Confidential VM attestation). Nói cách khác: Google tính toán trước (precompute) giá trị measurement kỳ vọng cho từng phiên bản firmware chính hãng, ký số giá trị đó, và verifier có thể so sánh MRTD thực tế nhận được từ attestation report với launch endorsement này để xác nhận firmware genuine — một bước kiểm tra bổ sung ngoài việc chỉ tin tưởng chữ ký của attestation report.
Ma Trận Cấu Hình Intel TDX Trên GCP
Theo tài liệu supported configurations, Intel TDX hiện được hỗ trợ trên các machine series sau, dựa trên vi kiến trúc Intel Sapphire Rapids:
| Machine series | CPU platform | Công nghệ | Ghi chú |
|---|---|---|---|
| c3-standard-* | Intel Sapphire Rapids | Intel TDX | Zone availability rộng nhất (22 zones) |
| A3 High | Intel Sapphire Rapids | TDX + NVIDIA Confidential Computing | Kết hợp bảo vệ CPU và GPU cho AI/ML workload |
Không giống C3D của AMD (hỗ trợ live migration), các instance TDX hiện không hỗ trợ live migration — một Confidential VM chạy TDX không thể được di chuyển sang host vật lý khác mà không dừng và khởi động lại. Đây là ràng buộc kiến trúc quan trọng: live migration đòi hỏi khả năng "chuyển giao" trạng thái VM (bao gồm cả trạng thái mã hóa) giữa hai host khác nhau một cách an toàn — một bài toán mật mã học phức tạp hơn đáng kể so với việc chỉ mã hóa bộ nhớ tại chỗ, và tính tới thời điểm hiện tại chưa được TDX trên GCP hỗ trợ.
Giới Hạn Kỹ Thuật Đặc Thù Của Intel TDX
Ngoài việc không hỗ trợ live migration, Intel TDX trên GCP có một tập ràng buộc riêng biệt, khác với AMD SEV:
- Local SSD chỉ khả dụng qua biến thể
c3-standard-*-lssd: không giống các cấu hình AMD Confidential VM nói chung (vốn chỉ hỗ trợ ephemeral storage trên Local SSD, không phải Local SSD thông thường), với TDX bạn phải chọn đúng biến thể machine type có hậu tố-lssdngay từ đầu để có Local SSD — không thể thêm sau. - Thời gian tắt máy (shutdown) lâu hơn đáng kể so với VM tiêu chuẩn: tài liệu ghi nhận "VM instances take longer to shut down compared to standard VM instances" — hệ quả trực tiếp từ việc TDX Module phải thực hiện quy trình teardown TD một cách có kiểm soát (xóa sạch khóa mã hóa, giải phóng tài nguyên SEAM) trước khi hoàn tất việc dừng VM, khác với việc chỉ đơn giản deallocate bộ nhớ như VM thường.
- Không tương thích với sole-tenant node: bạn không thể yêu cầu một TD chạy độc quyền trên một node vật lý cụ thể mà bạn kiểm soát placement — ràng buộc này áp dụng chung cho toàn bộ Confidential Computing trên GCP (không riêng TDX), sẽ được phân tích thêm ở file 04 trong bối cảnh GKE.
- Không hỗ trợ
kdump: công cụ debug kernel crash dump tiêu chuẩn của Linux không hoạt động được trên TD, vì kdump đòi hỏi khả năng truy cập trực tiếp vào vùng bộ nhớ kernel đã crash theo cách mà mô hình cách ly của TDX không cho phép thực hiện một cách an toàn từ bên ngoài TD. - Không hỗ trợ reservation cũng như tạo cluster cho multi-node workload: theo tài liệu, "Confidential VM instances with Intel TDX don't support reservations and don't support the creation of clusters for multi-node workloads" — một ràng buộc capacity planning quan trọng cần lưu ý khi thiết kế node pool GKE cho production cần đảm bảo capacity trước.
Khả Năng Đặc Thù: Confidential GPU Kết Hợp Với TDX
Một điểm mở rộng quan trọng của Intel TDX trên GCP là khả năng kết hợp bảo vệ CPU với NVIDIA Confidential Computing cho GPU — hiện khả dụng trên instance A3 High với NVIDIA H100. Cơ chế này mở rộng mô hình TEE ra khỏi ranh giới CPU: dữ liệu được truyền từ CPU (được bảo vệ bởi TDX) sang GPU qua kênh PCIe cũng được mã hóa, và bản thân GPU H100 khi ở chế độ Confidential Computing cũng thực hiện mã hóa bộ nhớ VRAM/framebuffer của chính nó, độc lập khỏi driver host. Đây là yêu cầu bắt buộc cho các workload AI/ML "agentic" xử lý dữ liệu nhạy cảm end-to-end — theo tài liệu: "CPU Protection: Intel TDX; GPU Protection: NVIDIA Confidential Computing; End-to-End: Both must run in confidential mode for agentic AI use cases" (From clicks to clusters). Điều quan trọng cần nhấn mạnh: chỉ bật TDX cho CPU mà không bật Confidential Computing cho GPU sẽ để lộ khoảng trống bảo mật — dữ liệu vẫn ở dạng plaintext trong VRAM của GPU trong quá trình tính toán, phủ nhận một phần giá trị bảo vệ của TDX ở tầng CPU. Attestation GPU trong trường hợp này đi qua một luồng riêng: driver attestation (yêu cầu Secure Boot) kết hợp với NVIDIA GPU device attestation qua thư viện nvtrust, có thể verify cục bộ hoặc qua NVIDIA Remote Attestation Service từ xa.
Xác Thực Bên Thứ Ba Độc Lập: Intel Tiber Trust Authority
Một khác biệt đáng chú ý giữa hệ sinh thái TDX và AMD SEV trên GCP là sự tồn tại của một verifier bên thứ ba độc lập với Google: Intel Tiber Trust Authority. Thay vì chỉ tin tưởng Google Cloud Attestation (verifier do chính nhà cung cấp cloud vận hành), tổ chức có yêu cầu compliance nghiêm ngặt (tách biệt trách nhiệm — separation of duties) có thể chọn dùng Intel Tiber Trust Authority làm verifier độc lập để xác minh attestation report từ TDX Module, giảm mức độ tin tưởng đặt vào riêng một bên duy nhất. Đây là một lựa chọn kiến trúc quan trọng cho các ngành có yêu cầu kiểm toán cao — verifier hiện có tier miễn phí khả dụng cho mọi khách hàng (From clicks to clusters). AMD SEV/SEV-SNP hiện không có một lựa chọn verifier độc lập tương đương công khai rộng rãi trên GCP ở cùng mức độ — Google Cloud Attestation gần như là verifier mặc định duy nhất.
Bảng Tổng Hợp So Sánh AMD SEV-SNP Và Intel TDX
| Tiêu chí | AMD SEV-SNP | Intel TDX |
|---|---|---|
| Cơ chế cách ly | Mở rộng tiệm tiến trên AMD-V, RMP kiểm soát quyền sở hữu trang | Chế độ CPU mới (SEAM), TDX Module trung gian bắt buộc |
| Nơi lưu measurement | Kết hợp AMD-SP (early boot) + vTPM (boot muộn) | Hoàn toàn trong TDX Module (MRTD + RTMR) |
| Loại attestation | Phần cứng + phần mềm kết hợp | Phần cứng thuần túy |
| Machine series GCP | N2D (Milan) | c3-standard-*, A3 High |
| Live migration | Không (kể cả trên N2D) | Không |
| Verifier bên thứ ba | Chưa có lựa chọn công khai tương đương | Intel Tiber Trust Authority (miễn phí tier) |
| Chống replay/remap bộ nhớ | Có (qua RMP) | Có (qua mô hình sở hữu trang riêng của SEAM) |
| GPU confidential đi kèm | Không đề cập trong tài liệu hiện tại | NVIDIA H100 trên A3 High |
SEAM Mode Trong Bối Cảnh Đặc Quyền CPU Truyền Thống
Để hình dung rõ hơn vị trí của SEAM trong kiến trúc đặc quyền CPU, cần đặt nó cạnh mô hình ring truyền thống mà hầu hết kỹ sư backend đã quen thuộc: ring 0 (kernel), ring 3 (user-space ứng dụng), và với ảo hóa truyền thống là VMX root mode (hypervisor, tương đương "ring -1") và VMX non-root mode (nơi guest OS/ứng dụng chạy, dù bên trong guest vẫn có ring 0/ring 3 riêng). SEAM chèn thêm một mức đặc quyền mới song song, không nằm trên trục ring 0-3 quen thuộc — nó không phải "ring -2" theo nghĩa cao hơn VMX root mode trong một trật tự phân cấp tuyến tính, mà là một mặt phẳng thực thi tách biệt (separate execution plane) được CPU đảm bảo rằng ngay cả mã chạy ở VMX root mode (hypervisor) cũng không thể đọc/ghi trực tiếp vào bộ nhớ của SEAM.
Điều này khác về bản chất so với mô hình của AMD, nơi AMD-SP là một bộ xử lý vật lý hoàn toàn tách biệt (một lõi ARM riêng biệt nằm cạnh các lõi x86, không chia sẻ pipeline thực thi) — còn TDX Module lại chạy trên chính lõi x86 chính, chỉ khác ở chế độ hoạt động (SEAM thay vì VMX root/non-root). Sự khác biệt này có một hệ quả thực tế về hiệu năng: vì TDX Module thực thi trên cùng lõi vật lý với cả hypervisor và guest (chỉ chuyển đổi ngữ cảnh giữa các chế độ), chi phí chuyển đổi vào/ra SEAM (SEAMCALL, tương đương VMEXIT/VMENTER mở rộng) là một chi phí CPU cycle thực sự trên cùng lõi, trong khi với AMD, một phần công việc xác minh có thể diễn ra "song song" trên AMD-SP mà không tranh chấp chu kỳ xử lý với lõi x86 chính đang chạy guest/hypervisor.
Chuỗi Xác Thực Chứng Chỉ: Quote Verification Với DCAP
Việc TDX Module ký số attestation report không tự nó đủ để verifier tin tưởng — verifier còn cần xác nhận rằng khóa ký số đó thực sự thuộc về một CPU Intel chính hãng, chưa bị thu hồi (revoke). Cơ chế này dựa trên Intel DCAP (Data Center Attestation Primitives), một hạ tầng chứng chỉ phân cấp (certificate chain) bắt nguồn từ Intel Provisioning Certification Service: mỗi CPU vật lý có một khóa chứng thực riêng (Attestation Key) được cấp chứng chỉ bởi Intel, và attestation report (gọi là "quote" trong thuật ngữ DCAP) được ký bằng khóa này. Verifier (Google Cloud Attestation hoặc Intel Trust Authority) xác minh chuỗi chứng chỉ này ngược lên tới Intel root CA, đồng thời kiểm tra danh sách thu hồi chứng chỉ (Certificate Revocation List) để đảm bảo CPU đó chưa bị Intel đánh dấu là có lỗ hổng đã biết. Đây là lý do vì sao attestation của TDX được mô tả là "hardware attestation thuần túy" — toàn bộ chuỗi tin cậy, từ khóa ký tới việc xác minh khóa đó có hợp lệ hay không, đều bắt nguồn từ phần cứng và hạ tầng PKI do chính Intel vận hành, không phụ thuộc vào một vTPM phần mềm trung gian nào của Google.
Mental Model Tổng Kết
Đứng từ góc độ platform engineer, sự khác biệt giữa AMD SEV-SNP và Intel TDX không chỉ là "hai nhà cung cấp khác nhau của cùng một tính năng" — chúng phản ánh hai triết lý kiến trúc CPU khác nhau để đạt cùng mục tiêu isolation/encryption/attestation. Điều này có hệ quả thực tế: khi bạn cần chọn công nghệ cho một node pool Confidential GKE Nodes, quyết định không chỉ dừng ở "muốn bảo mật cao hơn thì chọn cái mới hơn" — nó phụ thuộc vào máy chủ nào khả dụng ở khu vực bạn cần, ràng buộc storage/networking đi kèm, có cần live migration hay không, và liệu bạn có cần verifier độc lập với Google hay không. Phần tiếp theo sẽ đưa toàn bộ kiến thức phần cứng này vào bối cảnh cụ thể: cách GKE expose ba công nghệ này qua ba cấp độ cấu hình — cluster, node pool, và workload.