Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Intel MPK入門

Intel MPK入門

B83842a07c4241e2aec3e2dfeedf16fe?s=128

Keisuke Nishimura

March 21, 2021
Tweet

Transcript

  1. Intel MPK入門 Kernel/VM 探検隊 online Part.2 mumumu / 西村 啓佑

    ← Twitter: @mumumu_vm ※マサカリ,ツッコミ,質問等はTwitterまで!
  2. 発表内容 - Intel MPKの概要 - Intel MPK対応のソフトウェア - 独断と偏見で選んだIntel MPK関連研究

    2
  3. Intel MPK(Memory Protection Keys) とは? プロセス内のメモリアクセス権限を効率的に制御する仕組み - メモリのアクセス権限の制御? - 従来:Page

    Tableの設定 = アクセス権限の設定 - MPK:PTを拡張し,新たな方法で権限の制御が可能 - 効率的? - アクセス権限設定は従来からPage Tableを設定することでできる が,コンテキストスイッチやTLBINV発生 - MPKはRing 3にいながらアクセスできる範囲を設定可能 3
  4. 従来: mprotect()等を用いたメモリアクセス権限制御 4 RW- R-- RW- R-X R-- RW- ---

    RW- R-X R-- RW- --- RW- R-X --- mprotect() mprotect() Page Tableを書換える為 要コンテキストスイッチ メモリ空間
  5. MPKを用いたメモリアクセス権限制御 wrpkru(各Keyへの アクセス権限) 5 RW- R-- RW- R-X R-- Pkey

    0 Pkey 1 Pkey 2 RW- --- RW- R-X --- 予めPage Tableに 属性(Pkey)を設定 レジスタの書換えのみ ユーザランドで実行可能
  6. 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) = --
  7. 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
  8. アクセス制御: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で許可できない.
  9. アクセス制御: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で許可できない.
  10. アクセス制御: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を使用
  11. SWのサポート状況:Linux - 4.6 ~ MPKのサポートを開始 - cpuid のサポートなど?(/proc/cpuのflagのpku参照) - 4.9

    ~ ユーザが使えるシステムコールを提供開始 - pkey_alloc()/pkey_free(): pkeyの管理 - pkey_mprotect() = mprotect() + pkey 11 基本的に初期化で使用
  12. 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をセット
  13. SWのサポート状況:glibc - 2.27~ PKRUを読み書きするwrpkru/rdpkruのラッパを提供 13

  14. SWのサポート状況:アプリケーション - 研究レベル - Nojitsu[NDSS ‘20]: JITエンジンの一部 - libmpk[ATC ‘19]:

    MPK汎用ライブラリ,OpenSSLに適用 - 調査した限りアプリケーション側ではほとんど導入されていな い? - 情報募集中 - 難しさ:メモリのアクセス制御はそのソフトウェアのメモリ管理方 法やSWアーキテクチャに直接影響 - 既存のソフトウェアをMPK対応するのは困難? 14
  15. Intel MPKの効率性について libmpk[ATC ‘19]より引用 15

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

    + 23 * 2 < 1094*2
  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に行う等の工夫 17
  18. 研究: 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とかも併用してね☆彡)
  19. 研究: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
  20. 研究:ERIM[Usenix Security ‘19] NGINXの性能はNativeの95%程度 もちろん性能はApp依存 DEPが存在することが前提 =JITエンジンとか難しい? 20

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

  22. 参考 - 関連トピック 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
  23. まとめ - MPK:効率的なプロセス内のメモリアクセス権限制御 - Ring 3で動作するため,mprotect()等よりも高速 - Linuxでは以前からサポートされているが,実際に使われてい るか不明? -

    これからの応用研究・開発に期待 23 岡本拓也(@hei_nyan) さん,服部穣 さん にフィードバックを頂きました.ありがとうございました.
  24. 参考文献 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