情報処理学会研究報告
IPSJ SIG Technical Report

AMD SEV-ES によるネストした VM の保護
瀧口 和樹1

光来 健一1

概要：機密性の高い情報をクラウドで扱うようになるにつれて，クラウドの内部犯から仮想マシン (VM)
内の機密情報を盗まれる危険性が増している．AMD のプロセッサは VM のメモリを透過的に暗号化する
SEV と呼ばれる機能を提供しており，VM のメモリ上のデータの盗聴を防ぐことができる．我々は VMの中で VM を動作させるシステムにおいて，ネストした VM を SEV で保護することを可能にする Nested
SEV を提案している．しかし，メモリに加えてレジスタも暗号化する SEV-ES には対応できていなかった．本稿では，ネストした VM を SEV-ES で保護することを可能にする Nested SEV-ES を提案する．
Nested SEV-ES は SEV-ES 仮想化と SEV-ES パススルーの 2 つの方式を提供する．SEV-ES 仮想化は仮
想 SEV-ES をネストした VM に適用し，外側の VM とは異なる鍵を用いてメモリとレジスタを暗号化す
る．一方，SEV-ES パススルーは外側の VM に適用されている SEV-ES をそのままネストした VM にも適用し，同じ鍵を用いてメモリとレジスタを暗号化する．これらの方式を KVM に実装し，Nested SEV-ESの性能を調べる実験を行った．

1. はじめにジスタの状態も暗号化することができる．しかし，Nested

SEV は SEV-ES には対応できていなかった．

ユーザに仮想マシン（VM）を提供するクラウドが様々

本稿では，SEV-ES を適用した L1 VM の中で SEV-ES

な用途に活用されている．それに伴い，機密性の高い情報を適用した L2 VM を動作させることを可能にする Nested

がクラウドで扱われるようになり，クラウドの内部犯なSEV-ES を提案する．Nested SEV-ES は用途に応じて，どから機密情報を盗まれる危険性が増している．そのた

SEV-ES 仮想化と SEV-ES パススルーの 2 つの方式を提供

め，AMD プロセッサでは Secure Encrypted Virtualization

する．SEV-ES 仮想化は SEV-ES を仮想化した仮想 SEV-

(SEV) [1] と呼ばれる VM のセキュリティ機構が提供されES を L2 VM に適用し，L1 VM と L2 VM で異なる鍵をている．SEV は VM のメモリを透過的に暗号化し，VM

用いてメモリとレジスタを暗号化する．一方，SEV-ES パの内部でのみ復号可能にする．そのため，VM 外部のハイススルーは L1 VM に適用されている SEV-ES をそのままパーバイザ等によってメモリ内部の機密情報が盗聴される

L2 VM にも適用し，L1 VM と L2 VM で同じ鍵を用いてのを防ぐことができる．Google Cloud や Microsoft Azureのメモリとレジスタを暗号化する．これらの方式を KVMなどで SEV を適用した Conﬁdential VM [2, 3] が提供されに実装し，Nested SEV-ES のオーバヘッドを測定した．

ている．

以下，2 章ではネストした仮想化に SEV を組み合わせる

一方，クラウドにおいてネストした仮想化 [4] を用いた

Nested SEV について述べる．3 章では Nested SEV を拡

様々なシステムが提案されている．ネストした仮想化は張した Nested SEV-ES を提案する．4 章では Nested SEV

VM 内で VM を動作させる技術であり，本稿ではクラウドの実装について述べる．5 章では Nested SEV のオーバが提供する外側の VM を L1 VM，その中で動作する VM

ヘッドを調べた実験について述べる．6 章で関連研究に触を L2 VM と呼ぶ．例えば，クラウドの L1 VM をホストとれ，7 章で本稿をまとめる．

して用いることにより仮想クラウドを提供することができる [5, 6]．ネストした仮想化を用いるシステムにおいて L2

2. Nested SEV

VM にも SEV を適用することを可能にするために，我々ネストした仮想化 [4] は VM の中で VM を動作させるたは Nested SEV を提案している [7]．第 2 世代以降の AMDめの技術であり，例えばクラウド上で仮想クラウドを実現

EPYC プロセッサは SEV-Encrypted State (SEV-ES) とするために用いられている [5]．ハイパーバイザ上で動作呼ばれる SEV の拡張を提供しており，メモリに加えてレしている VM の中で別のハイパーバイザを動作させ，その1

九州工業大学c 2023 Information Processing Society of Japan⃝

ハイパーバイザ上でさらに VM を動作させる．ネストした1

情報処理学会研究報告
IPSJ SIG Technical Report

L2 VM
L1ハイパーバイザ
L1 VM

透過的に暗号化

適用

SEV

適用

L1ハイパーバイザ

ネストした仮想化のシステム構成

仮想化を用いるシステムは図 1 のように 3 つのレイヤで構

SEV

L0ハイパーバイザ(a) 透過的 SEV

仮想
SEV

適用

L1 VM

直接アクセス

仮想デバイス
L0ハイパーバイザ

L2 VM
L1ハイパーバイザ
L1 VM

SEV

L1ハイパーバイザ(b) SEV パススルー

適用

直接アクセス

仮想デバイス
L0ハイパーバイザ(c) SEV 仮想化成される．従来のハイパーバイザはレベル 0 (L0) と呼ばれるレイヤで動作し，L0 ハイパーバイザと呼ばれる．そ

適用

L1 VM

L0ハイパーバイザ
図 1

L2 VM

L2 VM

図 2

Nested SEV の適用方式の上の VM は L1 と呼ばれるレイヤで動作し，L1 VM と呼ばれる．その VM の中で動作するハイパーバイザは L1

透過的 SEV または SEV パススルーを用いると L1 VM

ハイパーバイザと呼ばれる．その上の VM は L2 と呼ばれと L2 VM の両方のメモリを同じ鍵で暗号化することがでるレイヤで動作し，L2 VM と呼ばれる．

きる．これにより，L0 ハイパーバイザから L1 ハイパー

近年，クラウドにおいては内部犯から VM を保護する

バイザと L2 VM を保護することができる一方で，L1 ハ

ために AMD SEV が用いられるようになっている [2, 3]．

イパーバイザは L2 VM に自由にアクセスすることができ

SEV は AMD のプロセッサに搭載されているセキュリティ

る．例えば，パブリッククラウドが L0 ハイパーバイザを機能であり，VM のメモリを透過的に暗号化することによ動作させ，ユーザが L1 VM の中に L2 VM を作成すること

り VM 外の内部犯によるメモリの盗聴を防ぐことができが考えられる．この構成により，ユーザはパブリッククラ

る．I/O に使う領域などが暗号化されていると VM の実行

ウド上に仮想プライベートクラウドを構築 [5] し，SEV でに支障が出るため，SEV では VM 内のページテーブルを保護することができる．また，SEV 仮想化を用いると L1

用いてメモリ暗号化の制御を行う．ページテーブルエント

VM と L2 VM の両方のメモリを異なる鍵で暗号化するこリ (PTE) の C ビットを 1 にすると対応するページが暗号とができる．これにより，L0 ハイパーバイザから L1 ハイ

化され，0 にすると暗号化されない．一方，ページングがパーバイザを保護しつつ，L1 ハイパーバイザから L2 VM

無効の場合のメモリアクセス，PTE へのアクセスや命令を保護することができる．例えば，パブリッククラウドがフェッチは常に暗号化される．

L0 ハイパーバイザを動かし，別のクラウドプロバイダがネストした仮想化を用いるシステムにおいて L2 VM にL1 VM に仮想パブリッククラウドを構築して SEV で保護も SEV を適用することを可能にするために，我々は Nested

することが考えられる．そのユーザに提供する L2 VM もSEV を提案している [7]．Nested SEV は用途に応じて 3

SEV で保護することができる．

つの方式を提供している．透過的 SEV は図 2(a) のように

Nested SEV を応用して安全な監視を行うシステムも提L1 VM に適用されている SEV の機能を用いて，L2 VM

案されている．SEVmonitor [8] は SEV で保護された VMのメモリを透過的に暗号化する．L2 OS の対応は不要であ内でエージェントを安全に動作させることにより，VM 外るため，SEV 非対応の OS を用いることができる．SEV

で侵入検知システム（IDS）を実行することを可能にしてパススルーは図 2(b) のように L1 VM に適用されているいる．そのために，透過的 SEV または SEV パススルーを

SEV をそのまま L2 VM にも適用する．L2 OS はページ適用して L1 ハイパーバイザ内でエージェントを動作させテーブルの C ビットを用いてメモリ暗号化を制御できるたる．そして，VM イントロスペクション（VMI） [9] を用め，仮想 PCI デバイスへのパススルーアクセスが可能で

いて監視対象システムが動作する L2 VM のメモリデータある．また，L2 VM がプロセッサの仮想化支援機構を用を取得し，IDS に転送する．また，SEV-tracker [10] はク

いて動作していない場合でも適用できる．SEV 仮想化はラウド内にユーザの L1 ハイパーバイザを送り込み，クラ

図 2(c) のように SEV を仮想化した仮想 SEV を L1 ハイ

ウドサービスが動作する L2 VM の通信を追跡・制御する．

パーバイザに提供し，L2 VM に適用する．AMD セキュア

クラウドとユーザ間の相互保護を実現するために，SEV 仮

プロセッサ（AMD-SP）を仮想化した仮想 AMD-SP を L1

想化を適用することでクラウド内に送り込んだユーザ・ハ

VM に提供することにより，L2 VM に対して独立した鍵

イパーバイザをクラウドから保護しつつ，クラウドの L2

管理などを行うことができる．

VM をユーザ・ハイパーバイザから保護する．

c 2023 Information Processing Society of Japan⃝2

情報処理学会研究報告
IPSJ SIG Technical Report

第 2 世代以降の AMD EPYC プロセッサは SEV の拡張である SEV-ES を提供している．SEV-ES は VM のメモリに加えて仮想 CPU レジスタの状態も暗号化する．そのため，ハイパーバイザは VM の仮想 CPU レジスタを直接参1. I/O

3. GHCBに書き込む
2. #VC
7. 復帰

ドライバ

照して命令エミュレーションを行うことができず，SEV-ES

カーネル空間専用の対応が必要となる．Nested SEV は SEV-ES には対

4. VMGEXIT

で L2 VM を起動することができない．

L0ハイパーバイザ

3. Nested SEV の拡張
た Nested SEV-ES を提案する．

3.1 SEV-ES
AMD プロセッサの仮想化支援機構である AMD-V を用

6. VMRUN

L1 VM

応しておらず，SEV-ES が有効になっている L1 VM の中

本稿では，Nested SEV を拡張して SEV-ES に対応させ#VCハンドラ

5. GHCBに共有されたI/Oを処理
図 3#VC 例外の処理の流れする．#VC ハンドラは IRET 命令により#VC 例外を発生させた処理に復帰する．

いる場合，ハイパーバイザ（ホスト）が VMRUN 命令を実行

すべての VM Exit がこのような#VC ハンドラと GHCB

すると VM（ゲスト）に状態が遷移する．そして，外部割りを経由したゲスト OS による処理が必要というわけではな

込みや VM による I/O といった要因で VM Exit が発生すい．例えば，タイマ割り込みなどの外部割り込みによる VM

るとハイパーバイザへ復帰する．例えば，I/O ポートへのExit で#VC 例外を発生させると，VM がハイパーバイザ

アクセスをハイパーバイザがエミュレートする場合，VMに制御を戻さないことが可能になってしまう．また，#VC

がどのポートへどのレジスタを介して読み書きしようとし例外ハンドラで実行する VMGEXIT による VM Exit で#VCているかという情報が必要となる．VM Exit が発生した

例外が発生すると，無限ループに陥ってしまう．このよう時に VM のレジスタの状態は VM Control Block (VMCB)

な VM Exit は Automatic Exit (AE) と呼ばれ，#VC 例と呼ばれるメモリ領域に格納されるため，ハイパーバイザ

外は発生しない．それ以外の VM Exit は Non-Automatic

が読み書きできる．一方，レジスタをどう使って I/O を行

Exit (NAE) と呼ばれる．

うかという情報を取得するためには VM Exit を発生させた命令をデコードする必要がある．SEV では VM のメモ

3.2 Nested SEV-ES

リが暗号化されているため命令のバイト列には直接アクセ

Nested SEV-ES は SEV-ES を適用した L1 VM の中でスできないものの，Decode Assists と呼ばれる機能によっ

SEV-ES を適用した L2 VM を動作させることを可能にすて命令のバイト列が VMCB に格納される．

る．Nested SEV-ES では，L1 ハイパーバイザを L0 ハイ

しかし，SEV-ES では VM の仮想 CPU レジスタの状態

パーバイザに対する SEV-ES ゲストとして動作させられは VM Save Area (VMSA) と呼ばれるメモリ領域に暗号るようにする．そのために，L0 ハイパーバイザがアクセ化されて格納されるため，ハイパーバイザはレジスタのスする必要のある VMCB や GHCB などのメモリ領域や状態にアクセスすることができない．また，SEV-ES では

DMA バウンスバッファを暗号化しないようにする．それDecode Assists も利用できないため，VM Exit 発生時の命に加えて，#VC 例外が発生した時に#VC 例外ハンドラを

令のバイト列にもアクセスできない．そのため，SEV-ES

用いて処理を行うようにする．また，L1 ハイパーバイザ

では VM Exit の代わりに VM に VMM Communication

を L2 VM に対する SEV-ES ホストとして動作させられる(#VC) 例外が発生する．ゲスト OS 内のドライバが I/O

ようにする．そのために，L2 VM 用の VMSA の管理を行を発生させると図 3 のような流れで処理が行われる．#VC

えるようにしたり，L2 VM の#VC 例外ハンドラで実行さ例外が発生するとゲスト OS の#VC 例外ハンドラが命令れる VMGEXIT 命令の処理を行えるようにしたりする．

のデコードを行い，どのポートへどのレジスタを介して読み書きするかという情報を取得する．その情報を VM とハイパーバイザ間でデータを共有するメモリ領域である

Nested SEV-ES は用途に応じて，SEV-ES 仮想化と SEVES パススルーの 2 つの方式を提供する．
• SEV-ES 仮想化

Guest Host Communication Block (GHCB) に格納する．

SEV-ES を仮想化した仮想 SEV-ES を L1 VM に提供

そして，新たに導入された VMGEXIT 命令を実行して VM

し，L1 ハイパーバイザが仮想 SEV-ES を L2 VM に

Exit を発生させ，ハイパーバイザが GHCB を参照して命適用する．L1 VM と L2 VM で異なる鍵を用いてメモ

令エミュレーションを行う．処理が完了すると VMRUN 命令

リとレジスタを暗号化することができるため，L2 VMを実行して VM に復帰し，#VC ハンドラから実行を再開

を L1 ハイパーバイザから保護することができる．そc 2023 Information Processing Society of Japan⃝3

情報処理学会研究報告
IPSJ SIG Technical Reportのために，暗号鍵を管理する AMD-SP を仮想化した

L2 VM

仮想 AMD-SP を L1 VM に提供する．仮想 AMD-SP

L1ハイパーバイザ

は SEV が必要とするゲスト管理用コマンドに加えて，

L1 VM

VMSA を暗号化するために用いられる SEV-ES 用のコマンドを提供する．

初期化• SEV-ES パススルー
L1 VM に適用されている SEV-ES を L2 VM にもそのまま適用する．L1 VM と L2 VM は同一の鍵を用いてメモリとレジスタを暗号化するため，L1 ハイパーバ

書き換え

L0ハイパーバイザ
暗号化

AMD-SP

書き換え

L1用VMSAL2用VMSA参照

参照

アクセス不可チェックサム TMR チェックサム
プロセッサ

イザが L2 VM のメモリやレジスタにアクセスするこ

図 4

メモリ

SEV-ES パススルーにおける VMSA の管理とができる．そのため，GHCB などを L1 VM と L2

VM の共通の鍵で暗号化することができ，L0 ハイパー

込み，VMSA のチェックサムを計算して TMR に格納すバイザからはアクセスできないようにすることができる．LAUNCH UPDATE VMSA コマンドを任意のタイミングでる．また，L1 ハイパーバイザは L2 VM に対して命令実行できてしまうとハイパーバイザによって任意の状態をエミュレーションを行うことができるため，#VC 例

設定できてしまうため，VM を実行できる状態に遷移する

外を用いずに効率のよいメモリマップド I/O (MMIO)と LAUNCH UPDATE VMSA コマンドを実行することはできなを実現することができる．

くなる．

Nested SEV では同様の方式である SEV 仮想化と SEV

4.1.1 SEV-ES 仮想化の場合

パススルーに加えて，L2 OS の SEV 対応が不要な透過的SEV-ES 仮想化では L1 VM に仮想 AMD-SP を提供す

SEV と呼ばれる方式も提供していた．しかし，SEV-ES

るため，L0 ハイパーバイザと同様に L1 ハイパーバイザ

では透過的 SEV で用いていた SEV の機能である Virtual

でも L2 VM 用の VMSA の管理を行うことができる．L1

Transparent Encryption (VTE) を利用して L2 VM のメ

ハイパーバイザは仮想 SEV-ES を L2 VM に適用し，L2

モリを透過的に暗号化することができない．また，L2 OS

VM の起動時に VMSA を確保する．VMSA に暗号化さに#VC ハンドラを用意する必要があるため，L2 OS のれていない仮想 CPU レジスタの初期値を格納し，仮想SEV-ES 対応が必須である．

AMD-SP に対して LAUNCH UPDATE VMSA コマンドを実行

4. 実装
L0 ハイパーバイザおよび L1 ハイパーバイザとして KVMと QEMU を用いて Nested SEV-ES を実装した．

する．仮想 AMD-SP は L0 ハイパーバイザを呼び出し，物理 AMD-SP にコマンドを転送する．物理 AMD-SP は L2

VM 用の VMSA のチェックサムを計算して TMR に格納する．

4.1.2 SEV-ES パススルーの場合
4.1 L2 VM 用の VMSA の管理
SEV-ES で導入された VMSA には VM の仮想 CPU レ

SEV-ES パススルーを用いる場合，L1 VM に適用されている SEV-ES を L2 VM にも適用するため，L1 VM に仮ジスタの状態が暗号化されて格納されるが，ハイパーバイ

想 AMD-SP は提供されない．L2 VM を起動する時点ではザは暗号化された状態であれば VMSA のメモリ領域を自すでに L1 VM が実行中であるため，もはや AMD-SP の由に読み書きすることができる．そのため，レジスタの状

LAUNCH UPDATE VMSA コマンドを実行することはできない．

態を暗号化するだけでは状態のロールバック攻撃を行う

そのため，L1 ハイパーバイザが L2 VM の起動時に VMSA

ことができてしまう．この攻撃を防ぐために，SEV-ES はを確保しても，それを L2 VM 用に用いることはできない．

VM Exit が発生した時に VMSA のチェックサムを計算し，そこで，図 4 に示すように，L1 VM の起動時に L0 ハイ

Trusted Memory Region (TMR) と呼ばれる通常の方法でパーバイザが L2 VM 用の VMSA も確保し，あらかじめは読み書きできない特殊なメモリ領域に格納する．ハイ

LAUNCH UPDATE VMSA コマンドを実行しておく．確保したパーバイザが VMRUN 命令を実行した時，SEV-ES は VMSA

VMSA は L1 VM のメモリ空間にマップし，L2 VM の起動のチェックサムを計算して TMR に格納されている値と比時に利用する．L2 VM 用の VMSA は L1 VM に割り当て較を行い，一致しなければ実行を失敗させる．

られた仮想 CPU 数だけ確保する．L1 VM の仮想 CPU 数

ハイパーバイザは VM の起動時に VMSA に暗号化されてより L2 VM の仮想 CPU の総数の方が多い場合もありえるいない仮想 CPU レジスタの初期値を格納し，AMD-SP のため，L2 VM の仮想 CPU は L2 VM 用に確保した VMSALAUNCH UPDATE VMSA コマンドを用いて VM の鍵で VMSAとは一対一に対応させず，その時に割り当てられている L1を暗号化する．このコマンドではさらに TMR にチェック

VM の仮想 CPU に対応する L2 VM 用の VMSA を動的にサムを格納する領域を確保して VMSA にその参照を書き利用する．

c 2023 Information Processing Society of Japan⃝4

情報処理学会研究報告
IPSJ SIG Technical Report
オフセット+0x0000x000+0x008+0x010

CRC の逆算は，調整に使う領域より前方のバイト列にCS

ついては通常の生成多項式で計算する．SSE4.2 には CRC-

ES

0x018

CS

SS
DS

0x030
FS

0x048

32C の計算を行う CRC32 命令が含まれており，高速に計FS

GS

イト列は係数を反転させた生成多項式で CRC を計算する

...
0x390

算することができる．一方，調整に使う領域より後方のバ
ため，CRC32 命令を利用することができない．CRC を 1

GUEST_EXITINFO1GUEST_EXITINFO2GUEST_EXITINTINFO

0x570

YMM0[128:191]

YMM0[192:255]

YMM1[128:191]

ルを用いて複数ビットを一度に処理することで高速化する

0x588

YMM1[191:255]

YMM2[128:191]

YMM2[192:255]

ことができる [12]．ただし，多くのビットを処理できるよ

ビットずつ計算していく手法が最も単純であるが，テーブ

...

...
0x648

YMM13[192:255] YMM14[128:191] YMM14[192:255]

0x660

YMM15[128:255]
YMM15[128:191]
YMM15[192:255]

うにすると指数的にテーブルの要素数が増加してしまうため，一般的には 8 ビットずつ計算する．その場合には 28 要
素のテーブルが用いられる．テーブルの要素数を大幅に増

CRC 1

ES

CS

...

YMM13[192:255]

CRC 2

ES

SS

...

YMM14[128:191]

CRC 3

CS

SS

...

YMM15[192:255]

やすことなく高速化する手法として Slicing-by-N [13] がある．28 × n 要素のテーブルを用意すると 8 × n ビットを命
令レベルの並列性を活かして計算できる．

x86 プロセッサの PCLMULQDQ 命令を使うとオーバヘッド
図 5

第 3 世代 EPYC における VMSA のチェックサム

を償却できるような長さのバイト列であればさらに高速に計算できる [14]．この命令は 2 つの 128 ビットの SSE レジ
スタを用いて GF(2) 有限体上の乗算を行う．同一の CRC

L1 VM の起動時に LAUNCH UPDATE VMSA コマンドを実であるがより短いバイト列を乗算によって求めていき，最行するため，L2 VM 用の VMSA のチェックサムも L1 VM

終的に乗算によって剰余を求める Barrett Reduction を用の起動時に計算されて TMR に格納される．そのため，L2

いて CRC を求める．第 3 世代の EPYC プロセッサからはVM の起動時に仮想 CPU レジスタの初期値を VMSA に格

新たに VPCLMULQDQ 命令が導入され，256 ビットの AVX の納すると，TMR に格納されているチェックサムと不一致

レジスタを用いた乗算が行えるため，さらに 2 倍の高速化を起こして L2 VM の起動に失敗してしまう．同様に，L2を行える．そこで，VPCLMULQDQ 命令と端数バイト列のた

VM の仮想 CPU に割り当てられる L1 VM の仮想 CPU がめのテーブル方式を併用した CRC の逆算の実装を行った．

切り替わった時にも対応する VMSA を書き換える必要があるが，チェックサムが変化してしまうため VMRUN 命令の実行に失敗してしまう．

4.2 仮想化支援命令の SEV-ES 対応
SEV-ES が有効でない場合，ハイパーバイザが仮想化支

この問題を解決するために，VMSA を書き換える前に援命令の VMRUN 命令を実行するとまず，命令ポインタなチェックサムを計算しておき，VMSA の一部の値を変更ど必要最低限の状態がホスト保存領域に退避される．そしすることで VMSA を書き換える前後でチェックサムが変て，VMCB に保存された VM の状態が復元され，VM に化しないようする．SEV-ES パススルーでは L1 VM と L2状態が遷移する．一方，VM 内で VM Exit が発生した時にVM が同一の暗号鍵を用いるため，L1 ハイパーバイザがはまず，VM の最低限の状態が VMCB に退避される．そ

暗号化されている L2 VM 用の VMSA の値を読み書きす

して，ホスト保存領域の状態が復元され，ハイパーバイザ

ることができる．この処理を実装するために，AMD-SP のに状態が遷移する．VMRUN 命令で復元されない FPU レジ

内部で用いられているチェックサムの計算方法を調べた．

スタなどの状態は通常のコンテキストスイッチのようにス

調査の結果，第 3 世代の EPYC では図 5 のように 3 つのトア命令やロード命令を用いて退避と復元を行う．特殊な独立した CRC-32C を計算していることが分かった．

状態は仮想化支援命令である VMSAVE 命令と VMLOAD 命令

CRC は文献 [11] の手法で通常の CRC の計算と同程度のを用いて退避と復元を行う．

計算量で逆算することが可能である．ただし，3 つの 32 ビッ

SEV-ES が有効になっている場合は，ハイパーバイザがトの CRC の調整を行うためには，VMSA の中の 3 つの 32

VMRUN 命令を実行すると SEV-ES が無効の場合と同様に，ビットの領域が必要となる．予約済み領域やレジスタの値

まず最低限の状態がホスト保存領域に退避される．そしが格納されている領域は調整に利用できないため，VMSAて，VM のすべての状態が暗号化された VMSA から復元の途中に位置する GUEST_EXITINFO1，GUEST_EXITINFO2，

される．一方，VM 内で VM Exit が発生した時にはまず，GUEST_EXITINTINFO の領域を調整に用いる．これらの領VM のすべての状態が暗号化されて VMSA に保存される．

域は VM Exit 時にのみ値が格納されるため，VMRUN 命令

そして，すべての状態がホスト保存領域から復元されるかの実行前に書き換えても動作に影響はない．

初期化されるため，VM の状態は秘匿される．

c 2023 Information Processing Society of Japan⃝5

情報処理学会研究報告
IPSJ SIG Technical Report

L2 VM

L2 VM

NPT1→2L1ハイパーバイザ

L1ハイパーバイザ
VMGEXIT VMRUN

VM Exit

L1 VM

VMRUN

NPT0→1

L0ハイパーバイザ
図 6

図 7

VMRUN 命令の処理の流れ

Nested SEV-ES では，L1 ハイパーバイザがこれらの仮NPT0→2L1ハイパーバイザ

NPT の仮想化

初に実行するアドレスを含めておき，VM の起動前に想化支援命令を実行した時に VM Exit を発生させるよう

LAUNCH UPDATE VMSA コマンドで AP の初期状態に設定すにし，L0 ハイパーバイザが代わりに処理する．これらのる．そして，SIPI に指定されたアドレスは無視する．UEFIVM Exit はいずれも NAE であるため，L1 ハイパーバイザ

は SIPI を使いあらかじめ AP を立ち上げておき，UEFI がに#VC 例外ハンドラを用意して処理する必要がある．た

起動した後に実行されるゲスト OS が SIPI を発行するまだし，L1 ハイパーバイザは SEV-ES ゲストとして L1 VM

で待機する．ゲスト OS は AP Jump Table と呼ばれるメ内で動作しているため，VMRUN 命令で#VC 例外が発生する

モリ領域に AP で実行するアドレスを書き込み，SIPI を発ことはあらかじめ分かっている．そのため，VMRUN 命令を行する．UEFI は SIPI を検知すると AP Jump Table に指実行して#VC ハンドラで VM Exit を処理する代わりに，定されたアドレスにジャンプする．

直接，GHCB への設定を行って VMGEXIT 命令を実行する

SEV-ES 仮想化の場合，L2 VM の場合もこの仕組みでことにより効率化を図る．この場合，図 6 のような流れで

AP を立ち上げる．一方，SEV-ES パススルーの場合は L1

L2 VM が実行される．

ハイパーバイザが L2 VM 用の VMSA を変更することがで

L1 VM からの VM Exit 時に L0 ハイパーバイザは L1

きるため，より単純な SIPI 仮想化を行うことができる．そVM の状態にアクセスできないため，L1 VM 用のホスト保こで，最初の SIPI に関しては，SIPI で指定されたアドレス

存領域への状態の保存と復元の処理をエミュレートするこを L1 ハイパーバイザが L2 VM 用の VMSA に書き込み，とはできない．しかし，L1 VM のすべての状態は VMSA

チェックサムが変わらないように VMSA の調整を行う．

に保存されるため，Nested SEV-ES では L1 VM 用のホ

その後，VMRUN 命令を実行すると AP は指定したアドレス

スト保存領域を使用しない．L1 ハイパーバイザが VMRUNにジャンプする．2 回目以降の SIPI は AP Jump Table を命令を実行した時には L1 VM の VMSA と VMCB を L2

利用する．

VM のものに切り替える．L2 VM で VM Exit が発生した
時には L2 VM の VMSA と VMCB を L1 VM のものに切4.4 NPT 仮想化の SEV-ES 対応

り替える．ホスト保存領域を使用しなくても動作に支障は

仮想アドレスから物理アドレスに変換するためにページなく，L1 ハイパーバイザで特殊な状態の退避するためのテーブルが用いられるが，仮想化を行う場合はさらに VM

VMSAVE 命令と復元するための VMLOAD 命令を実行する必要の物理アドレスからホストの物理アドレスに変換するネスもない．

トしたページテーブル (NPT) が用いられる．ネストした
仮想化を行う場合，図 7 のように NPT を仮想化する．L1

4.3 マルチプロセッサ初期化の SEV-ES 対応

ハイパーバイザは L2 VM の物理アドレスから L1 VM の物

複数のプロセッサがある場合，最初に起動するプロセッ

理アドレスに変換する NPT1→2 を用意し，L0 ハイパーバ

サである Bootstrap Processor (BSP) 以外のプロセッサを

イザは L1 VM の物理アドレスからホスト (L0) の物理アド

Application Processor (AP) と呼ぶ．AP を立ち上げるたレスに変換する NPT0→1 を用意する．プロセッサはこの 2めにプロセッサ間割り込み (IPI) が用いられており，ハイ

つの NPT を使って L2 VM の物理アドレスからホストのパーバイザは IPI を仮想化した機構を提供している．INIT

物理アドレスへの変換を行うことはできない．そのため，

IPI を送ると AP がリセットされ，Startup IPI (SIPI) を送

L0 ハイパーバイザは NPT1→2 を基にして，L2 VM の物

信すると指定したアドレスから実行を開始する．しかし，

理アドレスからホストの物理アドレスに変換する NPT0→2

SEV-ES を有効にした VM では実行中にハイパーバイザがをシャドウページテーブルの手法を用いて生成する．

仮想 CPU のレジスタを更新することはできないため，これら IPI をエミュレートすることはできない．

QEMU ではあらかじめ UEFI のイメージに AP で最

c 2023 Information Processing Society of Japan⃝

シャドウページテーブルの実装には，書き換え時に常に同期を保つ方式と書き換え時には同期を保たない方式がある．同期を保つ方式では PTE を書き込み保護し，L1 ハイ

6

情報処理学会研究報告
IPSJ SIG Technical Report

パーバイザが書き換えようとすると VM Exit が発生する

Build: defconfig

ようにしておく．VM Exit が発生すると，L0 ハイパーバ

250

イザが命令エミュレーションを行って書き換えようとした
実行を再開する．
同期を保たない方式でも同様に書き換え時に VM Exitを発生させるが，命令エミュレーションは行わない．VM

Exit 発生時に書き込み保護を解除し，VM Exit を発生させ

213.4

248.1

247.1
231.3

235.5

150
100
50

た命令から実行を再開する．これにより，NPT0→2 が最新の状態ではなくなるが，書き換え後に行われる TLB フラッ

214.1

236.1

200
ビルド時間 [s]PTE に対応するシャドウ PTE を書き換え，次の命令から

231.3
217.3

SEV無効
SEV有効
SEV-ES有効

0

シュの際に同期を取ることでつじつまを合わせる．TLB フ

ネストなし

図 8

ラッシュの際には同期が取れていないシャドウ PTE を最SEVパススルー

SEV仮想化

カーネルビルド時間

新の状態に書き換え，再び書き込み保護を行う．この処理は L1 ハイパーバイザが VMRUN 命令を実行して L2 VM に状態を遷移する際に行う．

5. 実験

KVM は性能上の理由により，レベル 1 ページテーブ

Nested SEV-ES のオーバヘッドを調べる実験を行った．

ルは書き換え時に同期を取らない方式を，それより上のこの実験には，AMD EPYC 7443P（24 コア）の CPU を

レベルのページテーブルは同期を取る方式を採用してい1 基，DDR4-3200 RDIMM 128GiB のメモリを搭載した

る [15, 16]．同期を取る方式では命令エミュレーションを

マシンを用いた．L0 ハイパーバイザとして Linux/KVM行う必要があるため，SEV-ES を適用した L1 VM では利

6.0.0 と QEMU v7.1.0-748-gf1d33f55c4 を，L1 ハイパーバ

用できない．そこで，Nested SEV-ES では NPT 全体で書イザとして Linux/KVM 6.0.0 と QEMU v6.2.0 を用いた．

き換え時に同期を取らないようにすることで，NPT の仮

L2 の OS には Linux 6.0.0 を，UEFI として OVMF edk2-

想化を SEV-ES に対応させる．

stable201903-5039-g0b633b1494 を用いた．L1 VM には 12個の仮想 CPU と 16 GiB のメモリを割り当て，L0 で使わ

4.5 L2 VM における MMIO の SEV-ES 対応

れていない物理 CPU を割り当てた．L2 VM には 6 個の仮MMIO 領域は VM 内でのアクセス時に VM Exit を発生

想 CPU と 8 GiB のメモリを割り当て，L1 VM で使われさせることで仮想化される．対応する NPT の PTE に無ていない仮想 CPU を割り当てた．ネストした仮想化を用

効な値を設定することにより，ネストしたページフォール

いない場合は L1 VM に 6 個の仮想 CPU と 8 GiB のメモ

トによる VM Exit を発生させることができる．SEV-ES

リを割り当てた．MMIO 仮想化については，SEV-ES 仮想

ではネストしたページフォールトで#VC 例外が発生し，化では#VC 例外による方法を，SEV-ES パススルーでは#VC ハンドラで命令のデコードを行う．そして，アクセス

命令エミュレーションによる方法を用いた．

先のアドレスを GHCB に書き込み，VMGEXIT 命令を実行することでハイパーバイザによって MMIO がエミュレー

5.1 カーネルビルド時間

トされる．しかし，ネストしたページフォールトのすべて

Linux カーネル 6.1.0 を defconfig でビルドしたときにが NAE であるとデマンドページングを行うことができな

かかる時間を測定した．カーネルビルド時間を図 8 に示

い．そのため，NPT の PTE の予約ビットが 1 の場合にのす．L1 VM と L2 VM のどちらにも SEV を適用しない

み NAE が発生し，存在ビットが 0 のページへのアクセス場合と比べて，SEV 仮想化ではビルド時間が 1.8%増加

や書き込み可能フラグが 0 のページへの書き込みの場合なし，SEV-ES 仮想化では 7.3%増加した．一方，SEV パス

どには AE が発生するようになっている．

スルーではビルド時間が 2.1%増加し，SEV-ES パススルー

KVM のシャドウページテーブル実装では，NPT の PTE

では 6.8%増加した．このことから Nested SEV と比べて，に予約ビットを設定してもシャドウ PTE には反映されず，

Nested SEV-ES の方がいずれの方式でも少しオーバヘッ

L2 VM 内での MMIO 領域へのアクセスで NAE を発生さドが大きいことが分かる．ネストした仮想化を用いない場せることができなかった．そのため，PTE の予約ビットの合には，SEV のオーバヘッドは 0.3%，SEV-ES のオーバ

値もシャドウ PTE と同期を取るようにした．SEV-ES パ

ヘッドは 1.8%であった．

ススルーの場合には，L1 ハイパーバイザが命令エミュレー
ションを行うことができるため，PTE の予約ビットを 0 に設定することで AE を発生させ，効率よく MMIO を仮想化することが可能である．

c 2023 Information Processing Society of Japan⃝

5.2 HTTP サーバの性能
VM 内の Apache HTTP Server 2.4.48 に bombardier [17]を用いて VM 内から並列にリクエストを送信した．Web

7

情報処理学会研究報告
IPSJ SIG Technical Report

行に仮想化支援機構が使えるため，VM Exit のオーバー

Concurrent Requests: 1

1000リクエスト毎秒

1212.284

ヘッドは小さくなった．一方，SEV を有効にした場合は11.976プロセッサによる仮想化支援を受けられないため，性能の10.38910

低下が大きくなった．SEV-ES の場合はレジスタの状態の

8
6.580

る性能低下がみられた．

6

4.978

4

4.661
3.727

SEV無効

4.191

5.3 I/O 性能

SEV有効

2
0

VMSA への退避によるオーバーヘッドがあるため，さらな

6.580

暗号化されたメモリに対して DMA を行うことはできな

SEV-ES有効
ネストなし

SEVパススルー

SEV仮想化

Concurrent Requests: 100040

38.82640.34638.401

1000リクエスト毎秒

3533.27030

27.763

ファに対して DMA を行う．その際に，バッファとバウン
スバッファとの間でコピーが行われるため，I/O 性能が低下する．SEV-ES パススルーでは L1 VM と L2 VM が同

33.27032.373

いため，SEV では暗号化しないようにしたバウンスバッ

28.351 28.055

じ暗号鍵を用いるため，L1 ハイパーバイザと L2 VM の

25

間では暗号化されたメモリに対する DMA を行うことがで20きる．一方，SEV-ES 仮想化では L1 ハイパーバイザと L2

15

VM の間と L0 ハイパーバイザと L1 ハイパーバイザの間

1050の両方でバウンスバッファが使われるため，性能がさらに

SEV無効
SEV有効

低下する．

SEV-ES有効
ネストなし

図 9

SEVパススルー

SEV仮想化HTTP サーバのリクエスト処理性能

I/O スループットの最大の性能低下を調べるために，ブ
ロックデバイスに対する読み出しスループットを測定した．
ホストに 10 GiB の RAM ディスクを作成し，このブロック
デバイスにアクセスする仮想デバイスを virtio-blk-pci

サーバのリクエスト処理性能を図 9 に示す．リクエストをを使って L0 QEMU に追加した．L1 VM でも同様に，L0

1 並列で送信した場合，SEV を適用しない場合と比べて，

QEMU が提供するブロックデバイスにアクセスする仮想SEV 仮想化では性能が 29%低下し，SEV-ES 仮想化ではデバイスを virtio-blk-pci を使って L1 QEMU に追加

36%低下した．一方，SEV パススルーでは性能が 24%低した．

下し，SEV-ES パススルーでは 43%低下した．このことか

readv システムコールを用い，物理アドレスが連続してら，Nested SEV の場合とは逆に，SEV-ES 仮想化の方がいない 4 KiB の 1024 ページをバッファとした際の読み出性能がよいことが分かった．ネストした仮想化を用いない

しスループットを図 10 に示す．SEV を適用しない場合と場合には，SEV のオーバヘッドは 2.5%，SEV-ES のオー

比べて，SEV 仮想化では性能が 46%低下し，SEV-ES 仮想

バヘッドは 15%であった．ネストした仮想化により性能が化では 48%低下した．一方，SEV パススルーでは性能が大幅に低下していることが分かる．

28%低下し，SEV-ES パススルーでは 32%低下した．これリクエストを 1000 並列で送信した場合，SEV を適用しらのことから，SEV-ES を適用することによる I/O 性能へない場合と比べて，SEV 仮想化では性能が 15%低下し，の影響は SEV を適用する場合とそれほど変わらないこと

SEV-ES 仮想化では 16%低下した．この場合には SEV とが分かった．ネストした仮想化を用いない場合，SEV を適

SEV-ES のオーバヘッドはほぼ同程度であった．一方，SEV

用すると性能が 16% 低下し，SEV-ES を適用すると 13%

パススルーでは性能が 2.7%低下し，SEV-ES パススルー

低下した．

では 17%低下した．SEV パススルーではオーバヘッドが

2 MiB の 2 ページをバッファとした際の結果を図 10 に非常に小さかったが，SEV-ES パススルーでは SEV-ES 仮示す．現在の実装では，仮想 SEV と仮想 SEV-ES ではゲス想化と同程度のオーバヘッドとなった．ネストした仮想化

トに 2 MiB ページを割り当てることができていないため，を用いない場合には，SEV を適用するとむしろ高速化し，この測定では除外している．SEV を適用しない場合と比SEV-ES を適用してもオーバヘッドは 1.1%であった．ネ

べて，SEV パススルーでは性能が 36%低下し，SEV-ES パ

ストした仮想化によるオーバヘッドは 1 並列の場合よりもススルーでは 40%低下した．4 KiB の 1024 ページをバッ

小さくなっている．

ファとして用いた場合と比べて性能は改善したが，SEV に

この実験は VM 外部への I/O を行わず VM 内で完結さよる性能低下は少し大きくなった．

せたが，割り込み要因による VM Exit が多く発生した．

SEV を無効にした場合，VMSAVE 命令と VMLOAD 命令の実

c 2023 Information Processing Society of Japan⃝8

情報処理学会研究報告
IPSJ SIG Technical Report

Ryoan [20] はクラウド内に SGX のエンクレイヴを作成

6
5.39

5.27

スループット [GiB/s]

5
4.45

し，Google NaCl [21] を用いてその中にサンドボックスを5.39

構築する．NaCl がサンドボックス内で実行されるコード

4.56

4

3.89

を検査したりランタイムチェックを行ったりすることによ
3.65

3り，サンドボックス内でクラウドのサービスを安全に実行
2.92

2.80

安全にサービスの通信履歴を取得したり，サービスのアク

2
SEV無効
1

セス制限を行ったりすることができる．

SEV有効

同様に，AccTEE [22] は SGX のエンクレイヴ内で We-

SEV-ES有効0

図 10

することができる．これにより，サンドボックスの外部で

ネストなし

SEVパススルー

SEV仮想化ブ ロ ッ ク デ バ イ ス の 読 み 出 し ス ル ー プ ッ ト (バ ッ フ ァ:

4KiB × 1024)

bAssembly [23] を用いて双方向サンドボックスを構築す
る．WebAssembly も NaCl と同様にサンドボックス内でプログラムを安全に実行することができる．これにより，サンドボックス外部でプログラムによるリソース利用情報を安全に記録することができる．記録された利用情報はエ

スループット [GiB/s]

12も改ざんされることはない．

10
8Hyper-V は AMD-SP を仮想化することにより，L1 ハ
8.36
7.16

4

0

イパーバイザとして動作する KVM 上の L2 VM に SEV-

7.10

6

2

図 11

ンクレイヴ外部からもサンドボックス内のプログラムから

12.37

5.36

Secure Nested Paging (SEV-SNP) を適用可能にしてい5.00

る [24]．SEV-SNP は SEV-ES の拡張であり，リプレイ攻

SEV無効

撃やメモリデータの破壊，VM の物理ページの入れ替えにSEV有効よる攻撃なども防ぐことができる．Nested SEV-ES とは違

SEV-ES有効
ネストなし

SEVパススルー

ブ ロ ッ ク デ バ イ ス の 読 み 出 し ス ル ー プ ッ ト (バ ッ フ ァ:

2MiB × 2)

い，L1 VM 内の KVM は SEV ホストとしてのみ動作し，SEV ゲストとしては動作しない．そのため，L1 VM 内で動作する Linux カーネルや QEMU は SEV で保護されていない．また，SEV-ES パススルーのような，L1 VM と L2

VM が同一の暗号鍵を用いる構成はサポートしていない．

6. 関連研究7. まとめAMD SEV は Trusted Execution Environment (TEE)

本稿では，SEV-ES を適用した L1 VM の中で SEV-ESの一実装であるが，別の実装である Intel SGX についてはを適用した L2 VM を動作させることを可能にする Nested

VM 内で利用するための SGX 仮想化 [18] が提案されていSEV-ES を提案した．Nested SEV-ES は SEV-ES 仮想化

る．SGX はエンクレイヴと呼ばれる保護領域でプログラと SEV-ES パススルーの 2 つの方式を提供する．SEV-ES

ムを安全に実行することができるプロセッサのセキュリ

仮想化は SEV-ES を仮想化した仮想 SEV-ES を L2 VM にティ機構である．SGX を仮想化するために，エンクレイ

適用し，L1 VM と L2 VM で異なる鍵を用いてメモリとレヴ・ページキャッシュ（EPC）の一部だけを VM に提供し，ジスタを暗号化する．一方，SEV-ES パススルーは L1 VM

CPUID 命令と MSR のエミュレーションを行う．Xen 用のに適用されている SEV-ES をそのまま L2 VM にも適用

パッチは現在のところ利用できなくなっているが，KVM

し，L1 VM と L2 VM で同じ鍵を用いてのメモリとレジスと QEMU については標準でサポートされている．

タを暗号化する．これらの方式を KVM に実装し，Nested

ネストしたエンクレイヴ [19] は SGX ハードウェアを拡SEV-ES のオーバヘッドを測定した．

張することにより，エンクレイヴの中でエンクレイヴを動

今後の課題は，ネストした VM に SEV-SNP を適用でき作させることができる．外側のエンクレイヴからは内側のるようにし，リプレイ攻撃やメモリデータの破壊，VM のエンクレイヴにアクセスすることはできないが，内側のエ

物理ページの入れ替えによる攻撃などを防げるようにする

ンクレイヴは外側のエンクレイヴに自由にアクセスするこことである．また，Nested SEV では対応していた Xen やとができる．また，内側のエンクレイヴ同士は隔離される．

BitVisor を L1 ハイパーバイザとして用いることができる

これにより，エンクレイヴ内で動作するアプリケーション

ようにすることも予定している．

を信頼できないサードパーティのライブラリから保護したりすることができる．

c 2023 Information Processing Society of Japan
⃝

謝辞

9

情報処理学会研究報告
IPSJ SIG Technical Report

本研究の一部は，JST，CREST，JPMJCR21M4 の支援を受けたものである．また，本研究の一部は，国立研究開
発法人情報通信研究機構の委託研究（05501）による成果

[18]

を含む．
[19]

参考文献
[1]
[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]
[11]

[12]

[13]

[14]

[15]

[16]

[17]

Advanced Micro Devices, Inc.: Secure Encrypted Virtualization API Version 0.24 (2020).
Google LLC: Conﬁdential VM documentation, https://cloud.google.com/compute/confidential-vm/docs(2020).
Microsoft Corporation:
Azure Conﬁdential VM
optionsonAMD,
https://learn.microsoft.
com/en-us/azure/confidential-computing/virtual-machine-solutions-amd (2021).
Ben-Yehuda, M., Day, M. D., Dubitzky, Z., Factor, M.,
Har’El, N., Gordon, A., Liguori, A., Wasserman, O. andYassour, B.-A.: The Turtles Project: Design and Implementation of Nested Virtualization, Proc. Symp. Operating Systems Design and Implementation, pp. 423–436(2010).
Williams, D., Jamjoom, H. and Weatherspoon, H.: The
Xen-Blanket: Virtualize Once, Run Everywhere, Proc.
European Conf. Computer Systems, pp. 113–126 (2012).
Liu, C. and Mao, Y.: Inception: Towards a Nested Cloud
Architecture, Proc. Workshop on Hot Topics in Cloud
Computing (2013).
瀧口和樹，光来健一： Nested SEV：ネストした仮想化への AMD SEV の適用，第 34 回コンピュータシステム・シ
ンポジウム (2022).
能野智玄，光来健一： AMD SEV で保護された VM の隔
離エージェントを用いた安全な監視，コンピュータセキュ
リティシンポジウム 2022 (2022).
Garﬁnkel, T. and Rosenblum, M.: A Virtual Machine Introspection Based Architecture for Intrusion Detection,
Proc. Network and Distributed Systems Security Symp.,
pp. 191–206 (2003).
安東尚哉，光来健一： AMD SEV とネストした仮想化を用いた安全な通信履歴の取得，第 155 回 OS 研究会 (2022).
Stigge, M., Plötz, H., Müller, W. and Redlich, J.-P.: Reversing CRC – Theory and Practice, HU Berlin Public Report SAR-PR-2006-05, Humboldt University Berlin(2006).
Sarwate, D. V.: Computation of Cyclic Redundancy
Checks via Table Look-Up, Commun. ACM, Vol. 31,
No. 8, p. 1008–1013 (online), DOI: 10.1145/63030.63037(1988).
Kounavis, M. and Berry, F.: A systematic approach tobuilding high performance software-based CRC generators, 10th IEEE Symposium on Computers and Communications (ISCC’05), pp. 855–862 (online), DOI:
10.1109/ISCC.2005.18 (2005).
Gopal, V., Ozturk, E., Guilford, J., Wolrich, G., Feghali,W., Dixon, M. and Karakoyunlu, D.: Fast CRC Computation for Generic Polynomials Using PCLMULQDQInstruction.
Guida, G.: [Xen-devel] [PATCH 0/4] Out-of-sync L1
shadows., https://lists.xenproject.org/archives/
html/xen-devel/2008-06/msg00659.html (2008).
Tosatti,M.:
RFC: out of sync shadow,
https://lore.kernel.org/all/20080906184822.
560099087@localhost.localdomain/ (2008).
bombardier:Fastcross-platform
HTTP

c 2023 Information Processing Society of Japan
⃝

[20]

[21]
[22]

[23]

[24]

benchmarking
tool
writteninGo,
https://github.com/codesenberg/bombardier.
Huang, K.: Introduction to Intel SGX and SGX Virtualization, Xen Project Developer and Design Summit(2017).
Park, J., Kang, N., Kim, T., Kwon, Y. and Huh, J.:
Nested Enclave: Supporting Fine-grained Hierarchical
Isolation with SGX, Proc. Annual Int. Symp. Computer
Architecture (2020).
Hunt, T., Zhu, Z., Xu, Y., Peter, S. and Witchel, E.: A
Distributed Sandbox for Untrusted Computation on Secret Data, Proc. Symp. Operating Systems Design and
Implementation (2016).
Google, Inc.: Native Client, https://developer.
chrome.com/docs/native-client/ (2016).
Goltzsche, D., Nieke, M., Knauth, T. and Kapitza, R.:
AccTEE: A WebAssembly-based Two-way Sandbox for
Trusted Resource Accounting, Proc. Int. Middleware
Conf. (2019).
Haas, A., Rossberg, A., Schuﬀ, D., Titzer, B., Holman,
M., Gohman, D., Wagner, L., Zakai, A. and Bastien, J.:
Bringing the Web Up to Speed with WebAssembly, Proc.
Conf. Programming Language Design and Implementation (2017).
Piotrowski, J.:[RFC PATCH v2 0/7] Support nested SNP KVM guests on Hyper-V,
https://lore.kernel.org/lkml/20230213103402.
1189285-1-jpiotrowski@linux.microsoft.com/(2023).

10