libmpk software abstraction for intel memory protection
play

LIBMPK: SOFTWARE ABSTRACTION FOR INTEL MEMORY PROTECTION KEYS (INTEL - PowerPoint PPT Presentation

LIBMPK: SOFTWARE ABSTRACTION FOR INTEL MEMORY PROTECTION KEYS (INTEL MPK) Soyeon Park, Sangho Lee, Wen Xu, Hyungon Moon and Taesoo Kim INTRODUCTION SECURITY CRITICAL MEMORY REGIONS NEED PROTECTION JIT page To achieve code execution,


  1. LIBMPK: SOFTWARE ABSTRACTION FOR INTEL MEMORY PROTECTION KEYS (INTEL MPK) Soyeon Park, Sangho Lee, Wen Xu, Hyungon Moon and Taesoo Kim

  2. INTRODUCTION SECURITY CRITICAL MEMORY REGIONS NEED PROTECTION ▸ JIT page 
 “To achieve code execution, we can simply locate one of these RWX JIT pages and overwrite it with our own shellcode.” - [1] ▸ Personal information ▸ Password ▸ Private key 
 “We confirmed that all individuals used only the Heartbleed exploit to obtain the private key.” - [2] [1] Amy Burnett, et al. “Weaponization of a Javascriptcore vulnerability” RET2 Systems Engineering Blog [2] Nick Sullivan “The Results of the CloudFlare Challenge” CloudFlare Blog

  3. INTRODUCTION EXAMPLE 1 - HEARTBLEED ATTACK P r i v a t e k e y 1000 bytes H E L L O Reply “HELLO” (1000 bytes) · · · Private key · · · · · · t s e u q e r d e e l b t r a e H y e Web Server k e t a v i r p g n i d u l c n i a t a d d e k a e L

  4. INTRODUCTION EXAMPLE 1 : EXISTING SOLUTION TO PROTECT MEMORY ▸ Process separation Process Process MEMORY MEMORY [1] Song, Chengyu, et al. "Exploiting and Protecting Dynamic Code Generation”, NDSS 2015. 
 [2] Litton, James, et al. "Light-Weight Contexts: An OS Abstraction for Safety and Performance”, OSDI 2016.

  5. INTRODUCTION EXAMPLE 2 - EXISTING SOLUTION TO PROTECT JIT PAGE ▸ JIT page W^X protection Process mprotect(W) Write code Execute Write Write mprotect(RX) Code Cache

  6. 
 INTRODUCTION PROBLEMS OF EXISTING SOLUTIONS ▸ Process Separation 
 High overhead to spawn new process and synch data ▸ W^X Protection Multiple cost to change permission of multiple pages Race condition due to permission synchronization This talk: utilizing a hardware mechanism, Intel Memory Protection Key (MPK), to address these challenges

  7. OUTLINE OUTLINE ▸ Introduction ▸ Intel MPK Explained ▸ Challenges ▸ Design ▸ Implementation ▸ Evaluation ▸ Discussion ▸ Related Work ▸ Conclusion

  8. INTEL MPK EXPLAINED OVERVIEW ▸ Support fast permission change for page groups with single instruction ▸ Fast single invocation ▸ Fast permission change for multiple pages 18 mprotect (contiguous) mprotect (sparse) 13.5 Latency (ms) mprotect Intel MPK 9 Userspace 4.5 Kernel 0 1000 6000 11000 16000 21000 26000 31000 36000 Number of pages

  9. INTEL MPK EXPLAINED UNDERLINE IMPLEMENTATION pkey 2 <- R/W pkey 2 <- R 
 32-bit register page 120 -> R/W page 120 -> R R W R W WRPKRU 16 pkeys RDPKRU pkey_mprotect Kernel ··· page # pkey perm. ··· 120 2 R/W ▸ Permissions per cpu ··· ▸ 32-bit PKRU register contains keys/perm < Page table> ▸ WRPKRU: write key/perm ▸ RDPKRU: read key/perm

  10. INTEL MPK EXPLAINED EXAMPLE - JIT PAGE W^X PROTECTION pkey = 1 function init() pkey = pkey_alloc() Grant pkey_mprotect(code_cache, len, RWX, pkey) permission PKRU Register function JIT() 1 WRPKRU(pkey, W) CODE CACHE Write code in ... W code cache RWX RWX write code cache ... WRPKRU(pkey, R) 1 Revoke function fini() permission R pkey_free(pkey)

  11. INTEL MPK EXPLAINED EXAMPLE : EXECUTABLE-ONLY MEMORY function init() pkey = pkey_alloc() pkey_mprotect(code_cache, len, RWX, pkey) pkey function JIT() WRPKRU(pkey, W) CODE CACHE ... RWX write code cache ... WRPKRU(pkey, R) function fini() pkey_free(pkey)

  12. INTEL MPK EXPLAINED EXAMPLE : EXECUTABLE-ONLY MEMORY function init() pkey = pkey_alloc() pkey_mprotect(code_cache, len, RWX, pkey) pkey function JIT() WRPKRU(pkey, W) CODE CACHE ... RWX RWX write code cache ... WRPKRU(pkey, None) function fini() pkey_free(pkey)

  13. OUTLINE OUTLINE ▸ Introduction ▸ Intel MPK Explained ▸ Challenges ▸ Non-scalable Hardware Resource ▸ Asynchronous Permission Change ▸ Design ▸ Implementation ▸ Evaluation ▸ Discussion ▸ Related Work ▸ Conclusion

  14. CHALLENGES NON-SCALABLE HARDWARE RESOURCE ▸ Only 16 keys are provided Process pkey pkey pkey 1 16 ? W W W Write code Write code Write code cache 1 cache 16 cache 17 R R R pkey pkey pkey pkey 1 2 3 4 1 2 3 4 pkey pkey 5 … 16 17 5 16

  15. CHALLENGES ASYNCHRONOUS PERMISSION CHANGE - PROS ▸ Permission change with MPK is per-thread intrinsically Process RX RX RX W RX Write Code RX Cache R Code Cache

  16. CHALLENGES ASYNCHRONOUS PERMISSION CHANGE - PROS ▸ Permission change with MPK is per-thread intrinsically Process RX RX W W pkey RX Write Code RX Cache Write R Code Cache

  17. CHALLENGES ASYNCHRONOUS PERMISSION CHANGE - CONS ▸ Permission synchronization is necessary in some context Process RX RX X W RX Write Code RX Cache pkey None Code Cache

  18. CHALLENGES ASYNCHRONOUS PERMISSION CHANGE - CONS ▸ Permission synchronization is necessary in some context Process RX RX X W RX Write Code RX Cache Read pkey None Code Cache

  19. 
 
 DESIGN REVISIT : CHALLENGES ▸ Non-scalable Hardware Resources 
 Key virtualization solve by key indirection. ▸ Asynchronous Permission Change libmpk provide permission synchronization API

  20. DESIGN KEY VIRTUALIZATION ▸ Decoupling physical keys from user interface ▸ Key indirection working like cache W W W Write Write Write code code code R R R pkey 1 pkey 16 pkey ? vkey 1 vkey 16 vkey 17 😲 Application Library 😋 Evicted pkey 1 pkey 16

  21. DESIGN INTER-THREAD PERMISSION SYNCHRONIZATION RX X RX X THREAD B THREAD A STATE : RUNNING STATE : RUNNING RUNNING SLEEP ➍ return ➌ interrupt Userspace ➊ call mpk_mprotect() Kernel task_work ➎ update PKRU (rescheduled) pkey_sync ➋ add hooks WRPKRU

  22. IMPLEMENTATION IMPLEMENTATION ▸ libmpk is written in C/C++ ▸ Userspace library : 663 LoC ▸ Kernel support : 1K LoC ▸ Permission Synchronization ▸ Kernel module for managing metadata ▸ Userspace cannot fabricate metadata 
 ‣ We open source at https://github.com/sslab-gatech/libmpk

  23. IMPLEMENTATION USE CASE - JIT PAGE W^X PROTECTION function init() vkey = libmpk_mmap(&code_cache, len, RWX) Key virtualization function JIT() libmpk_begin(vkey, W) ... CODE CACHE write code cache RWX RWX ... libmpk_end(vkey) libmpk_mprotect(vkey, X) X X X Permission synchronization X

  24. OUTLINE OUTLINE ▸ Introduction ▸ Intel MPK Explained ▸ Challenges ▸ Design ▸ Implementation ▸ Evaluation ▸ Usability ▸ Checking overhead occurred by design ▸ Use cases - applying for memory isolation and protection ▸ Discussion ▸ Related Work ▸ Conclusion

  25. EVALUATION LIBMPK IS EASY TO ADOPT ▸ OpenSSL (83 LoC) : protecting private key ▸ Memcached (117 LoC) : protecting slabs ▸ Chakracore (10 LoC) : protecting JIT pages

  26. EVALUATION LATENCY - KEY VIRTUALIZATION ▸ Cache miss costs overhead due to eviction 3.0 2.3 Miss Time ( μ s) Hit 1.5 mprotect 0.8 0.0 0 25 50 75 100 Hit rate Reasonable overhead while providing similar functionality.

  27. EVALUATION LATENCY - INTER-THREAD PERMISSION SYNCHRONIZATION mpk_mprotect ▸ Performance mprotect (4KB) mprotect (4000KB) ▸ 1,000 pages : 3.8x 40 ▸ Single page : 1.7x 30 Latency ( μ s) 20 10 0 1 5 10 15 20 25 30 35 40 Number of threads libmpk outperform mprotect regardless of the number of pages.

  28. EVALUATION FAST MEMORY ISOLATION - OPENSSL & MEMCACHED For 1GB protection : OpenSSL ▸ ▸ original vs mpk_inthread : ▸ request/sec: 0.53% ▸ 0.01% slowdown mpk_synch vs mprotect : ▸ 8.1x original mpk_inthread original libmpk mpk_synch mprotect 500 1500 375 1125 request/sec Kbyte/sec 750 250 125 375 0 0 1 2 4 8 16 32 64 128 256 5121024 250 500 750 1000 Size of each request (KB) Number of connections

  29. EVALUATION FAST AND SECURE W ⊕ X - JIT COMPILATION ▸ Chakracore mprotect-based protection ▸ Allows race-condition attack ▸ 4.39% performance improvement (31.11% at most) ▸ mprotect libmpk 1.30 Normalized Score 1.15 1.00 0.85 0.70 RICHARDS DELTABLUE CRYPTO RAYTRACE EARLEYBOYER REGEXP SPLAY SPLAYLATENCY NAVIERSTOKES PDFJS MANDREEL MANDREELLATENCY GAMEBOY CODELOAD BOX2D ZLIB TYPESCRIPT

  30. DISCUSSION DISCUSSION ▸ Rogue data cache load (Meltdown) ▸ MPK is also affected by the Meltdown attack ▸ Hardware or software-level mitigation ▸ Code reuse attack ▸ Arbitrary executed WRPKRU may break the security ▸ Applying sandboxing or control-flow integrity ▸ Protection key use-after-free ▸ pkey_free does not perfectly free the protection key ▸ Pages are still associated with the pkey after free

  31. RELATED WORK RELATED WORK ▸ ERIM [1] : Secure wrapper of MPK ▸ Shadow Stack [2] : Shadow stack protected by MPK ▸ XOM-Switch [3] : Code-reuse attack prevention with execute-only memory supported by MPK [1] Anjo Vahldiek-Oberwagner, et al. “ERIM: Secure, Efficient In-Process Isolation with Memory Protection Keys”, Security 2019 [2] Nathan Burow, et al. “Shining Light on Shadow Stacks”, Oakland 2019 [3] Mingwei Zhang, et al. “XOM-Switch: Hiding Your Code From Advanced Code Reuse Attacks in One Shot”, Black Hat Asia 2018

  32. CONCLUSION CONCLUSION ▸ libmpk is a secure, scalable, and synchronizable abstraction of MPK for supporting fast memory protection and isolation with little effort. THANKS! https://github.com/sslab-gatech/libmpk

Recommend


More recommend