AMD SEV / SEV-ES / SEV-SNP — Cơ Chế Mã Hóa Bộ Nhớ
Vị Trí Của AMD Secure Processor Trong Kiến Trúc CPU
Để hiểu SEV, phải bắt đầu từ một thành phần vật lý nằm ngay trong die của CPU AMD EPYC: AMD Secure Processor (AMD-SP), một lõi ARM Cortex-A5 độc lập nhúng bên trong chip, chạy firmware riêng, tách biệt hoàn toàn khỏi các nhân x86 chính nơi hypervisor và guest OS thực thi. AMD-SP không phải một khái niệm trừu tượng hay một thành phần phần mềm — nó là một bộ vi xử lý vật lý thứ hai, độc lập, có vùng bộ nhớ riêng, và đóng vai trò root of trust cho toàn bộ cơ chế SEV. Theo tài liệu GKE chính thức, per-node instance key "is generated and managed by the AMD Secure Processors, which is embedded in the AMD EPYC processor... These keys are generated by the AMD Secure Processor during node creation and reside solely within it, making them unavailable to Google or any VMs running on the host" (Confidential GKE Nodes documentation).
Điểm mấu chốt cần khắc sâu: khóa mã hóa không bao giờ rời khỏi AMD-SP. Không có API, không có lệnh CPU, không có kênh debug nào cho phép hypervisor hay bất kỳ phần mềm nào trên nhân x86 chính đọc được giá trị khóa này. Đây là khác biệt căn bản so với mọi mô hình mã hóa dựa trên phần mềm — khóa không "được bảo vệ tốt", nó không tồn tại ở bất kỳ đâu ngoài AMD-SP để có thể bị đánh cắp.
SEV Thế Hệ Gốc: ASID-Bound Encryption Và C-bit
Address Space Identifier (ASID) làm đơn vị cách ly khóa
Mỗi guest VM khi khởi động dưới SEV được gán một Address Space Identifier (ASID) duy nhất bởi hypervisor thông qua lệnh CPU mở rộng (SEV API). AMD-SP sau đó sinh ra một khóa AES-128 ngẫu nhiên, ràng buộc riêng với ASID đó, và nạp nó vào memory controller. Từ thời điểm này, mọi giao dịch đọc/ghi bộ nhớ vật lý gắn với ASID đó đều tự động được memory controller mã hóa/giải mã bằng khóa tương ứng, hoàn toàn trong suốt với guest OS. Vì mỗi VM có một ASID và một khóa riêng biệt, hai VM khác nhau trên cùng một host vật lý không thể đọc được dữ liệu của nhau ngay cả khi chúng chia sẻ cùng vùng RAM vật lý theo thời gian (do multiplexing) — nội dung mà VM B đọc từ một trang bộ nhớ trước đó thuộc VM A sẽ chỉ là dữ liệu đã mã hóa bằng khóa của A, vô nghĩa nếu giải mã bằng khóa của B.
C-bit: cờ đánh dấu ở tầng bit địa chỉ vật lý
Cơ chế kỹ thuật cho phép CPU biết trang bộ nhớ nào cần mã hóa là C-bit (Confidentiality bit hay Encryption bit) — một bit bổ sung trong không gian địa chỉ vật lý (physical address space) mà AMD dành riêng cho mục đích này. Khi guest OS ánh xạ một trang bộ nhớ với C-bit được set, memory controller tự động áp dụng mã hóa AES cho trang đó khi ghi xuống DRAM vật lý, và giải mã khi CPU đọc nó vào cache. Cơ chế C-bit hoạt động ở tầng thấp hơn cả page table thông thường của x86 — nó là một phần mở rộng của cơ chế địa chỉ hóa vật lý, nghĩa là việc bật/tắt mã hóa cho một trang bộ nhớ không đòi hỏi thay đổi logic ứng dụng hay driver, chỉ cần guest OS (kernel) được biên dịch/patch để nhận biết và set C-bit đúng cách khi ánh xạ bộ nhớ private.
Giới hạn cố hữu của SEV gốc: không bảo vệ thanh ghi CPU
SEV thế hệ đầu tiên chỉ mã hóa nội dung bộ nhớ, nhưng không mã hóa trạng thái thanh ghi CPU (register state) khi VM bị trap ra ngoài (VMEXIT) — ví dụ khi xảy ra một I/O instruction, một page fault, hay bất kỳ sự kiện nào buộc CPU chuyển quyền điều khiển về hypervisor. Tại thời điểm VMEXIT, giá trị các thanh ghi (bao gồm cả những gì có thể chứa dữ liệu nhạy cảm đang được xử lý dở, hoặc thậm chí một phần khóa mật mã đang nằm trong thanh ghi) được lưu vào một cấu trúc gọi là VMCB (Virtual Machine Control Block) mà hypervisor có toàn quyền đọc. Đây là một lỗ hổng threat model nghiêm trọng: một hypervisor độc hại có thể chủ động kích hoạt VMEXIT liên tục (ví dụ cưỡng ép page fault) để "trích xuất" dần trạng thái thanh ghi của guest, dù bộ nhớ chính đã được mã hóa.
SEV-ES: Bảo Vệ Trạng Thái Thanh Ghi Khi VMEXIT
SEV-ES (Encrypted State) ra đời để đóng lỗ hổng nói trên. Cơ chế bổ sung một cấu trúc mới gọi là VMSA (Virtual Machine Save Area), nơi trạng thái thanh ghi CPU được mã hóa và toàn vẹn-bảo vệ trước khi VMEXIT lưu nó lại, thay vì lưu plaintext vào VMCB như trước. Khi VMEXIT xảy ra, chỉ những thông tin tối thiểu cần thiết để hypervisor xử lý sự kiện (ví dụ mã lỗi exit reason) mới được để lộ ở dạng plaintext; toàn bộ ngữ cảnh thanh ghi còn lại vẫn nằm trong VMSA đã mã hóa. Điều này buộc hypervisor phải giao tiếp với guest thông qua một giao thức trung gian chặt chẽ hơn (ghcb — Guest-Host Communication Block) thay vì đọc trực tiếp thanh ghi như trước.
Hệ quả kỹ thuật quan trọng: SEV-ES thay đổi cách hypervisor xử lý một số thao tác I/O nhạy cảm về hiệu năng (như cấu hình interrupt, một số MSR access), khiến chi phí VMEXIT tăng nhẹ so với VM thường — đây là một phần lý do overhead của Confidential VM không đồng đều giữa các loại workload, được phân tích kỹ ở file 06.
SEV-SNP: Chống Lại Chính Hypervisor Chủ Động Tấn Công
SEV và SEV-ES giải quyết bài toán confidentiality (bảo mật, chống đọc trộm) nhưng vẫn để lộ một lớp tấn công khác: integrity (toàn vẹn). Một hypervisor độc hại, dù không đọc được nội dung bộ nhớ đã mã hóa, vẫn có toàn quyền kiểm soát bảng ánh xạ địa chỉ vật lý (nested page table) — nghĩa là nó có thể:
- Data replay attack: ghi đè một trang bộ nhớ mã hóa hiện tại bằng nội dung mã hóa của chính trang đó tại một thời điểm cũ hơn đã lưu lại từ trước, khiến guest OS "nhìn thấy" dữ liệu cũ mà không biết.
- Memory remapping attack: ánh xạ lại (remap) địa chỉ vật lý sao cho guest ghi vào một trang nhưng dữ liệu thực tế lại đi tới một vị trí khác do hypervisor kiểm soát, hoặc hoán đổi nội dung giữa các trang bộ nhớ của cùng một VM để đánh lừa logic ứng dụng.
- Memory aliasing: tạo ra nhiều ánh xạ trỏ tới cùng một trang vật lý theo cách guest không kiểm soát được, phá vỡ giả định cách ly bộ nhớ.
AMD SEV-SNP (Secure Nested Paging) giải quyết toàn bộ lớp tấn công này bằng một cấu trúc dữ liệu mới do phần cứng quản lý: Reverse Map Table (RMP). Khác với page table thông thường (ánh xạ từ địa chỉ ảo sang địa chỉ vật lý, do guest/hypervisor kiểm soát), RMP là bảng ánh xạ ngược — với mỗi trang bộ nhớ vật lý, RMP ghi lại trang đó hiện đang thuộc sở hữu hợp lệ của guest/ASID nào, và trạng thái của nó (validated hay chưa). RMP được lưu ở một vùng bộ nhớ chỉ AMD-SP và phần cứng quản lý được, hypervisor không thể ghi trực tiếp — mọi thay đổi quyền sở hữu trang bộ nhớ phải đi qua các lệnh CPU được kiểm soát chặt (PVALIDATE, RMPUPDATE), và guest OS tự xác thực (self-validate) trạng thái trang bộ nhớ của mình thông qua lệnh PVALIDATE trước khi tin tưởng nội dung đó.
Theo Google Cloud, "SEV-SNP incorporates hardware-based security to help prevent malicious hypervisor-based attacks like data replay and memory remapping. A key distinction: attestation reports can be generated on-demand directly from the AMD Secure Processor" (Confidential VM overview). Khả năng sinh attestation report theo yêu cầu (on-demand) trực tiếp từ AMD-SP — thay vì phải đi qua vTPM phần mềm như SEV gốc — là một cải tiến quan trọng về độ tin cậy của quy trình attestation, được trình bày kỹ ở file 05.
Bảng So Sánh Ba Thế Hệ SEV: Lớp Tấn Công Nào Bị Chặn Ở Đâu
| Thế hệ | Bảo vệ bộ nhớ chính | Bảo vệ thanh ghi CPU khi VMEXIT | Chống replay/remap bộ nhớ | Nguồn gốc attestation |
|---|---|---|---|---|
| SEV | Có (C-bit + ASID key) | Không | Không | vTPM phần mềm (đo lường boot) |
| SEV-ES | Có | Có (VMSA mã hóa) | Không | vTPM phần mềm |
| SEV-SNP | Có | Có | Có (RMP) | AMD Secure Processor (on-demand) |
Điểm quan trọng cần rút ra: mỗi thế hệ không thay thế thế hệ trước về mặt tính năng cơ bản — chúng bổ sung dần từng lớp phòng thủ. SEV-SNP kế thừa toàn bộ cơ chế mã hóa C-bit/ASID của SEV gốc và VMSA của SEV-ES, đồng thời thêm RMP để giải quyết integrity. Đây là lý do trên GKE, SEV-SNP luôn được coi là lựa chọn an toàn hơn SEV thuần khi machine type hỗ trợ (hiện tại chỉ N2D với CPU Milan hỗ trợ SEV-SNP theo cấu hình được liệt kê ở file 04).
Vì Sao Google Vẫn Cần vTPM Dù Đã Có AMD-SP
Một câu hỏi hợp lý: nếu AMD-SP đã là root of trust phần cứng, tại sao Google Cloud vẫn dùng vTPM (Virtual Trusted Platform Module) trong quy trình attestation của SEV/SEV-ES? Câu trả lời nằm ở sự phân công vai trò: AMD-SP chịu trách nhiệm cho phần mã hóa bộ nhớ và sinh khóa — đây là chức năng lõi của silicon. Nhưng việc đo lường (measure) trạng thái boot của guest OS — bootloader nào đã chạy, kernel nào đã load, initrd checksum ra sao — theo thiết kế của SEV gốc và SEV-ES lại được giao cho một vTPM ảo hóa do Google quản lý, chạy dưới dạng firmware ảo bên trong VM, tự đo chính nó và lưu kết quả vào Platform Configuration Registers (PCR) theo chuẩn TPM 2.0 quen thuộc từ Shielded VM.
Tài liệu chính thức phân loại rõ: với AMD SEV, cơ chế attestation được mô tả là "software attestation" — "phần mềm xác minh, firmware ảo đo chính nó, phép đo được lưu trong vTPM"; còn với SEV-SNP là "xác minh phần cứng và phần mềm kết hợp" — "các phép đo khởi động từ Bộ xử lý Secure của AMD, phép đo khởi động sau được lưu trong vTPM" (Remote attestation overview). Nói cách khác: SEV-SNP nâng cấp phần early boot measurement (đo lường giai đoạn khởi động sớm — firmware, bootloader) lên cho AMD-SP tự thực hiện bằng hardware root of trust, nhưng vẫn giữ vTPM để đo các giai đoạn boot muộn hơn (kernel, initrd) — một mô hình lai giữa phần cứng và phần mềm.
Máy Chủ AMD EPYC Nào Trên GCP Hỗ Trợ Công Nghệ Nào
Không phải mọi machine series AMD trên GCP đều hỗ trợ mọi thế hệ SEV — điều này phụ thuộc trực tiếp vào thế hệ vi kiến trúc AMD EPYC làm nền. Theo tài liệu supported configurations:
| Machine series | CPU platform | Công nghệ hỗ trợ | Live Migration |
|---|---|---|---|
| N2D | AMD EPYC Milan | SEV, SEV-SNP | Chỉ SEV (không SEV-SNP) |
| C2D | AMD EPYC Milan | SEV | Không |
| C3D | AMD EPYC Genoa | SEV | Có |
| C4D | AMD EPYC Turin | SEV | Không |
Quan sát quan trọng ở đây: chỉ N2D (thế hệ Milan) hỗ trợ SEV-SNP, dù các thế hệ CPU mới hơn như Genoa (C3D) hay Turin (C4D) đã tồn tại. Điều này phản ánh một thực tế vận hành thường bị bỏ qua: thế hệ CPU mới hơn không đồng nghĩa với việc hỗ trợ mọi tính năng bảo mật mới nhất ngay lập tức — việc bật một tính năng silicon-level như SEV-SNP đòi hỏi Google phải validate lại toàn bộ stack firmware/BIOS/microcode cho từng machine series, và quá trình này diễn ra độc lập với lộ trình ra mắt CPU mới. Khi thiết kế node pool cho Confidential GKE Nodes cần yêu cầu SEV-SNP cụ thể (ví dụ vì cần chống replay/remap attack), bạn buộc phải chọn N2D, chấp nhận đánh đổi hiệu năng CPU thế hệ cũ hơn so với C3D/C4D.
Giới Hạn Kỹ Thuật Riêng Của Từng Cấu Hình AMD SEV
Ngoài giới hạn về thế hệ công nghệ, mỗi machine series khi chạy ở chế độ confidential còn có các ràng buộc phần cứng bổ sung so với phiên bản non-confidential cùng loại:
- Giới hạn vNIC queue: trên C2D và N2D, số lượng hàng đợi vNIC tối đa bị giới hạn ở 8 khi Confidential VM được bật — thấp hơn đáng kể so với cấu hình non-confidential thông thường, ảnh hưởng trực tiếp tới khả năng scale throughput mạng cho workload nhiều luồng song song.
- Băng thông mạng giảm trên C3D/C4D: theo tài liệu, các instance C3D/C4D chạy Confidential VM có "lower network bandwidth than equivalent non-confidential VMs" — một trade-off hiệu năng cụ thể chứ không chỉ là con số overhead CPU trừu tượng.
- C3D không hỗ trợ Hyperdisk Balanced/Throughput: nếu kiến trúc storage của bạn phụ thuộc vào các loại Hyperdisk này (xem Chương 11), việc chọn C3D làm nền cho Confidential GKE Nodes sẽ buộc phải điều chỉnh lại thiết kế storage.
- SEV-SNP không hỗ trợ reservation: không thể dùng Compute Engine reservation để đảm bảo capacity cho node pool chạy SEV-SNP — một ràng buộc quan trọng cần tính tới khi lập kế hoạch capacity cho production tại các khu vực có nhu cầu cao.
- Debian 12 không hỗ trợ attestation với SEV-SNP: dù VM vẫn chạy được về mặt chức năng, hệ điều hành guest cụ thể này thiếu hỗ trợ để tạo ra attestation report hợp lệ cho SEV-SNP — nếu attestation là yêu cầu bắt buộc trong kiến trúc của bạn (gần như luôn đúng trong production nghiêm túc), cần chọn hệ điều hành khác (ví dụ Container-Optimized OS, vốn là lựa chọn mặc định và được kiểm định kỹ nhất trên GKE).
Vòng Đời Khóa Gắn Với Vòng Đời Node: Hệ Quả Cho Auto-Repair Và Node Replacement
Một hệ quả vận hành quan trọng, thường bị bỏ sót khi thiết kế node pool Confidential trên GKE, xuất phát trực tiếp từ nguyên lý "khóa sinh tại thời điểm khởi tạo VM, ràng buộc với ASID của phiên làm việc đó": mỗi khi một node bị thay thế — dù do auto-repair phát hiện node unhealthy, do node pool upgrade, hay do scale-down/scale-up của Cluster Autoscaler — AMD Secure Processor sẽ sinh ra một khóa hoàn toàn mới cho VM mới, không có bất kỳ mối liên hệ nào với khóa của node cũ. Cơ chế node bootstrap và auto-repair đã trình bày ở Chương 6 áp dụng nguyên vẹn cho Confidential GKE Nodes, nhưng với một lớp ý nghĩa bảo mật bổ sung: không có khái niệm "khôi phục khóa của node cũ" — về mặt thiết kế, đây là hành vi đúng đắn (một node mới hoàn toàn nên có danh tính mã hóa hoàn toàn mới, không kế thừa trạng thái tin cậy từ node trước), nhưng nó có nghĩa là bất kỳ trạng thái nào phụ thuộc vào việc "khóa ổn định qua thời gian" (ví dụ nếu bạn từng cân nhắc dùng khóa mã hóa bộ nhớ này cho một mục đích ngoài phạm vi thiết kế, như một dạng identity lâu dài) đều sai về nguyên lý — khóa này chỉ có ý nghĩa trong phạm vi vòng đời của một phiên VM cụ thể, không phải một định danh bền vững.
Điều này cũng lý giải vì sao attestation report luôn cần được lấy theo từng phiên boot cụ thể (launch attestation report sinh ra tại mỗi lần khởi động, như đã đề cập ở trên) thay vì cache lại một attestation report cũ và tái sử dụng cho các lần sau — vì bản chất khóa và trạng thái đo lường đã hoàn toàn khác sau mỗi lần node được tạo lại.
Tại Sao AMD Chọn Kiến Trúc Mở Rộng Tiệm Tiến Thay Vì Redesign Toàn Bộ
Nhìn xa hơn chi tiết kỹ thuật, cách AMD tiến hóa SEV qua ba thế hệ phản ánh một ràng buộc thực dụng của ngành công nghiệp bán dẫn: tương thích ngược với kiến trúc ảo hóa AMD-V đã tồn tại từ lâu. Việc xây dựng SEV như một tập lệnh mở rộng của AMD-V (thay vì một chế độ CPU hoàn toàn tách biệt như SEAM của Intel) cho phép AMD triển khai công nghệ này nhanh hơn trên nhiều thế hệ CPU liên tiếp, đồng thời giảm thiểu rủi ro tương thích với hypervisor hiện có (KVM chỉ cần mở rộng logic quản lý VM hiện tại, không cần viết lại toàn bộ tầng quản lý VM). Đánh đổi của cách tiếp cận này là: mỗi lớp bảo vệ bổ sung (ES, rồi SNP) phải được thiết kế cẩn thận để không phá vỡ các giả định kiến trúc của lớp trước, dẫn tới việc một số giới hạn của thế hệ đầu (như việc chỉ N2D hỗ trợ SEV-SNP dù các CPU mới hơn đã ra mắt) tồn tại lâu hơn kỳ vọng — vì việc validate lại toàn bộ chuỗi tương thích (firmware, BIOS, microcode, hypervisor) cho một thế hệ CPU mới là một khối lượng công việc kỹ thuật đáng kể, độc lập với việc bản thân CPU đó có hỗ trợ SEV-SNP về mặt silicon hay không.
Mental Model Tổng Kết Trước Khi Sang Intel TDX
AMD SEV là một họ công nghệ tiến hóa theo hướng bổ sung dần từng lớp phòng thủ trên cùng một nền tảng kiến trúc gốc (ASID-bound key, C-bit): từ chỉ mã hóa bộ nhớ (SEV), tới bảo vệ cả trạng thái thanh ghi (SEV-ES), tới chống cả tấn công chủ động vào tính toàn vẹn bộ nhớ từ chính hypervisor (SEV-SNP). Cách tiếp cận này khác về bản chất kiến trúc so với Intel TDX — nơi Intel không mở rộng dần một cơ chế cũ, mà xây một chế độ CPU hoàn toàn mới (SEAM) để chạy một module quản lý tách biệt độc lập với cả VMX root mode của hypervisor lẫn guest. Sự khác biệt triết lý thiết kế này — mở rộng tiệm tiến (AMD) so với tách lớp quản lý mới (Intel) — sẽ được làm rõ ở phần tiếp theo.