Intel MPK入門 Kernel/VM 探検隊 online Part.2 mumumu / 西村 啓佑 ← Twitter: @mumumu_vm ※マサカリ，ツッコミ，質問等はTwitterまで！

発表内容 - Intel MPKの概要 - Intel MPK対応のソフトウェア - 独断と偏見で選んだIntel MPK関連研究 2

Intel MPK(Memory Protection Keys) とは？ プロセス内のメモリアクセス権限を効率的に制御する仕組み - メモリのアクセス権限の制御? - 従来：Page Tableの設定 = アクセス権限の設定 - MPK：PTを拡張し，新たな方法で権限の制御が可能 - 効率的？ - アクセス権限設定は従来からPage Tableを設定することでできる が，コンテキストスイッチやTLBINV発生 - MPKはRing 3にいながらアクセスできる範囲を設定可能 3

従来: mprotect()等を用いたメモリアクセス権限制御 4 RW- R-- RW- R-X R-- RW- --- RW- R-X R-- RW- --- RW- R-X --- mprotect() mprotect() Page Tableを書換える為 要コンテキストスイッチ メモリ空間

MPKを用いたメモリアクセス権限制御 wrpkru(各Keyへの アクセス権限) 5 RW- R-- RW- R-X R-- Pkey 0 Pkey 1 Pkey 2 RW- --- RW- R-X --- 予めPage Tableに 属性(Pkey)を設定 レジスタの書換えのみ ユーザランドで実行可能

Intel MPKの実態 (ref. Intel SDM vol3) 1. Page Tableの設定の拡張 各PTエントリは0-15いずれかのPkeyに対応 2. PKRUレジスタ（Appが触れるレジスタでwrpkruで設定） プロセスの各Pkeyに対するアクセス権限を設定 6 (AD,WD) (0,0) = rw (0,1) = r- (1,0) = -- (1,1) = --

Intel MPKの実態 (ref. Intel SDM vol3) 1. Page Tableの設定の拡張 各PTエントリは0-15いずれかのPkeyに対応 2. PKRUレジスタ（Appが触れるレジスタでwrpkruで設定） プロセスの各Pkeyに対するアクセス権限を設定 7 (AD,WD) (0,0) = rw (0,1) = r- (1,0) = -- (1,1) = -- 2^4 = 16 keyのいずれかを 登録することが可能 32bit = 2bit * 16 key

アクセス制御：PTの設定 + PKRU = アクセス権限 8 対応するPage Table のアクセス権限 対応するPkey のアクセス権限 実際のアクセス権限 RWX Access Disable = 0 Write Disable = 1 R-X RW- Access Disable = 1 Write Disable = 0 --- R-- Access Disable = 0 Write Disable = 0 R-- RWX Access Disable = 1 Write Disable = 1 --X Page Tableで許可されていないアクセスはMPKで許可できない．

アクセス制御：PTの設定 + PKRU = アクセス権限 9 対応するPage Table のアクセス権限 対応するPkey のアクセス権限 実際のアクセス権限 RWX Access Disable = 0 Write Disable = 1 R-X RW- Access Disable = 1 Write Disable = 0 --- R-- Access Disable = 0 Write Disable = 0 R-- RWX Access Disable = 1 Write Disable = 1 --X Page Tableで許可されていないアクセスはMPKで許可できない．

アクセス制御：PTの設定 + PKRU = アクセス権限 10 対応するPage Table のアクセス権限 対応するPkey のアクセス権限 実際のアクセス権限 RWX Access Disable = 0 Write Disable = 1 R-X RW- Access Disable = 1 Write Disable = 0 --- R-- Access Disable = 0 Write Disable = 0 R-- RWX Access Disable = 1 Write Disable = 1 --X Page Tableで許可されていないアクセスはMPKで許可できない． 面白ポイント： mprotect()でPROT_EXECのみを 指定すると内部でMPKを使用

SWのサポート状況：Linux - 4.6 ~ MPKのサポートを開始 - cpuid のサポートなど？(/proc/cpuのflagのpku参照) - 4.9 ~ ユーザが使えるシステムコールを提供開始 - pkey_alloc()/pkey_free(): pkeyの管理 - pkey_mprotect() = mprotect() + pkey 11 基本的に初期化で使用

SWのサポート状況：Linux - 4.6 ~ MPKのサポートを開始 - cpuid のサポートなど？(/proc/cpuのflagのpku参照) - 4.9 ~ ユーザが使えるシステムコールを提供開始 - pkey_alloc()/pkey_free(): pkeyの管理 - pkey_mprotect() = mprotect() + pkey 12 基本的に初期化で使用 Kernel内部のbitmap構造体を参照 して1pkey(1bit分)を確保するだけ Page TableのProt. Keyに引数のPkeyをセット

SWのサポート状況：glibc - 2.27~ PKRUを読み書きするwrpkru/rdpkruのラッパを提供 13

SWのサポート状況：アプリケーション - 研究レベル - Nojitsu[NDSS ‘20]: JITエンジンの一部 - libmpk[ATC ‘19]: MPK汎用ライブラリ，OpenSSLに適用 - 調査した限りアプリケーション側ではほとんど導入されていな い？ - 情報募集中 - 難しさ：メモリのアクセス制御はそのソフトウェアのメモリ管理方 法やSWアーキテクチャに直接影響 - 既存のソフトウェアをMPK対応するのは困難？ 14

Intel MPKの効率性について libmpk[ATC ‘19]より引用 15

Intel MPKの効率性について libmpk[ATC ‘19]より引用 16 2回以上アクセス権限を変更 するならMPKの方が高速(雑見積) (183 + 1104) + 23 * 2 < 1094*2

研究： libmpk[ATC ‘19] 概要：高機能なMPKのライブラリを作る研究 - HWではPkeyの数は16に制限されているが，SWレイヤで仮 想化することでAppから見て16以上のPkeyをサポート - ↑と同時に，KeyのUse-after-free攻撃のMitigation - pkey_free()はPTに設定されたPkeyを変更しない． - HWのpkeyとlibmpkが仮想化したPkeyは異なることを利用 - mprotect()のように，プロセス(×スレッド)粒度でKey管理 - 同期はLazyに行う等の工夫 17

研究： libmpk[ATC ‘19] 概要：高機能なMPKのライブラリを作る研究 - HWではPkeyの数は16に制限されているが，SWレイヤで仮 想化することでAppから見て16以上のPkeyをサポート - ↑と同時に，KeyのUse-after-free攻撃のMitigation - pkey_free()はPTに設定されたPkeyを変更しない． - HWのpkeyとlibmpkが仮想化したPkeyは異なることを利用 - mprotect()のように，プロセス(×スレッド)粒度でKey管理 - 同期はLazyに行う等の工夫 18 制御が乗っ取られて，意図しないwrpkruを実行され ないことが前提(CFIとかも併用してね☆彡)

研究：ERIM[Usenix Security ‘19] 概要：(1) UntrustedなApp componentをMPKでIsolation (2) その実行可能ページをスキャンしてwrpkru命令列等の出現の 書き換えを行うことで乗っ取りに対し堅牢化 - x86-64の命令はかなり複雑で，他の命令の一部かも...? - WRPKRU - 0x0F01EF / XRSTOR - 0xFAE[2|6|A][8-F] - 書換え戦略：ディスアセンブルしてよしなに(Ad-hoc?) - 本当にうまくいくか心配だが，そもそも上の命令列が出てくるこ とは稀らしい(1213 occurrences / 204,370 bin.s) 19

研究：ERIM[Usenix Security ‘19] NGINXの性能はNativeの95%程度 もちろん性能はApp依存 DEPが存在することが前提 =JITエンジンとか難しい？ 20

研究：libhermitmpk[VEE ‘20] 概要：Unikenrelの内部をMPKでIsolation 注) Kernel/User Modeどちらで動作していても，ページテーブル でU bitが指定されていればMPKは有効 21 ※元になったUnikernelのRustyHermitはRust製らしい

参考 - 関連トピック 1. HW-based a. ARM Memory Domains i. Context SwitchというかSystemcallが必要? ii. 同じく16 Domainに限定 b. VM-FUNC i. Ring0にいながら，EPTを切り替え ii. VM-introspection等に応用可能 2. SW-based a. Software Fault Isolation i. 言語・ランタイムレベルでInstrumentation b. 各種プログラミング言語のメモリ抽象化機能 22

まとめ - MPK：効率的なプロセス内のメモリアクセス権限制御 - Ring 3で動作するため，mprotect()等よりも高速 - Linuxでは以前からサポートされているが，実際に使われてい るか不明？ - これからの応用研究・開発に期待 23 岡本拓也(@hei_nyan) さん，服部穣 さん にフィードバックを頂きました．ありがとうございました．

参考文献 Nojitsu[NDSS ‘20] Park, Taemin, et al. "Nojitsu: Locking down javascript engines." Symposium on Network and Distributed System Security (NDSS). 2020. libmpk[ATC ‘19] Park, Soyeon, et al. "libmpk: Software abstraction for intel memory protection keys (intel MPK)." USENIX ATC . 2019. ERIM[Usenix Security ‘19] Vahldiek-Oberwagner, Anjo, et al. "ERIM: Secure, efficient in-process isolation with protection keys (MPK)”.USENIX Security 19. 2019. libhermitmpk[VEE ‘20] Sung, Mincheol, et al. "Intra-unikernel isolation with intel memory protection keys." VEE. 2020. 24