RISC-V TEE
I/Oまわりの状況
早稲⽥⼤学 ⽊村啓⼆

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

1

⾃⼰紹介
u マルチコアアーキテクチャ・⾃動並列化コンパイラの研究に従事

u OSCAR⾃動並列化コンパイラ
u 各種サーバマルチコア，組み込みマルチコアでのアプリ

ケーション並列性能評価

u 最近はセキュアなコンピュータシステムの研究も
u 不揮発性メインメモリのメモリプロテクション
u Trusted Execution Environment (TEE)u 今回はこのあたりの話
セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

2

本⽇の内容u RISC-V TEEのI/O周りの状況を紹介
u まずはRISC-V PMPとKeystoneの復習
u SiFive WorldGuard
u IOPMPu IOMMU
u 及び関連の話題

u メモリ隔離（保護）と割り込みの観点から

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

3

Trusted Execution Environment (TEE)に関して極めて簡単におさらいu 信頼可能な（隔離された）プログラム実⾏環境
u ごく限られた信頼できるもののみに依存してプログラムを実⾏する

u OSも信⽤しない

u 要素技術u 隔離されたメモリ空間
u OSが管理する通常の仮想記憶では不⾜

u 今回はこれをI/Oの観点からみていく

u メモリの完全性保証
u Attestation
セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

4

RISC-Vの物理メモリ保護関連の復習
特権モード
u 3つの特権モード
u U-mode (user)
u ユーザアプリが動作するモード

u S-mode (supervisor)u OSが動作するモード

u M-mode (machine)u ファームウェアやハイパーバイザが動作するモード
u RISC-V Linuxはここで動作するOpenSBIを利⽤する

u TEEを利⽤する場合はここでSecurity Monitor (SM)が動作する
セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

5

RISC-Vの物理メモリ保護関連の復習
Physical Memory Protection (PMP)u RISC-Vのメモリ隔離機構
u 指定した物理アドレス領域のU/Sモードに対するアクセス権限を設定する

u 読み(r)・書き(w)・実⾏(x)u サイズは2^n (NAPOT)か任意のサイズの領域 (TOP)か選べる
u ⼆つ⼀組のレジスタで領域を指定する（pmpcfg, pmpaddr)
u 命令セット仕様書では64組（もともとは16組）まで持つことが出来る

u 各コアが持つ
u コンテクストスイッチ時にIPIでコア間の⼀貫性を維持する必要がある
セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

6

RISC-Vの物理メモリ保護関連の復習
EuroSys ’20, April 27–30, 2020, Heraklion, Greece
PMPによる物理メモリ保護の様⼦
PMP registers

Priority

pmpcfgpmpcfg perm.
rwx=000
rwx=111

pmpaddr…

PhysicalMemorySM

E2

E1

Untrusted Context

SME2

E1U1

Enclave (E1) Context[Keystone]より引⽤

Figure 3. How Keystone uses RISC-V PMP for the �exible, dynamic
memory isolation. pmpaddr and pmpcfg control and status registers(CSRs) are used to specify PMP entries. The SM uses a few PMP
entries to guard its own memory (SM) and enclave memories (E1,
セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

7region2 and then cquest, the SM proteentry with all perm
entry has a higher p
Figure 3), the OS anenclave region. A v
not overlap with e
During controlcurrent core only)
relevant enclave meentry permissions
clave. This allows t
no other regions. A
the SM disables all

RISC-Vの物理メモリ保護関連の復習
Keystoneu 隔離された実⾏環境をEnclaveとKeystone呼ぶ
u Enclave内部で動作するアプリケー

ションをEappと呼ぶ

はOSも⼿出しできない

u OSの代わりにRuntime (RT)がEappの実⾏をサポートする

u Eapp起動時は、そのEnclaveが利⽤するメモリ領域のPMP設定をSMで⾏うu Eappのコンテクストスイッチの際もSMでPMPの設定変更を⾏う

Higher Privilege

u Enclaveが利⽤するメモリ領域に

Untrusted

Enclave 1

User(U-mode)

AppAppEnclave App 1(Eapp)

Supervisor(S-mode)

Operating System(OS)Runtime (RT) 1…

Machine(M-mode)
TrustedHardware…

Enclave 2
Eapp 2
RT 2

Security Monitor (SM)

RISC-V Cores

Optional H/W Features

Root of Trust[Keystone]より引⽤

Figure 1. Keystone system with host processes, untrusted OS, security monitor, and multiple
enclaves (eachwith runtime and eapp)
セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ
2024/1/29
8solution which has a large software stack [18, 22, 31] to extend the supported features. On the other hand, an AMD
SEV-based solution isolates a full VM with a large TCB. Iftaacbnbcemmmaoa現状、何が問題か︖
u I/Oは考慮されていない
u PMPはCPUコアの持つ機能
u コアから物理メモリへのロード・ストアリクエストの可不可はコア内部のPMPによってチェックされる
u メモリ側はノーチェック

u DMA等のCPUコア以外のバスマスタはメモリアクセスし放題

u I/O側へのアクセスもノーチェック

u 割り込みもEappは受け取れない
u 現在の実装では、割り込みは⼀度SMで受け取ってからホストOSに渡される
u 受け取れたとしてもEnclaveのコンテクストスイッチは重い

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

9

（RISC-Vではないけれど）事例紹介
GPU内部データの盗聴

https://blog.trailofbits.com/2024/01/16/leftoverlocals-listening-to-llmresponses-through-leaked-gpu-local-memory/
セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

10

RISC-V界隈の動き
security@lists.riscv.orgより

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

11

本⽇の本題u I/Oも含めてTEEを構築するような仕組みは︖
u 以下のような提案がある
u SiFive WorldGuard
u IOPMPu IOMMU

u 先のProf. Asanovicの⽂⾯に倣い、バスリクエス

トの要求元をsource、宛先をtargetとしてみる
u 古来よりmaster/slaveなどと⾔っていますが…

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

12

SiFive WorldGuardu

SiFive策定による仕様

u

基本的なアイデアuu

トランザクションに付与したタグの⼀致・不⼀致で処理の可不可を判別する

タグの値がWorldを⽰すu

各Worldはそれぞれ隔離された空間を表現する

uSource/Targetにそれぞれが所属するWorldのタグを事前に設定しておく

uSouceはリクエスト発⾏時にタグを付与する

uTargetはリクエストに付与されたタグと⾃分のタグから対応するPMPをチェックし、そのトランザクションを処理するかどうかを決定する

u

ARM TrustZoneを拡張したものと考えられる
u

リクエストにNSビットを付与し、secure/non-secureを区別する

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

13

Block Diagram
The block diagram in Figure 4 provides an overview of the SiFive WorldGuard solution on amulti-core chip with DMA, memories, and peripherals. It also shows processors and hardware
blocks.

WorldGuardを持つSoCのブロック図例[WorldGuard]より引⽤
Figure4:
WorldGuard
Systemona
Multi-coreChip
セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ
2024/1/29
14

WorldGuard
Core-drivenu シンプルなモデル、ハードウェアの修正も最⼩限
u コアは固定的にWorldと結びつけられる
u U/S/M各モード問わない

u L2/L3キャッシュのタグアレイはWorldのタグも保持する
u あるWorldがアクセスしたラインは他のWorldはアクセス不能
u L1キャッシュは修正無し

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

15

WorldGuard
Process-driven
u プロセスがWorldと結びつけられる
u 特権モード毎にも別々のWorldタグを持つ

u 各コアは⾃分が所属しうるWorldのタグリストを割り当てられる

u 割り当てはシステム中の特権コアにより⾏われる
u MモードはSモードのWorldタグを、SモードはUモードのWorldタグを、それぞれリストの中から設定可能

u L1キャッシュのタグアレイもWorldタグを保持する
u ⼀つのコアが複数のWorldに所属しうるから
セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

16

WorldGuard
割り込みの扱いu Core-Local Interrupt (CLINT)
u タイマ割り込みに関連するレジスタ（mtimecmp）が保護される

u Platform-Level Interrupt Controller (PLIC)u Process-drivenが前提
u 各特権モードは別々のWorldに所属する

u SモードのOSで処理される割り込みハンドラのアドレステーブルはMモード

にてPMPを使ってロックされる

u PLICからの割り込みは⼀度Mモードで受け付ける
u 割り込みの発⽣元に応じた割り込みハンドラを選択してSモードに遷移する
u 複数のEappが動いていて、それぞれ割り込みを受け付けたい場合はどうする︖

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

17

This document describes a mechanism to improve the security of a platform. In a platform, the bus
initiators on it can access the target devices, just like a RISC-V hart. The introduction of I/O agents likethe DMA (Direct Memory Access Unit) to systems improves performance but exposes the system tovulnerabilities such as DMA attacks. In the RISCV eco-system, there already exists the PMP/ePMP
which provides standard protection scheme for accesses from a RISCV hart to the physical address
space, but there is not a likewise standard for safeguarding non-CPU initiators. Here we propose thePhysical Memory Protection Unit of Input/Output Devices, IOPMP for short, to control the accesses
issued from the bus initiators.

IOPMP

IOPMP is considered a hardware component in a bus fabric. But why is a pure-software solution notenough? For a RISC-V-based platform, a software solution mainly refers to the security monitor, aprogram running on the M-mode in charge of handling security-related requests. Once a requirementfrom another mode asks for a DMA transfer, for example, the security monitor checks if therequirement satisfies all the security rules and then decides whether the requirement is legal. Only alegal requirement will be performed. However, the check could take a long time when the requirement
is not as simple as a DMA transfer. A GPU, for example, can take a piece of program to run. Generally,
examining whether a program violates access rules is an NP-hard problem. Even though we only
consider the average execution time, the latency is not tolerable in most cases. A hardware component
that can check accesses on the fly becomes a reasonable solution. That is the subject of this document,
IOPMP.

u 2023年12⽉時点でVersion1.0.0-

draft5u Sourceとバスの間に接続するモジュール
u 各sourceはid (SID)を持つ
u IOPMPは内部にRISC-V PMPと同様のアドレス・コンフィグの配列(IOPMPARRAYを持つ)
u SIDとIOPMPでリクエストを[IOPMP]より引⽤

Figure 1. Examplary Integration of IOPMP(s) in System.

バスに流すかどうか決める

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

RISC-V IOPMP Architecture Specification | © RISC-V

2024/1/29

18IOPMP
どうかな、と思うところ
u 仮想記憶は考慮されず
u 割り込みに関する記述もない
u 設定変更はどのコアのどのモードからも可能なように⾒えるu 設定変更の⼿順として，⼀度全てのトランザクションをストールしてから変更する，といったことは書いてあるu ブート時にPMPで保護してSMだけが操作できるようにすれば良いか

u ベアメタルに近い状況では良いのかも
セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

19

IOPMP
オープンソース実装︓Protego

githubのURL

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

20

IOMMUu 2023年6⽉Version 1.0がRatified
u I/Oデバイス（主にDMA）⽤のMMU
u Source側のデバイスが物理アドレスではなく論理アドレスで主記憶アクセスを⾏う

u 例︓GPU（のDMA）がホストメモリからデバイスメモリにデータを転送するとき、DMAはホストメモリに論理アドレスでアクセスする

u IOMMUが使うページテーブルがI/Oデバイス毎に設定でき、それらがOSから適切に保護できればI/Oもメモリ隔離できる

u IOMMU⾃体はRISC-V特有ではない
u 仮想化技術で活⽤される
u ゲストの物理アドレスをホストの物理アドレスに変換する
u おそらく第3回（次回）詳しく説明していただけるのではないかと

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

21

IOMMUIOMMUを持つRISC-V SoCのブロック図の例[IOMMU]より引⽤
ここにPMPがつくことがある

Figure 5. Example of IOMMUs integration in SoC.

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

The IOMMU is invoked by the IO Bridge for address translation and protection for inboundtransactions. The data associated with the inbound transactions is not processed by the IOMMU.
The IOMMU behaves like a look-aside IP to the IO Bridge and has several interfaces (see Figure 6):• Host interface: it is an interface to the IOMMU for the harts to access its memory-mapped
registers and perform global configuration and/or maintenance operations.

22

IOMMU
割り込み
u

MSI（割り込み通知はメモリ書き込みトランザクションで処理）u

割り込みに応じたメモリ上の割り込みファイルに書き込まれる

u

IOMMUのアドレス変換により実際の書き込み先を操作できる
u 割り込みとEnclaveを紐付けておけば、特定のEnclaveで割り込みを受け取れる（はず）

u 仮想化における割り込み処理と同じ（はず）

u

RISC-V Advanced Interrupt Architectureも関連する[INTERRUPT]

ここから先はコントローラでCPUコアに通知する[IOMMU]より引⽤
セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ
23 filesFigure 3. MSI address translation to direct guest programmed MSI 2024/1/29
to IMSIC guest interrupt

1.2.3. Guest OS
The hypervisor may provide a virtual IOMMU facility, through hardware emulation or byenlightening the guest OS to use a software interface with the Hypervisor (also known as paravirtualization). The guest OS may then use the facilities provided by the virtual IOMMU to avail theIOMMU
設定更新
u 設定更新に関しては特に記述無し
u こちらもブート時にPMPで保護してSMだけが操作できるようにすれば良いか

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

24

IOMMU
オープンソースのHW実装（Zero-Day Labs)u

https://github.com/zero-day-labs/riscv-iommuu

これとは別にQEMUのパッチも出ている

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

25

Intel SGXのI/Oは︖ 他のCPUは︖
uuuIntel SGXu

I/Oは扱わないu

隔離メモリ領域であるEPC (Enclave Page Cache)はDMA禁⽌u

ファイルとかデータ出⼒したい場合はSealing（暗号化）してホスト側に渡す

ARM TrustZoneu

Secure World側にI/Oデバイスを配置できればその範囲内で利⽤可能（のはず）

u

デバイスドライバとかSecure Worldに配置したくなければIntel SGXと同じ扱い

AMD SEVu

仮想化技術ベースなので、そのやり⽅でI/Oも扱う（はず）

u

AMD SEV-TIO (Trusted IO)という提案もある（white paperが2023年3⽉に発⾏）
uuI/Oチャネルの暗号化ベースの隔離技術

最近提案されたIntel TDXもSEV/SEV-TIOと同じような仕組みセキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/2926

（RISC-Vではないけれど）GPUのTEE
Steps 1-4 - Defining Host Topology andNVIDIA H100
Configuring GPUs for CC Mode

The Hopper H100 CC modes, as described in “Goals for Hopper H100 Confidential
u ホスト・デバイス間の暗号化も含めた安全な通信路の確⽴

u DH鍵交換使ったりComputing” on page 13 must be configured by the hypervisor. The CPU features, alongwith the H100 software stacks, allow a combination configuration of these modes. Figure
9 illustrates an example.

u GPUそのものは、隔離したいカーネル実⾏時にはそれ専⽤
Figure 9.
Sample Node Topology using H100にロックされる

u Gravitonかな︖
u S. Volos, et al., “Graviton:Trusted execution environments
on GPUs”, OSDI 2018.

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ
Confidential Compute on NVIDIA Hopper H100

2024/1/29

27[H100CONF]より引⽤
WP-11459-001WP-11459-001 | 20

（RISC-Vではないけれど）論⽂紹介
StrongBox
S�����B��: A GPU TEE on Arm Endpoints

CCS ’22, November 7–11, 2022, Los Angeles, CA, USA.

SoftwareNormal World

Secure WorldGPU Application

Secure App

User GPU Runtime

Secure App

u Y. Deng, et al., “StrongBox: A GPU TEE on ArmSEL0EL0Hardware

CPUEndpoints”, Proc. of CCS’22, November, 2022.
EL1SEL1
u 統合型GPU (GPGPU)⽤のTEEGPUNSTask

APP

STask

Host OSGPU Driver

Task
Scheduler

MemoryManager

DMAController

MMIO

Secure OS

MMU

smc

EL2
SEL2
u ARM Cortex-Aシリーズを前提とする（HW無改造）

MMU

S-1 & S-2

u TrustZoneによるメモリの隔離
EL3

TZASC

Secure Monitor

Strongbox Runtime

GPU Guard

Task Protector

u 2段階アドレス変換の利⽤
Added/Modiﬁed

Trusted

Trust
Modules

TrustedRAM

Untrusted

CPU Access

NormalRAM

S TaskRAM

NS TaskRAM

GPU Accessu 2段階⽬の変換でページフォルトを起こして、アクセス権限のチェックを⾏う
Figure 2: S�����B�� architecture overview

u なるべく既存のデバイスドライバを利⽤する
To protect the data security in secure tasks, S�����B�� provides
trusted modules (e.g., secure boot and key management modules).

two principal components: GPU Guard and Task Protector. GPU
u GPU kernel⽤のデータはsecure側で暗号化してGuard provides a protective layer that ensures the GPU can executein isolation, and ensures that secure tasks are completed before
normal側のドライバに渡す�nal computed results are returned. Task Protector works in tandem with GPU Guard to ensure that sensitive data are protected to
セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ
provide con�dentiality. Together, these components help to ful�llour goal of isolated GPU execution and con�dential storage. Inaddition, we reuse the GPU runtime and driver software in theOS (EL1) to reduce the overall TCB size (G2). The GPU driver andruntime manage hardware resources and data transfer for bothcon�dential and non-con�dential GPU applications (EL0), while
the data security is ensured by the thin S�����B�� runtime. As aresult, our approach ensures that the GPU can execute secure tasks

4.3

Exclusivity of GPU on Critical ExecutionS�����B��’s primary security goal is to provide exclusive execution of secure GPU tasks. That is, if any secure task is executing
on the GPU, no other task can be scheduled on the GPU simultaneously. As shown in Section 3, attackers who control the GPU MMIO
can subvert the isolated execution environment. To defend against
such2024/1/29
an attacker, we adapt state-of-the-art
GPU TEEs to Arm GPU
28
devices, which requires addressing two issues. First, while existing GPU TEEs migrate heavy GPU driver code into an enclave or
TEE to control the GPU, we keep this code in the untrusted kernel,
and instead react to speci�c smc events that route control to theS�����B�� runtime. Second, we use existing Arm features to control the access of GPU hardware — speci�cally, Stage-2 translation
helps lock the system mapping of GPU MMIO registers duringcomputation. By leveraging custom smc event handlers and Stage-2

まとめu RISC-V TEEのI/Oまわりの状況を紹介
u SiFIVE WorldGuard, IOPMP, IOMMUu IOMMUに関してはQEMUのパッチも提供されている

u RISC-V以外の話題も少しだけ紹介
u 個⼈的な興味u （実⽤レベルの）ハードウェア実装はどうなるか︖
u IOMMUをサポートするPCIeのIPは誰か作るか︖

u TEE側で割り込みを低コストで扱えるか︖
u デバイスドライバは簡単な拡張ですむのか︖
セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/2929

Referencesu[Keystone] Dayeol Lee, et al., “Keystone: An Open Framework for Architecting
Trusted Execution Environments”, EuroSys’20, April, 2020u[WorldGuard] SiFive, “SiFive WorldGuard White Paper Version 1.2”, 2020u

[IOPMP] RISC-V IOPMP Task Group, “RISC-V IOPMP Architecture Specification”,
Version 1.0.0-draft5, December, 2023

u

[IOMMU] RISC-V IOMMU Task Group, “RISC-V IOMMU ArchitectureSpecification”, Version 1.0, 06/2023

u[INTERRUPT] John Hauser, “The RISC-V Advanced Interrupt Architecture”,
Version 1.0, June, 2023u

[H100CONF] NVIDIA, “Confidential Compute on NVIDIA Hopper H100”, WP11459-001, July, 2023

セキュアシステムのためのソフトウェア、アーキテクチャ、理論に関するワークショップ

2024/1/29

30