VPS 機密運算：AMD SEV-SNP 與 Intel TDX

VPS 上的機密運算實際代表什麼

VPS 上的機密運算，是指處理器使用 hypervisor 不持有的金鑰，將虛擬機器的記憶體加密。因此，實體機器的營運商無法讀取伺服器正在處理的資料。目前幾乎沒有 VPS 具備這項能力。在一般 VPS 上，供應商的 hypervisor 可以讀取 guest 記憶體中的每個位元組，而磁碟加密不會改變這一點。

已發布的指南是為兩類對象撰寫的，而 VPS 租用者不屬於其中任何一類。Canonical 的機密運算文件，不是教你在 hyperscaler 上啟動映像檔（例如特定的 Azure 規格或 Google Confidential VM），就是教你將自有硬體設定為機密 VM 主機。這兩種情境都假設你是 hyperscaler，或是主機的擁有者。這些文件都沒有告訴租用 4 GB VPS 的使用者，相關功能是否真的能在已付費使用的那台實體機器上運作。請先建立威脅模型，因為所有實際可行的答案都取決於此。

目前誰能讀取 VPS 的記憶體

您的 VPS 是一個 guest。其他元件負責建立它、提供記憶體，並將它排程到實體核心上。大多數 Linux VPS 託管服務都使用 KVM；在這種架構中，guest 的 RAM 是主機上 QEMU process 所擁有的一般 anonymous memory。主機上的 root 使用者可以用讀取其他 process 的相同方式讀取該 process 的記憶體，例如透過 /proc/<pid>/mem，或使用會將 guest 的完整記憶體映像寫入檔案的 virsh dump。您的 VM 內部沒有任何機制能阻止這項操作，也沒有任何機制能偵測這項操作，因為執行讀取的一方控制著負責偵測的那一層。

這不是某一家供應商的缺陷，而是 virtualisation 的本質。hypervisor 的工作就是管理 guest 的記憶體，因此能讀取該記憶體是這項設計自然帶來的結果。這也是為什麼 VPS 託管是否適合實際工作負載 取決於營運商的作業方式與人員存取控制，而不是取決於技術本身：技術本身完全無法限制營運商。以容器為基礎的方案，其隔離邊界更薄；LXC 或 OpenVZ guest 會共用主機 kernel，主機甚至不需要建立 dump，就能讀取您的 process。比較價格之前，應先了解這項差異；KVM、Xen 與 LXC virtualisation 的差異 正是這項差異所在。

為什麼完整磁碟加密無法解決這個問題

在 VPS 上啟用完整磁碟加密仍然值得，但它無法處理這個問題。LUKS（Linux unified key setup）會在區塊寫入磁碟前加密，讀回時解密。為了完成這項工作，只要磁碟區處於掛載狀態，磁碟區金鑰就必須一直留在 kernel memory 中。因此，金鑰在 memory 中，傳輸中的解密資料也在 memory 中，而 host 正好可以讀取 memory。

靜態資料加密確實能提供實際的保護：離開機房的磁碟仍然無法讀取。退回供應商的故障磁碟受到保護。有人忘記解除連接的備份磁碟區也受到保護。這些風險與 live host 讀取 live guest 不同，但都以同一個詞對外宣稱，因此「我們所有的儲存空間都已進行靜態加密」雖然是正確的說法，回答的卻是另一個問題。

租用機器時還有另一個特有的陷阱。加密 root filesystem 代表每次開機都必須由某個來源提供密碼片語。若將密碼片語儲存在同一台機器上，例如 keyfile 或未加密的 initramfs 中，host 就能讀取。若將密碼片語輸入由供應商操作的主控台，host 也能讀取。若在開機時從其他位置取得密碼片語，則只是轉移信任，並未消除信任，因為提供金鑰的服務現在必須確認提出要求的機器確實是你認定的那台機器。最後這項要求正是 attestation 要解決的問題。

AMD SEV-SNP 與 Intel TDX 實際上做了什麼

這是兩件不同的事。釐清兩者的界線，是理解整體機制的關鍵：記憶體加密，以及遠端驗證。

先看記憶體加密。AMD SEV-SNP（Secure Encrypted Virtualization with Secure Nested Paging）會為每個 guest 提供專屬的記憶體加密金鑰。金鑰儲存在 AMD Secure Processor 中。這是同一個晶片上的獨立核心，hypervisor 無法取得該金鑰。記憶體控制器只會針對擁有該記憶體的 guest，在寫入時加密、讀取時解密。host 仍可擷取該記憶體的傾印。取得的內容會是密文。

Intel TDX 則透過另一種方式達到相同結果。guest 會成為 trust domain，其記憶體會標記私有金鑰識別碼。所有進出轉換都由 TDX module 控制。這是一段經 Intel 簽署的程式碼，執行於 hypervisor 無法進入的處理器模式。從 tenant 的角度來看，結果相同：hypervisor 會配置你的記憶體並排程你的 CPU，但無法讀取你的記憶體。

SEV-SNP 中的 SNP 部分經常被忽略，但它才是關鍵。加密可阻止 host 讀取頁面，卻無法阻止 host 移動 頁面。能重新對映 guest 實體頁面的 hypervisor，可以重播舊內容、讓兩個 guest 位址指向同一頁面，或回傳它在你使用期間換出的頁面。這些行為都能在不解密任何內容的情況下，轉化為可實際利用的攻擊。SNP 加入 Reverse Map Table。這是 CPU 存取記憶體時會查詢的結構，用來記錄每個頁面由哪個 guest 擁有。若 guest 未要求重新對映，存取就會產生 fault，而不會成功。TDX 也有自己的等效機制。沒有這個完整性層時，你只有抵禦被動 host 的隱私保護，無法抵禦主動攻擊的 host。

兩者都不會改變的一點是：host 仍會啟動你的 VM、停止你的 VM、決定何時分配 CPU 核心給你的 VM，也可以直接刪除它。機密運算涵蓋機密性與完整性。可用性與效能仍完全由 host 控制，因此 吵雜鄰居造成的 CPU steal time 不會受到任何影響。

遠端證明能證明哪些單靠加密無法證明的事項

以下是單靠加密仍會留下的缺口。你向供應商要求機密 VM。對方提供一台 VM。你如何知道記憶體加密已啟用？你無法只詢問 guest 來確認，因為 guest 所看到的整個環境都由 hypervisor 提供，而 hypervisor 正是你要檢查的對象。不誠實的主機，或只是設定錯誤的主機，都能提供一台完全普通的 VM；你在其中執行的每個命令，都是由你不信任的那一層回應。

遠端證明能補上這個閉環。CPU 本身會產生帶有簽章的報告。在 SEV-SNP 上，報告由該實體晶片專屬的金鑰簽署，並由 AMD 自有的憑證鏈認證；你是從 AMD 取得這條鏈，而不是從供應商取得。TDX 會產生由 Intel 核發的證明金鑰支援的 quote。報告包含啟動測量值，也就是 VM 啟動時所用確切記憶體內容的雜湊，涵蓋 firmware、kernel、initrd 及 kernel command line。你可在該機器之外，依據晶片供應商的根憑證驗證簽章，再將測量值與預期的啟動內容比對。

直接說明它的價值。遠端證明能讓不在該機器上的一方，決定是否信任這台機器。真正實用的模式是依證明結果釋出機密：你的資料庫密碼與解密金鑰根本不會存放在映像檔中。它們由其他地方的服務保管，只有在該服務驗證最新報告並確認測量值符合預期後，才會交付。如果主機啟動了修改過的 kernel，或在完全沒有 SEV-SNP 的情況下執行 VM，測量值就會改變，或無法取得有效報告，因此永遠不會釋出機密。沒有遠端證明的加密，只能保護資料免受你已選擇信任的主機侵害。遠端證明讓你不必再做出這項信任選擇。

相關工具是開放的，你可以檢視其內容。snpguest命令列工具會與 AMD guest 內的 /dev/sev-guest裝置通訊、要求產生報告，並依據憑證鏈驗證報告。在這裡，平台細節很重要：在 Azure confidential VM 上，該裝置通常不會以相同方式提供給 guest，工具需要不同的 build 與不同的 flag。遠端證明確實可運作，但目前在各個平台上的運作方式仍不完全相同。

機密運算無法防護的事項

遭入侵的 guest。 SEV-SNP 可防護 VM 不受外部環境影響。但若攻擊者已在 VM 內部，SEV-SNP 就無法發揮作用，因為對 CPU 而言，該攻擊者就是你。未修補的 Web 應用程式，或逃逸容器並進入你自己的 kernel，在機密 VM 上一樣能成功。此時加密反而也在保護入侵者，因為 host 同樣無法檢查那段記憶體來協助你。遭入侵後復原 VPS 不會因為 RAM 已加密而變得更容易。

你自己的應用程式。 防護邊界止於 VM 邊界。程式寫入 log 檔案或傳送至第三方 API 的資料，已離開 TEE（trusted execution environment），也就是受保護的區域。加密記憶體不會稽核你的程式碼。

遭竊的憑證。 Attestation report 會說明哪些軟體已完成開機，但不會說明之後是誰登入。洩漏的 SSH key 能和開啟其他 VM 一樣快速地開啟機密 VM，因此對大多數讀者而言，強化 VPS 的 SSH 存取 仍是更值得投入的工作。

所有不是記憶體的項目。 SEV-SNP 和 TDX 會加密 RAM。除非你自行加密，否則 virtual disk、network traffic、snapshots 和 backups 都不在防護範圍內。在 hyperscaler 的機密 VM 產品中，OS disk 由獨立機制處理，並使用自己的 key management，正是因為 CPU 功能無法涵蓋它。

實體攻擊，這是最棘手的一項。 一系列已發表的研究顯示，memory bus 是防護邊界較脆弱的部分。BadRAM（CVE-2024-21944、2024）竄改記憶體模組上的 SPD chip，讓 CPU 將實體位址視為別名，所需零件約為十美元。Battering RAM（2025）在 CPU 與 DRAM 之間放置成本約五十美元的 interposer，並擊破後續加入的開機階段別名檢查。TEE.fail（2025）將這項概念延伸至 DDR5，並回報在目前的 Intel 和 AMD server hardware 上，能從 confidential computing 擷取 ciphertext。Deterministic memory encryption 也造成類似問題：相同位址上的相同 plaintext 會產生相同 ciphertext，學術研究已將這項特性本身轉化為 side channel。這些攻擊全部都需要實體存取機器，並能獨占機器一段時間。請注意，這描述的是誰。Confidential computing 將 host 從只需執行一個 command 就能讀取你的記憶體，提升到必須使用硬體、取得實體存取權並投入攻擊成本才能讀取。這是確實而且幅度很大的改善，但其主張小於「host 無法讀取」。

今天可以購買機密 VPS 嗎

截至 2026 年 8 月，機密 VM 是大型雲端服務商提供的產品線。Microsoft Azure 提供 SEV-SNP 規格與 TDX 規格。Google Cloud 提供 Confidential VM。AWS 則在少數執行個體系列的少數區域中，提供 AmdSevSnp CPU 選項。獨立 VPS 主機商很少列出這項功能。少數業者確實宣稱支援 SEV-SNP，但數量少到最穩妥的做法是直接詢問，不要自行假設。

原因來自平台架構。了解這些原因，有助於判讀對方的回覆。

• 硬體平台受限。SEV-SNP 需要第三代 AMD EPYC 或更新版本，TDX 則需要近期的 Intel Xeon Scalable。若主機群是多年來依每核心價格陸續採購而成，通常會是混合硬體。這項功能可能只存在於部分節點。
• 主機軟體版本較新。Ubuntu 自 24.04 LTS 起支援 SEV-SNP guest，但主機端的支援（包括 QEMU 與 OVMF 韌體支援）要到 25.04 才加入。這比穩定託管平台採用的軟體堆疊更新。
• 即時遷移會變得困難。將執行中的 guest 移至其他主機時，必須複製其記憶體，但主機無法讀取這些記憶體。服務商會利用即時遷移，將節點上的 guest 移出以進行維護。因此，失去這項能力會改變整個平台的運作方式。
• 佈署密度會下降。單一主機同時可執行的機密 guest 數量受硬體限制，遠低於大型節點可容納的一般 guest 數量。低價 VPS 仰賴的正是這種高密度。
• Attestation 會帶來持續的支援負擔。除非 tenant 能取得憑證鏈，並知道應預期哪個 measurement，否則 report 沒有實際價值。因此，服務商必須發布並維護相關資訊，而每次韌體更新都可能使資訊改變。

這些都不是對任何服務商的抱怨。這只是說明這項功能目前所處的位置。

如何詢問主機是否提供 SEV-SNP 或 TDX

支援團隊會回答你提出的問題，而含糊的問題只會得到令人安心、卻沒有實際意義的答案。詢問資料是否加密時，你會聽到所有儲存空間都已在靜態狀態加密；這句話雖然正確，但談的是磁碟。請改用更精確的問法。以下 5 個問題值得照原文寄出。

1. 你們是否提供已為 guest 啟用 AMD SEV-SNP 或 Intel TDX 的 instance？哪些方案支援？
2. 這項功能是在建立 instance 時個別選取，還是由 host 決定、我無法選擇？
3. 從 guest 內部能否取得硬體 attestation report？其中是否包含 /dev/sev-guest？
4. 你們是否提供或 passthrough 用來驗證該 report 與 CPU 供應商關聯性的憑證鏈？
5. 哪些區域與 host 世代支援？這是否會限制 resize 或 migration？

請依下列方式解讀回覆。問題 1 的答案是肯定，但問題 3 和 4 的答案是否定，表示你擁有無法驗證的記憶體加密。相較於轉售的記憶體模組，這對防範 host 的價值很低；因為你仍須相信營運商所說的功能，而這項功能的目的正是免除你相信營運商說法的需要。若回覆只談合規或泛稱加密，應視為否定答案。問題 5 沒有明確回答，通常表示只有單一區域的一個 instance family。

在價格與 instance 選擇方面，請預期可選清單會縮小，而不是只需支付簡單的附加費。Confidential size 往往組成獨立的 family，提供的 size 與區域都較少。實際成本通常來自這些限制，而不是每小時費率。請依你實際要執行的特定 size 估算價格。

如何檢查現有的 VPS

以下指令會在 guest 內執行，約需 1 分鐘。請將輸出視為重要線索，而非確切證明，因為 guest 所能看到的一切都由 hypervisor 控制。

systemd-detect-virt
systemd-detect-virt --cvm

第一個指令會顯示 kernel 偵測到的虛擬化技術。第二個指令會回報機密 VM 技術，可能的值包括 sev、sev-es、sev-snp 和 tdx。--cvm 是較新的選項，因此如果系統無法識別它，請先執行 systemctl --version。

sudo dmesg | grep -i -E 'sev|tdx|memory encryption'
sudo journalctl -k | grep -i -E 'sev|tdx|memory encryption'

啟用 AMD 記憶體加密的 guest 會輸出以 Memory Encryption Features active: 開頭的開機訊息，並在其後列出使用中的技術。trust domain 會在早期開機階段輸出專屬的 TDX 訊息。也請執行 journalctl 形式的指令，因為長時間運作的伺服器可能已讓 dmesg ring buffer 循環覆寫，導致開機訊息遭到丟棄。

grep -m1 ^flags /proc/cpuinfo | tr ' ' '\n' | grep -i -E 'sev|tdx'
ls -l /dev/sev-guest /dev/tdx-guest

請謹慎解讀 CPU flags。/proc/cpuinfo 會顯示 hypervisor 選擇呈現的 CPU 型號，因此 sev flag 可能只代表實體 CPU 支援該功能，並不表示 VM 實際使用它。tdx_guest 是較直接的訊號，因為該 flag 描述的是 guest 本身。attestation 工具需要使用裝置檔案：AMD 使用 /dev/sev-guest，Intel 使用 TDX guest 裝置；如果檔案不存在，ls 會明確回報找不到該檔案。部分平台即使 VM 使用機密運算，也會刻意將裝置隱藏在 guest 中，因此這項檢查只能確認狀態，不能排除機密 VM。

如果所有檢查都沒有找到任何結果，表示你的伺服器不支援這項功能。一般 VPS 主機通常會得到這個結果，這不代表系統發生問題。

答案是否定時的處理方式

答案確實會是否定的。實用的做法不是放棄這個問題，而是降低答案對你的代價。幾個習慣就能完成大部分工作，而且都不需要特殊硬體。

在主機上加密離開主機的資料。 備份最重要。像 restic 和 age 這類工具會在用戶端先完成加密，再將任何資料傳送到目的端，因此儲存服務提供者只會持有密文，不會持有金鑰。自有伺服器之間的流量也應使用 TLS（傳輸層安全性），包括經過服務提供者私有網路的流量，因為私有網路仍是你未管理的網路。

不要把 secret 放進映像檔或 git。 寫入 VM 映像檔或提交至 repository 的 secret，任何能讀取其中任一項的人都能取得。這個群體通常遠大於負責操作 hypervisor 的人員。請將 secret 存放在加密儲存區，並在部署時解密。使用 Ansible Vault 加密 secret 是設定負擔較低的做法，對大多數小型伺服器群組已經足夠。

限制每台伺服器可被信任的範圍。 這是能改變結果的習慣。請問自己：如果攻擊者讀取了這台機器的全部記憶體，他能取得什麼？如果答案包含可解密 10 年客戶紀錄的金鑰，那麼 hypervisor 只是問題較小的一半：這把金鑰正放在面向公開網路的 Web 伺服器上。為每台主機提供能完成工作所需的最小權限 credential，設定較短的有效期限，並準備好經過演練的輪替程序。如此一來，主機記憶體遭讀取時，你承受的損失就只限於該主機原本能執行的操作。

不要在無法輪替金鑰的 VPS 上放置金鑰。 輪替是能在實際環境中持續有效的控制措施。這個頁面上的其他做法，都假設你會發現問題。當你沒有發現問題時，真正要執行的就是輪替。

修正實際正在攻擊你的問題。 對幾乎所有讀者而言，實際遭到入侵的途徑是未修補的服務或遭竊的 credential，而不是資料中心的工程師讀取 RAM。檢查伺服器是否存在已知 CVE 和 Ubuntu Pro 如何擴大伺服器的修補涵蓋範圍，對降低風險的幫助都比任何 CPU 功能更大。在新機器上，新 VPS 上線後的前 10 分鐘 是你能執行的最划算工作。

如果確實有一個工作負載需要硬體信任邊界，就把它視為獨立的工作負載。將該部分部署在提供 confidential VM 的服務提供者上，或部署在你能控制的硬體上，其餘部分則留在成本可接受的位置。依敏感度拆分系統是正常的架構方式，而且現在就能採用；這一點是 confidential VPS 所做不到的。

FAQ

我的 VPS 供應商可以讀取伺服器的記憶體嗎？

在一般 VPS 託管環境中，可以。hypervisor 會配置並對映 guest 的 RAM，因此 host 上的 root 使用者可以讀取這些內容，例如透過 /proc/<pid>/mem 中的 QEMU process，或將 guest 的記憶體傾印至檔案。guest 內的任何機制都無法阻止或偵測這項操作。AMD SEV-SNP 與 Intel TDX 可用來移除這項能力，但大多數 VPS 方案都不提供。一般 VPS 能限制供應商存取權限的，主要是供應商自身的控制措施與員工政策，而不是技術本身。

完整磁碟加密能保護 VPS 資料不被託管商讀取嗎？

伺服器執行期間不能。檔案系統要能讀取，volume key 就必須留在 kernel memory 中，因此 key 和經過解密處理的資料都會位於 host 可以讀取的記憶體中。磁碟加密能保護靜態資料，例如故障後退回供應商的磁碟，或卸載後被遺忘的備份 volume。這些風險值得防護，但與 live host 讀取 live guest 是不同的風險。

如何確認 VPS 是否使用 AMD SEV-SNP 或 Intel TDX？

在 guest 內執行 systemd-detect-virt --cvm，接著執行 sudo dmesg | grep -i -E 'sev|tdx' 與 ls -l /dev/sev-guest。啟用 AMD memory encryption 的 guest 會輸出以 Memory Encryption Features active: 開頭的 boot line，而 Intel trust domain 會在 /proc/cpuinfo 中帶有 tdx_guest flag。這些結果都會經由 hypervisor 傳回，因此只能作為指示。唯一的證明是 signed attestation report；你必須在機器外部，根據 CPU 供應商的 certificate chain 驗證該報告。

Attestation 在 memory encryption 之上增加了什麼？

它能證明加密確實已啟用，並確認機器已啟動你預期的 software。無法驗證的 memory encryption，仍要求你相信 operator 的說法。attestation report 由 CPU 簽署，包含 VM 初始記憶體的 measurement，涵蓋 firmware、kernel、initrd 與 kernel command line；接著在機器外部，使用 silicon vendor 的 root certificate 進行驗證。這才能實現值得採用的模式：只有在報告驗證成功後，才將其他位置保存的 secret 釋出給 VM。

為 confidential computing 額外付費值得嗎？

這取決於 infrastructure operator 是否屬於你的威脅模型。對受法規管制的資料，或保護他人資料的 key 而言，這是目前唯一可用的技術方案；相較於替代方案，hyperscaler confidential instance 的價格很低。對個人網站或小型服務而言，同樣的費用用於修補程式與 credential hygiene，能換來更高的安全性。在尋找硬體功能之前，先誠實判斷你實際執行的是哪一種環境。