「機密コンピューティング」を活用する方法を学ぶ: Linux 6.16 以降におけるアテステーションレポート取得

近年、機密コンピューティング技術を用いることで、クラウドプロバイダーなどの信頼できないサービスにより運用されている計算機上で、安心して機密情報を取り扱うことが可能になりつつあることを2024年8月の記事でお伝えしました。一方、機密コンピューティング分野、特にAMD SEV-SNPを取り巻く環境は過去1年間で大きく変化しました。あまりにも変化が速いため、数ヶ月前の検証手順が陳腐化することなどが多々あります。

本稿では、我々が検証を進める中で扱ったトピックや検証手順のアップデートなどをまとめます。個々の事例の紹介を通じて、機密コンピューティング分野の動向を読み取っていただく一助となれば幸いです。

SVSM vTPM対応パッチのLinux mainlineへのマージ
configfs-tsmを経由したアテステーションレポートの取得
configfs-tsmを用いてVMPL0へアテステーションレポート取得を委託する例
まとめ

SVSM vTPM対応パッチのLinux mainlineへのマージ

SVSM vTPMドライバがmainlineへマージされ、Linux 6.16からバニラカーネルでもvTPM が取り扱えるようになりました¹ ²。

2024年8月の記事の中でお伝えしたリモートアテステーション検証手順においては、vTPMを機密VMで認識できるようにするためにCOCONUT-SVSM プロジェクトによるパッチを適用したLinux カーネルを使用していました。2025年7月にリリースされたLinux 6.16で同等の変更がmainlineへ加えられたため、パッチを適用する必要がなくなりました。Linux 6.16以降では、ビルド時の構成でドライバが有効にされてさえいればSVSM vTPMを取り扱うことができます。

本稿の執筆時点ではUbuntu 25.10が標準のカーネルとしてLinux 6.17を採用しており、Beta版による試験を行った限りではSVSM vTPMドライバも組み込まれた状態になっているようです。他のディストリビューションでも新しいLinuxカーネルを採用するリリースが増えていくにつれ、SEV-SNPとvTPMを用いたアテステーションレポート取得が行える環境の構築が簡単になっていくものと思われます。

configfs-tsmを経由したアテステーションレポートの取得

2024年8月の記事ではvirtee/snpguestを用いてアテステーションレポートを取得していましたが、SVSM対応パッチのLinux mainlineへのマージが進んだことにより、configfsを経由してSVSMに対して要求を行えるようになりました。

これまではユーザーが一度ephemeral vTPMからEK公開鍵を読み出し、読み出した値を元に/dev/sevインターフェースへアテステーションレポート発行要求を行うという不完全な形でしたが、ゲストOSのカーネルとしてLinux 6.16以降を用いることで、SVSMとephemeral vTPMが動作するVMPL0内でアテステーションレポートの発行動作が完結するようになりました。

アテステーションレポート要求元がVMPL0であることの意味

VMPLとは何か

VMPL(Virtual Machine Privilege Level)はSEV-SNPにより導入された特権分離の概念です。特権レベルが高い(=VMPL の値が小さい)VMPLで動作するコードに割り当てられたメモリページは、ホスト・ハイパーバイザー・特権レベルの低いVMPLで動作するコードからのアクセスがハードウェアレベルで拒否されます。逆に、特権レベルの低いVMPLで動作するコードに割り当てられたメモリは特権レベルが高いVMPLからの参照が可能です³。最も高い特権レベルはVMPL0であり、VMPL0で稼働するプログラムは自身で意図的に許可しない限り他者からの干渉を受けません。

VMPLの概念が導入されたことで、セキュリティ的に重要なサービスを特権レベルの高いVMPLで動作させ、特権レベルの低いVMPL側から特権レベルの高いVMPLへ処理を委譲する形にすることで重要なサービスの改ざんを防止する、といったことが実現できるようになりました。

VMPL0で取得されたレポートは何が嬉しいのか

VMPL0でアテステーションレポートを取得するということは、アテステーションの根拠となる情報の提出を全てSVSMに任せるということになります。このため、正しい手順でアテステーションレポートの要求を行っているかを確認する作業が必須となり、使用されているSVSMのバイナリファイル / バイナリファイルのハッシュ値 / 提供されたソースコードがそれぞれ一致するかを確認する作業が必須となります。当然、バイナリ解析によって検証を行う作業は簡単ではありません。

一方、一度解析を行うことで「正当な動作をするSVSMバイナリのハッシュ値」を得ることができれば、アテステーションレポートに含まれる測定値と「正当な動作をするSVSMバイナリのハッシュ値」が一致するかを確認することで正しい手順でアテステーションレポートが要求されたかを簡単かつ確実に検証できます。

SVSMより低い特権レベルで動作するLinuxからアテステーションレポート要求を行うことも可能ですが、この場合一般的なLinuxシステムの防御技術を用いて要求ロジックを保護するしかありません。SVSMはLinuxより高い特権レベルで動作しているため、SVSMそのものに悪意のあるコードが混入していた場合に打てる手はVMのシャットダウン以外存在しません。

高い特権レベルで不正なプログラムを動作させられるリスクを排除するためにSVSMを挟まずにLinuxをVMPL0で起動させることも可能ですが、SEV-SNPによる権限分離を活用したサービス分離は行えなくなります。これは同時にvTPMも利用できなくなることを意味します。

vTPMが利用できない場合、確実に信用できる測定値がVM起動後最初に起動するプログラムのもののみとなります。VM起動後最初に起動するプログラムは一般的にUEFIファームウェアとなるため、例えばUEFIファームウェア→ブートローダー→不正なプログラム→Linuxのように起動シーケンスが進んだ場合、不正なプログラムが動作していたことを検出するのは困難です。

不正なプログラムの例として、改ざんされた測定値を返す不正なvTPMをVMPL0で動作する正規のvTPMとは別に動作させられたケースを考えてみます。

単にアテステーションレポートが発行後に改ざんされただけであれば、VCEK証明書を用いた検証により改ざんを検出できます。アテステーションレポートの発行要求だけを正規のvTPMへ転送し、測定値の応答だけ不正なvTPMで行うといった若干手が込んだケースにおいても、アテステーションレポートに発行に使用されたEKと不正vTPMから返される測定値のquoteに用いられたAKに関係性がないため、これも改ざん検出が可能です。

一方、不正なvTPMが正規vTPMにアテステーションレポート要求を転送せず、 /dev/sev を用いて自力でアテステーションレポートを発行した場合が問題です。この場合、不正vTPMの保持しているEKを用いつつ正規のアテステーションレポートが発行できるため、署名検証だけでは不正なアテステーションレポートであることを見抜けません。ephemeral vTPMである以上、EKはVMを起動するたびに変動するため、同一起動セッション内で値が変動した等でない限り、不正であることに気づくのは困難です。

しかし、ここでアテステーションレポートに要求元VMPL値が記載されている意味が出てきます。/dev/sevを用いた自前ロジックを持つ不正vTPMによって発行されたアテステーションレポートでは、記載される発行元VMPL値が2になります。前述の通りLinux上で動作するプログラムからはVMPL2以下の権限でしかアテステーションレポートを発行できないため、普段からVMPL0でアテステーションレポートを発行するようにしておけば不正であることを証明できます。

これらのことから、正しく検証が行われる環境が構築できていればVMPL0 / VMPL2のどちらからアテステーションレポートを要求したとしても本質的に変わりはないが、VMPL0で取得したレポートであれば信頼すべき界面が一つ減らせる、というメリットが見えてきます。

SVSMのコード解析が煩雑という課題がありますが、Linuxよりも高い特権で動作するSVSMはコード解析による検証が行われていなければアテステーションレポートの信頼性以前にシステム全体の安全性が担保できないため、どのようにアテステーションレポートを要求する場合であっても大前提として行っていなければならない作業であると言えます。

また、2024年8月の記事でも触れたとおり、vTPMをホスト・ゲスト両面から独立した環境で動作させるためには VMPL0でSVSMを動作させることは実運用上は必須と言ってよいため、SEV-SNPを用いた機密コンピューティングを正しく活用する上でSVSMをVMPL0で動作させないという選択肢はありません。

VMPL2ではなくVMPL0でアテステーションレポートを取得するというのは、「そもそもやっていなければならない手順を正しく踏んでいる場合にアテステーションレポートの堅牢性が上がる」行為であると言えます。

configfs-tsmを用いてVMPL0へアテステーションレポート取得を委託する例

VMPL0で動作するSVSMに対し、Linux 6.16以降で標準搭載されているSVSM-vTPMドライバを用いてリクエストを行い、アテステーションレポートを発行する具体的な手順を示します。

動作検証を行った環境

ソフトウェア	バージョン
Guest OS	Ubuntu 25.10 Beta
Guest kernel	6.17.0-5-generic #5-Ubuntu
QEMU	https://github.com/coconut-svsm/linux branch:svsm-igvm (commit: 8ce58bd)
Host kernel	6.11.0 https://github.com/coconut-svsm/linux/ branch:svsm (commit: 3b04c21)
SVSM	https://github.com/coconut-svsm/svsm/ branch:main (commit: 9959d99)

本稿では機密VM側の動作に焦点を絞り、UEFIファームウェアとしてSVSMを結合したOVMFを使用した上で、ゲストOSとしてUbuntu 24.04を問題なく起動できる環境が整っていることを前提とします。ホストは基本的に2024年8月の記事の手順に従い構築しましたが、各コンポーネントの開発が急速に進んでいるため記事中の手順はすでに陳腐化しており、ほとんどのコンポーネントは手順通りに構築できなくなっています。基本的には利用可能な最新のバージョン同士を組み合わせることで動作可能な環境が構築できるはずです。

手っ取り早くゲストOS環境を手に入れるにはUbuntu 25.10を利用するのがお勧めです。標準状態でSEV-SNPとSVSM vTPMが使用できるLinux 6.17が使用されているため、普通にインストールするだけで要件を満たせます。

自分でゲストカーネルを用意する場合、AMD SEV Guest driver (CONFIG_SEV_GUEST) やSNP SVSM vTPM interface (CONFIG_TCG_SVSM) など、AMD SEVとSVSMに関連する設定が適切に構成され、組み込まれた状態でビルドされている必要があります。ゲストで使用するカーネルは6.16.0以降であればバニラカーネルの状態で動作します。

以降の手順は適切に構成したカーネルを用いてゲストVMを起動させ、以下のような出力が得られている環境を前提とします。なお、本稿ではUbuntu 25.10 BetaとLinux 6.16.0を組み込んだUbuntu 24.04を利用し検証を行い、両方で同等の動作が得られることを確認しました。

$ lsmod | grep -E "(svsm|sev)"
sev_guest              24576  0
tpm_svsm               12288  0
tsm_report             16384  3 sev_guest
$ sudo dmesg | grep -E "(SEV|tpm-svsm)"
[    4.547524] Memory Encryption Features active: AMD SEV SEV-ES SEV-SNP
[    4.547541] SEV: Status: SEV SEV-ES SEV-SNP
[    4.717671] SEV: APIC: wakeup_secondary_cpu() replaced with wakeup_cpu_via_vmgexit()
[    6.172529] SEV: Using SNP CPUID table, 29 entries present.
[    6.172533] SEV: SNP running at VMPL2.
[    6.353177] SEV: SNP guest platform devices initialized.
[   11.050667] tpm-svsm tpm-svsm: SNP SVSM vTPM 2.0 device
[   11.059386] sev-guest sev-guest: Initialized SEV guest driver (using VMPCK2 communication key)
$

SVSMへアテステーションレポートの発行を依頼する

SEV-SNPを用いて起動した機密VM内で以下のコマンドを実行します。

なお、本稿ではnonceの生成も機密VM内で行いましたが、リモートアテステーションとして適切な形にするためにはnonce生成を信頼できる別の端末で行う必要があります。適切な構成にしたい場合、nonce.binの生成を信頼できる端末上で行い、SSHなどの安全な手段でアテステーション対象となるVMへ供給することで実現できます。リモートアテステーションの基本的な概念については2024年8月の記事で触れていますので、こちらもご覧ください。

#####  ephemeral vTPM 内で ephemeral EK を作成する
$ sudo apt install tpm2-tools
$ sudo tpm2_clear
$ sudo tpm2_createek --ek-context ek.ctx --public ek.pub --key-algorithm rsa
$ sudo tpm2_evictcontrol -C o -c ek.ctx 0x81010001
persistent-handle: 0x81010001
action: persisted
$ sudo tpm2_getcap handles-persistent
- 0x81010001

#####  configfs-tsm 初期化
$ sudo rmdir /sys/kernel/config/tsm/report/report0 # なければ飛ばしてOK
$ sudo mkdir /sys/kernel/config/tsm/report/report0

#####  SVSM を利用したレポート取得を TSM に指示する
$ echo svsm | sudo tee /sys/kernel/config/tsm/report/report0/service_provider
svsm

#####  Linux の動作している VMPL 値 (= 2) を TSM に渡す
$ echo 2 | sudo tee /sys/kernel/config/tsm/report/report0/privlevel
2

#####  nonce を生成し、TSM に渡す
$ head -c 64 /dev/urandom > nonce.bin
$ cat nonce.bin | sudo tee /sys/kernel/config/tsm/report/report0/inblob > /dev/null

#####  アテステーションレポートを読み出す
$ sudo cat /sys/kernel/config/tsm/report/report0/outblob > attestation_report.bin

##### サービスマニフェストを読み出す
$ sudo cat /sys/kernel/config/tsm/report/report0/manifestblob > services_manifest.bin

以上の手順でアテステーションレポート(attestation_report.bin)とサービスマニフェスト(services_manifest.bin)が得られます。サービスマニフェストという概念が唐突に出てきますが、これは「SVSM内で動作しているサービスの一覧」を含むデータ構造で、AMD社によるSVSM Specification⁴において定義されています。

SVSM_ATTEST_SERVICES CallでSVSMにアテステーションレポート要求を行うと、vTPM内で動作しているサービス一覧を含める形でアテステーションレポートの要求がなされます。SVSMを経由してアテステーションレポートを要求した場合、Linux側から渡したnonceにサービスマニフェストとEK公開鍵を結合し、SHA-512によりハッシュ化したものがアテステーションレポートのREPORT_DATA値として使用されます。

このため、アテステーションレポートとnonceの対応を検証するためにはサービスマニフェストとEK公開鍵を手元に持っておく必要があります。configfs-tsm経由でSVSM vTPMを用いる場合、EK公開鍵はサービスマニフェストの末尾に結合された状態で出力されるため、manifestblobを読み出すことで検証に必要なデータを得ることができます。これらのデータを用いた具体的な検証手順については後述します。

余談ですが、本稿の執筆時点でCOCONUT-SVSMにはvTPM動作を提供するサービスしか実装されていません⁵。サービスマニフェストの内容をパースして表示するサンプルスクリプトを作成しましたので、実データを用いて確認したい方はご利用ください。

アテステーションレポートの検証

得られたattestation_report.binはvirtee/snpguestなどのツールで検証が可能です。検証に際してCPUのChip IDに紐付く非対称鍵を用いて作成された、VCEK証明書を得る必要があります。VCEK証明書はChip IDを元にAMD KDS (Key Distribution System, AMD社の運用する鍵配布サーバ)からHTTPSで取得できます⁶。

本稿ではアテステーションレポートの検証をアテステーション対象となる機密VM上で直接行っていますが、リモートアテステーションとして適切な形にするためには検証手順を信頼できる別の端末で実行する必要があります。nonce.binとsnpguestツールキットとインターネットへの接続性を持っている外部の端末にattestation_report.binとservices_manifest.binをSSHなどの安全な手段で渡すことで適切な構成が実現できます。リモートアテステーションの基本的な概念については2024年8月の記事で触れていますので、こちらもご覧ください。

snpguestツールキットの扱いについて2024年8月の記事で紹介しましたが、この1年間で受け取る引数のフォーマットが変わっており、そのままではコマンドが実行できなくなっています。本稿の執筆時点(2025年9月, commit: c1d8292)では以下のコマンドで取得できます。

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
$ sudo apt install git build-essential
$ git clone https://github.com/virtee/snpguest snpguest_git
$ cargo build -r && cp target/release/snpguest ~
$ cd ~
$ ./snpguest fetch vcek der certs_vcek_only attestation_report.bin
$

VCEK証明書はインターネットへの疎通性とChip IDさえあれば環境を問わず取得できます。このため、Chip IDを含むattestation_report.binさえあれば、機密VM内の暗号化済みデータの鍵を保持する「外部の信頼されたシステム」で検証を実施できることは2024年8月の記事でも触れたとおりです。VCEK証明書を用いたアテステーションレポートの検証手順は以下の通りです。

$ ./snpguest verify attestation certs_vcek_only/ attestation_report.bin
Reported TCB Boot Loader from certificate matches the attestation report.
Reported TCB TEE from certificate matches the attestation report.
Reported TCB SNP from certificate matches the attestation report.
Reported TCB Microcode from certificate matches the attestation report.
VEK signed the Attestation Report!
$

VEK signed the Attestation Report!という表示からアテステーションレポートが正当であることが確認できます。

一方、アテステーションレポートが改ざんされている場合は Error: VEK did NOT sign the Attestation Report! のようなエラーが出力されて終了します。例として、正当なアテステーションレポートを1ビットだけ書き換えたものについて検証を行った際の出力を以下に示します。

$ ./snpguest verify attestation certs_vcek_only/ attestation_report_tampered.bin
Reported TCB Boot Loader from certificate matches the attestation report.
Reported TCB TEE from certificate matches the attestation report.
Reported TCB SNP from certificate matches the attestation report.
Reported TCB Microcode from certificate matches the attestation report.
ERROR: VEK did NOT sign the Attestation Report!
Error: VEK did NOT sign the Attestation Report!

アテステーションレポートの内容確認・検証

ところで、snpguest verify attestationによる検証だけではアテステーションレポートの取得要求を行ったVMPLの値を参照することができません。snpguest display reportでアテステーションレポートの内容を表示することができるので、実際にアテステーションレポートの内容を確認してみます。

$ ./snpguest display report attestation_report.bin
Attestation Report:

...略...

VMPL:                         0

...略...

Report Data:
F5 21 79 98 39 83 FE FD B3 E2 99 95 12 F1 FF 8A
76 AF 3B 68 1D BE 1D 02 5D F2 DB 3F FF EC 79 CD
9C 54 41 53 91 07 93 D8 AE BC 5C 6D F4 51 49 EA
66 CD 78 23 40 F6 9C 66 E3 2F 93 3F 91 5E BE C2

Measurement:
87 35 67 8E 1D A9 8A 81 FC 8F BA 53 14 E5 36 33
81 99 FD A9 52 A4 1B 54 08 D2 45 71 5D 10 94 CD
85 56 67 78 43 83 13 7D 84 4C 5F 78 74 FA EF 01

...略...

VMPL値やReport Dataなどのフィールドで値が確認できます。ここでは重要な3つのフィールドについて確認・検証を行っていきます。

VMPL

VMPL: 0はアテステーションレポートの要求元VMPLを示す値です。2024年8月の記事ではsnpguestツールキットを用いてアテステーションレポートを要求する手順をご紹介しましたが、その場合にアテステーションレポートに含まれる要求元 VMPLの値は2になります。

$ sudo ./snpguest report attestation_report_vmpl2.bin request.txt --random -v 2
$ ./snpguest display report attestation_report_vmpl2.bin
Attestation Report:

...略...

VMPL:                         2

...略...

余談ですが、snpguestの-v 2オプションは要求元VMPLを指定するものです。ここを0に変えるだけで要求元をVMPL0にできそうですが、自身(=Linux kernelを含めたOSそのもの)が動作しているVMPLより高位の値を指定するとSEVファームウェアにより操作が拒否されます。ちなみに、自身より低位の値を指定することは可能です。

$ sudo ./snpguest report attestation_report_vmpl3.bin request.txt --random -v 3
$ sudo ./snpguest report attestation_report_vmpl1.bin request.txt --random -v 1
ERROR: unable to fetch attestation report
because: Firmware Error Encountered: Known SEV FW Error: Status Code: 0x16: Given parameter is invalid.
because: Known SEV FW Error: Status Code: 0x16: Given parameter is invalid.
Error: unable to fetch attestation report

Caused by:
    0: Firmware Error Encountered: Known SEV FW Error: Status Code: 0x16: Given parameter is invalid.
    1: Known SEV FW Error: Status Code: 0x16: Given parameter is invalid.

以上のように、自分より特権レベルの高いVMPL値を騙ったアテステーションレポートを生成できないことから、アテステーションレポートに記載されている要求元VMPL値は、高く見積もってもレポートに記載されているVMPL上で動作するコードより要求されたことが証明できます。このため、正当な署名を持つアテステーションレポートに要求元VMPL値が0と記載されているならば、そのアテステーションレポートは確実にVMPL0で取得されたもの、すなわちクラウドサービスプロバイダー・ユーザーの双方から干渉を受けずに採取されたデータであると言えます。

Report Data

アテステーションレポート自体が正当なことと要求元VMPLが確認できましたが、これだけでは以前に取得した正当なアテステーションレポートを応答する、不正な動作のCPU上でOSが動作している可能性を排除できません。いわゆるリプレイ攻撃が可能な状態です。

この可能性を排除するために、アテステーションレポートの要求時に/sys/kernel/config/tsm/report/report0/inblob に対して/dev/urandomを基にしたnonceを書き込みました。アテステーションレポート発行の仕組みではnonceを用いたchallenge-responseの仕組みが備わっているので、本当に我々が支給したnonceに対応したアテステーションレポートが発行されているかを確認する必要があります。

確認手順は単純で、nonceとサービスマニフェストを結合した値にSHA-512によるハッシュ化を施した値がアテステーションレポートに含まれているので、手元にあるnonceとアテステーションレポート取得時に得られたサービスマニフェストのダンプを結合し、sha512sumを用いてハッシュ値を計算した後、これをアテステーションレポート内に含まれるチャレンジ値と比較するだけです。

アテステーションレポート内のREPORT_DATAフィールドにチャレンジ値が含まれます。nonceとサービスマニフェストを基にした期待するチャレンジ値の計算とsnpguestツールキットによるREPORT_DATAフィールドの表示例を以下に示します。

##### アテステーションレポートの発行を要求する過程で得られた nonce.bin と services_manifest.bin を使う
$ cat nonce.bin services_manifest.bin | sha512sum
f52179983983fefdb3e2999512f1ff8a76af3b681dbe1d025df2db3fffec79cd9c544153910793d8aebc5c6df45149ea66cd782340f69c66e32f933f915ebec2  -
$ ./snpguest display report attestation_report.bin
Attestation Report:

...略...

Report Data:
F5 21 79 98 39 83 FE FD B3 E2 99 95 12 F1 FF 8A
76 AF 3B 68 1D BE 1D 02 5D F2 DB 3F FF EC 79 CD
9C 54 41 53 91 07 93 D8 AE BC 5C 6D F4 51 49 EA
66 CD 78 23 40 F6 9C 66 E3 2F 93 3F 91 5E BE C2

表示フォーマットが異なりますが、ハッシュ値が一致することを確認できます。

Measurement

AMD社により製造された特定個体のCPU上で、真に我々の要求に応じてアテステーションレポートが発行されたことまではこれまでの手順で証明できました。最後に測定値によるOVMFのLaunch Digest検証が必要ですが、これは2024年8月の記事で示した手順と同様です。

coconut-svsm/svsm内に含まれるigvmmeasureツールキットを用いて、真正なIGVMファイルを測定することで正当なOVMFのLaunch Digestを取得し、アテステーションレポート内に含まれるMeasurementフィールドの内容と比較することで検証が行えます。以下に出力例を示します。

# ./igvmmeasure ./coconut-qemu.igvm measure

===============================================================================================================
igvmmeasure './coconut-qemu.igvm'
Launch Digest: 8735678E1DA98A81FC8FBA5314E536338199FDA952A41B5408D245715D1094CD855667784383137D844C5F7874FAEF01
===============================================================================================================

$ ./snpguest display report attestation_report.bin
Attestation Report:

...略...

Measurement:
87 35 67 8E 1D A9 8A 81 FC 8F BA 53 14 E5 36 33
81 99 FD A9 52 A4 1B 54 08 D2 45 71 5D 10 94 CD
85 56 67 78 43 83 13 7D 84 4C 5F 78 74 FA EF 01

...略...

表示フォーマットが異なりますが、ハッシュ値が一致することを確認できます。

まとめ

本稿では Linux 6.16 で取り込まれた機能拡張を活用し、SEV-SNPを用いた機密コンピューティング技術の活用手順について扱いました。

これまでは自分で様々な手を打たなければSEV-SNPは活用できない状況でしたが、Linux kernelやUbuntuなどの主要インフラへと機能が組み込まれ始めたことにより、ようやくきちんと活用できる環境が整ってきたかなと感じます。とはいえ「自分以外の誰も信用しないでいい」という目的を達成するためには、どれだけ周辺環境が整備されたとしても利用者側で行うべき作業はゼロにはならず、一定の知見を持つことが必須となります。より安全なコンピューティング環境がきちんと活用可能になる世界を目指して、当チームでは今後とも情報発信を進めてまいります。

引用文献

Linux 6.16 Could See AMD SEV-SNP SVSM vTPM Driver Merged For EPYC CPUs - Phoronix ↩︎
Linux ChangeLog-6.16 (注意: リンク先は 15MB のテキストファイルです) ↩︎
AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More ↩︎
"AMD: Secure VM Service Module for SEV-SNP Guests" , p29 ↩︎
"coconut-svsm/svsm: kernel/src/protocols/attest.rs", L37 ↩︎
virtee/snpguest: src/fetch.rs ↩︎

共著

さくらインターネット株式会社　江草陽太