Truy xuất báo cáo AMD SEV bằng Zig: Bảo vệ máy ảo trước hypervisor độc hại

Trong một máy ảo (VM) thông thường, hypervisor có thể đọc toàn bộ bộ nhớ của khách. AMD SEV (Secure Encrypted Virtualization) mã hóa vùng nhớ đó bằng khóa riêng cho từng VM mà hypervisor không hề nắm giữ. SEV-ES mở rộng bảo vệ sang trạng thái thanh ghi CPU đã lưu, còn SEV-SNP (Secure Nested Paging) bổ sung kiểm tra quyền sở hữu và ánh xạ bộ nhớ, ngăn hypervisor độc hại thay thế hoặc ánh xạ lại các trang riêng tư.

Cơ chế này bảo vệ khách khỏi chủ nhà, nhưng không đảm bảo phần mềm bên trong khách đáng tin cậy, cũng không ngăn chủ nhà dừng VM. SNP cho phép khách yêu cầu một báo cáo (report) được ký bởi bộ xử lý bảo mật AMD, cung cấp bằng chứng về trạng thái khởi động và cấu hình của VM. Báo cáo chứa số đo khởi động (launch measurement), chính sách khách, phiên bản bảo mật nền tảng và 64 byte REPORT_DATA do bên gọi cung cấp.

Cách thức hoạt động của chứng thực SNP

Trước khi VM khởi động, chủ nhà nạp phần mềm khởi đầu vào bộ nhớ, bao gồm firmware khởi động của khách. Trên Google Cloud, đó là firmware UEFI do Google quản lý, dựa trên OVMF (Open Virtual Machine Firmware). Phần mềm khởi đầu cũng có thể bao gồm Coconut SVSM, một chương trình riêng cung cấp các dịch vụ như TPM ảo.

Firmware SNP của AMD chạy trên bộ xử lý bảo mật. Chủ nhà bắt đầu quá trình khởi động bằng lệnh SNP_LAUNCH_START, sau đó cung cấp ảnh khởi đầu theo từng phần gọi là memory page thông qua SNP_LAUNCH_UPDATE. Với mỗi trang mã hoặc dữ liệu thông thường, firmware băm các byte được cài đặt, địa chỉ bộ nhớ khách, loại trang và quyền, cùng với giá trị băm trước đó. AMD duy trì giá trị băm chạy này trong trạng thái được bảo vệ mà chủ nhà không thể thay thế.

SNP_LAUNCH_FINISH kết thúc quá trình khởi động. Giá trị băm SHA-384 cuối cùng chính là số đo khởi động — dấu vân tay của ảnh khởi đầu, bao gồm cả SVSM nếu có. Khi thực hiện chứng thực từ xa (remote attestation), bên xác minh so sánh giá trị này với dấu vân tay mong đợi của phần mềm và cấu hình mà họ tin tưởng. Google công bố các chứng thực khởi động đã ký chứa số đo mong đợi cho firmware của mình.

Thay đổi byte firmware sẽ thay đổi dấu vân tay. Đánh dấu các trang là không được đo sẽ bỏ qua việc băm nội dung nhưng thay đổi loại trang trong hash. Dù cách nào, kết quả cũng khác dấu vân tay mong đợi, nên bên xác minh có thể từ chối chứng thực.

Điều quan trọng cần lưu ý: nhân và ứng dụng mà firmware nạp sau đó không tự động nằm trong dấu vân tay này.

Truy xuất báo cáo trên Linux

Linux công khai giao diện khách SNP tại /dev/sev-guest. Ứng dụng gửi ioctl SNP_GET_REPORT, driver xử lý trao đổi được bảo vệ với firmware SNP của AMD. Ngoài dữ liệu báo cáo, yêu cầu cung cấp VMPL (VM Privilege Level) từ 0 đến 3, trong đó 0 có đặc quyền cao nhất.

Các cấp độ này quan trọng vì Linux không phải lúc nào cũng là phần mềm có đặc quyền cao nhất trong VM. Coconut SVSM có thể dùng sự tách biệt đó để vận hành TPM ảo với khóa cách ly khỏi nhân khách. Trở thành root trong Linux không đưa bạn lên VMPL0 — hãy dùng VMPL mà khách của bạn hỗ trợ.

Đoạn mã Zig dưới đây minh họa yêu cầu gửi tới /dev/sev-guest:

const SNP_GET_REPORT = 0xc0205300;
const result = linux.ioctl(fd, SNP_GET_REPORT, @intFromPtr(&call));

Bạn truyền một challenge 64 byte mới từ bên xác minh và VMPL của khách. Challenge sẽ quay lại trong REPORT_DATA, giúp bên xác minh từ chối báo cáo cũ. Kết quả là báo cáo thô; chữ ký và chính sách vẫn cần được kiểm tra riêng.

Tác giả bài viết đã đóng gói việc truy xuất, phân tích và xác minh báo cáo trong thư viện zig-sev-guest, để người gọi không phải làm việc trực tiếp với các buffer này.

Truy xuất qua Coconut SVSM và OpenHCL

Coconut SVSM và OpenHCL của Microsoft có thiết kế khác nhau nhưng đều chạy các dịch vụ đặc quyền như vTPM bên trong VM bảo mật. Trên SNP, phần cứng AMD mã hóa vùng nhớ đó — bao gồm khóa riêng của TPM — bằng khóa riêng cho từng VM do bộ xử lý bảo mật quản lý.

Nhân khách chạy ở VMPL ít đặc quyền hơn SVSM hoặc OpenHCL. Quyền truy cập trang của SNP ngăn nó đọc các trang chứa khóa riêng của vTPM. Khách có thể yêu cầu AMD ký báo cáo chứa hash của bất kỳ khóa công khai nào, nhưng điều đó không chứng minh khóa thuộc vTPM được bảo vệ. SVSM và OpenHCL xây dựng yêu cầu bằng khóa công khai của TPM mà chúng vận hành, nên ứng dụng nhận báo cáo thông qua chúng.

Có ba đường dẫn yêu cầu — /dev/sev-guest, configfs Linux và giao diện vTPM — tất cả đều dựa trên firmware SNP.

Kiểm tra bằng chứng

Trong zig-sev-guest, tác giả dùng OpenSSL để xác minh chuỗi chứng chỉ ký dựa trên gốc AMD nhúng sẵn, đồng thời kiểm tra chữ ký ECDSA P-384 của báo cáo. Phiên bản bảo mật của chứng chỉ và danh tính chip (nếu có) cũng phải khớp với báo cáo.

Bước xác thực chính sách sau đó so sánh báo cáo với số đo khởi động mong đợi, REPORT_DATA, VMPL và phiên bản bảo mật nền tảng tối thiểu. Các chế độ gỡ lỗi (debugging), SMT và di chuyển (migration) sẽ bị từ chối trừ khi được cho phép rõ ràng. Hàm verify.andValidate thực hiện cả hai bước trên cùng một báo cáo; bên gọi cung cấp các giá trị mong đợi, bao gồm challenge mới, và kiểm tra riêng các tuyên bố đặc thù của vTPM.

Ý nghĩa với người dùng Việt Nam

Với các doanh nghiệp Việt Nam đang chuyển dịch lên đám mây — đặc biệt trong lĩnh vực tài chính, ngân hàng và y tế, nơi yêu cầu tuân thủ dữ liệu rất khắt khe — điện toán bảo mật (confidential computing) như AMD SEV-SNP mở ra khả năng chạy khối lượng công việc nhạy cảm trên hạ tầng công cộng mà vẫn giữ được sự riêng tư ngay cả với nhà cung cấp đám mây.

Việc hiểu và triển khai đúng quy trình chứng thực từ xa là điều kiện tiên quyết để tận dụng công nghệ này một cách an toàn. Các thư viện như zig-sev-guest giúp giảm rào cản kỹ thuật, cho phép đội ngũ phát triển tập trung vào logic nghiệp vụ thay vì vật lộn với các buffer cấp thấp của firmware.