Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Prototype Implementation of Non-Volatile Memory Support for RISC-V Keystone Enclave

•
•
L
LenaYu2

Handling confidential information has become an increasingly important concern among many areas of society. However, current computing environments have been still vulnerable to various threats, and we should think they are untrusted. Trusted Execution Environments (TEEs) have attracted attention because they can execute a program in a trusted environment constructed on an untrusted platform. Particularly, the RISC-V Keystone is one of the interesting TEEs since it is a flexibly customizable and fully open-source platform. On the other hand, as same as other TEEs, it must also delegate I/O processing, such as file accesses, to a host OS, resulting in the expensive overhead. For this problem, we thought utilizing byte-addressable non-volatile memory (NVM) modules is a useful solution to handle persistent data objects for TEEs. In this paper, we introduce a prototype implementation of NVM support for the Keystone. Additionally, we evaluate it on the Freedom U500 built on a VC707 FPGA dev kit. https://ken.ieice.org/ken/paper/20210720TC4K/

1 of 24
Download to read offline
Prototype Implementation of Non-Volatile Memory Support for RISC-V Keystone Enclave Lena Yu, Yu Omori, Keiji Kimura Waseda University Presented by Lena Yu SWoPP CPSY 2021 2021/7/20 SWoPP 2021 1
Introduction p Modern systems are still vulnerable to various threats n Untrusted environments should not handle confidential data p Secure computing technologies exist n Homomorphic Encryption p Computationally expensive n Trusted Execution Environment (TEE) p Low performance overhead n TEE enables secure computing on variety of platforms p However TEEs have limitations on I/O operations 2021/7/20 SWoPP 2021 2 Utilize byte-addressable non-volatile memory (NVM) modules to handle persistent data objects for TEEs
Goal of this research 2021/7/20 SWoPP 2021 3 Utilize byte-addressable non-volatile memory (NVM) modules to handle persistent data objects for TEEs Enable NVMM accesses from an enclave application in Keystone TEE Make modifications to the Keystone Runtime to add page table management for the NVMM Use two different free lists to distinguish between DRAM and NVMM free memory As a tentative design, File Descriptor (fd) is used to distinguish mmap and munmap between DRAM and NVMM fd = -1 for DRAM fd = -2 for NVMM As a first step in achieving this goal
What is a TEE? p TEE generally divides system into separate regions n Untrusted area n Trusted area p Contains the TEE, code and data inside is relatively secure compared to the untrusted p Sometimes referred to as an Enclave p There exist multiple TEE implementations n Intel SGX n ARM TrustZone n RISC-V Keystone 2021/7/20 SWoPP 2021 4
Limitations of a TEE p Delegates I/O operations to the untrusted OS n Enclave program unable to handle I/O operations p Including file system accesses n Causes additional overhead n Poses a security risk p Untrusted OS can momentarily access sensitive data 2021/7/20 SWoPP 2021 5 Introduce byte-accessible non-volatile memory as a main memory (NVMM) in TEE to overcome these limitations
How might a NVMM overcome the limitations? p CPU can store persistent data objects n Only requires ordinary load and store instructions n No need to use complicated runtime software in a TEE for management p Host kernel does not intervene during I/O operation n Ensures only the TEE can touch sensitive data n As long as the page table for NVMM is prepared 2021/7/20 SWoPP 2021 6
Keystone TEE p Open-source project for building customizable TEE based on RISC-V n Provides building blocks for creating a custom TEE n TEEs can be created with only the required functionality p Reduces Trusted Computing Base (TCB) → Fully open-source, can be modified to allow NVMM usage 2021/7/20 SWoPP 2021 7
Layered Keystone Architecture p U-Mode n Enclave Application (Eapp) n Host Application p S-Mode n Enclave Runtime p Modified for the implementation n Host OS p M-Mode n Security Monitor (SM) p Trusted Hardware n RISC-V Core n Optional Hardware features n Root of Trust 2021/7/20 SWoPP 2021 8 High Privilege Low Privilege
Security Monitor (SM) p SM responsible for most security guarantees of Keystone TEE p RISC-V primitive Physical Memory Protection (PMP) n Used to enforce memory isolation by SM n PMP can grant/revoke access permissions n S-Mode and U-Mode have no permissions by default n M-Mode have full permissions by default p PMP entries prioritized by index n Highest priority PMP[0] used for SM p SM responsible for managing PMP n Next highest priority PMP[1] used for enclave n Lowest priority PMP[N-1] used for shared memory 2021/7/20 SWoPP 2021 9
Runtime (RT) p Each enclave has its own RT, acts like the enclaveʼs kernel n Manages enclave memory p Memory isolated by PMP p OS cannot access enclave memory n Implements enclave functionality p Customizable enclave functionality provided in the form of plugins n Free memory n Edge call interface 2021/7/20 SWoPP 2021 10
Free memory (Freemem) p Freemem is reserved physical memory area by enclave n This memory does not have to be mapped at time of creation p Allows RT to perform page table changes p Mmap from Eapp utilizes Free pages in Freemem → Required for DRAM and NVMM page table management 2021/7/20 SWoPP 2021 11 Enclave memory before modification Enclave memory after modification
Edge Calls and System calls p Interface that allows function calls to cross in or out of enclaves p Outbound Call (ocall) n Function call that crosses out of the enclave into host p Eapp can invoke a function inside host n Shared memory used for copying between host and enclave p System calls n Some syscalls (mmap, munmap, brk) are handled in Enclave RT n Some syscalls forwarded from Enclave to host OS through ocall 2021/7/20 SWoPP 2021 12
Enclave Lifecycle p Three distinct phases in Enclave lifecycle 2021/7/20 SWoPP 2021 13 Invalid Allocated Fresh Running Stopped Destroying CREATE CREATE EXECUTE EXIT/STOP DESTROY DESTROY DESTROY Create • Host allocates contiguous range of physical memory for enclave • Enclave page tables, RT, Eapp initialized • PMP entry set for enclave memory, status propagated through cores Execute • SM releases PMP permission to core containing enclave, and enters enclave • Includes RT boot • Page table management is done in Running state Destroy • Clears enclave memory • Releases PMP entry • Returns memory to host • SM cleans and frees all enclave resources, PMP entries, enclave metadata Benchmark these to measure initialization, preparation and clearing overhead of NVMM page table and Freemem
Original RT Memory Management p Sv39 addressing mode used p 3-level page table n Root Page Table, Kernel L2, L3, DRAM L2, L3 p Memory is prepared during RT boot n Creation of Page Table entries p Create root page table entry, Kernel L2 entries, and Kernel L3 entries p Create root page table entry, DRAM L2 entries, and DRAM L3 entries n Freemem initialization p All free pages of DRAM put inside free list p Simple Page Allocator (SPA) stores pages based on linked list 2021/7/20 SWoPP 2021 14
Prototype RT Memory Management for NVMM support p Modified to allow mapping to the NVMM p NVMM L2, L3 page tables added n Initialized and managed similarly to DRAM L2, L3 n Create root page table entry, NVMM L2 entries, and NVMM L3 entries p DRAM and NVMM free lists are used p Memory composition for testing n Entirety of NVMM region given to NVMM Freemem n DRAM and NVMM regions are contiguous 2021/7/20 SWoPP 2021 15
Mapping from the Eapp p Mmap from Eapp n RT only supports anonymous mapping n RT checks performed p Checks continuous virtual address space that fits required size p Checks DRAM/NVMM free list for number of pages available v fd = -1 for DRAM v fd = -2 for NVMM (tentative design for implementation) p Maps from DRAM/NVMM Freemem n Walks page table to find page table entry p Mapping is created if non-existent p Munmap from Eapp n Pages are freed and put back into DRAM/NVMM free list 2021/7/20 SWoPP 2021 16
Testing the implementation p First tested if modified Keystone works n Confirmed write/read works for the DRAM and NVMM mmap regions p Benchmarks n Ocall overhead n Mmap 5 pages from DRAM n Mmap 5 pages from NVMM n Munmap 5 pages from DRAM n Munmap 5 pages from NVMM n Enclave creation and destruction n RT boot time 2021/7/20 SWoPP 2021 17
FPGA used for Experimental Evaluation p Test executed on a Freedom U500 VC707 FPGA Dev Kit 2021/7/20 SWoPP 2021 18
Test Eapp p Clock function in the host used to measure Clock Cycles n Eapp uses Ocall to start/stop clock function 2021/7/20 SWoPP 2021 19 Prints string in host Fd to distinguish between DRAM and NVMM mmap Shared Memory Eapp ocall_measure_clock(x) Enclave Untrusted Trusted OS ocall_print_string(xxxx) Output Runtime Clock Cycles is XXX Enclave said: “mmap into DRAM region successful” Clock Cycles is XXX Enclave said: “mmap into NVM region successful” print_string() clock_start() clock_stop() mmap_dram() mmap_nvm()
Results p The test app was executed 10 times on the board, and average is taken 2021/7/20 SWoPP 2021 20
Discussion p NVM emulator uses part of DRAM region n Timing parameters of NVM region set to same as DRAM n Test overhead due to RT modification p Clock Cycle increase in operations after modifying the RT n Ocall had 1.66% increase n mmap had 0.274% increase n munmap had 0.585% increase n RT boot had 0.822% increase p Additional page table p Initialization of NVMM Freemem alongside DRAM Freemem n Enclave creation had 1.04% increase n Enclave destruction had 0.0894% increase p No significant increase in Clock Cycles due to RT modifications 2021/7/20 SWoPP 2021 21
Limitations p Ocall overhead is large n Multiple context switching between Enclave and host n Shared memory copy operations n Difficult to make precise measurements p NVMM region set to be contiguous with DRAM region n Unrealistic for them to be contiguous n Keystoneʼs only support contiguous enclave memory 2021/7/20 SWoPP 2021 22
Related Works p Trusted I/O path in a TEE n Secure execution environment in TEE not enough n Allow secure communication between TEE and peripherals p Generic trusted path architecture in Intel SGX n Intel SGX does not support secure I/O and syscall n Allow trusted paths to generic I/O devices p Secure Storage models for TrustZone n Secure storage of private files using encryption 2021/7/20 SWoPP 2021 23
Conclusion p Implemented a prototype NVMM support for RISC-V Keystone n Modified RT to mmap into DRAM and NVMM regions n Modified RT did not have a significant impact on the operations p Future work n Test implementation on NVMM emulator with appropriate latencies n Design persistent data management on the NVMM and OS n Investigate overhead associated with multi-core PMP synchronization 2021/7/20 SWoPP 2021 24

More Related Content

Prototype Implementation of Non-Volatile Memory Support for RISC-V Keystone Enclave

  • 1. Prototype Implementation of Non-Volatile Memory Support for RISC-V Keystone Enclave Lena Yu, Yu Omori, Keiji Kimura Waseda University Presented by Lena Yu SWoPP CPSY 2021 2021/7/20 SWoPP 2021 1
  • 2. Introduction p Modern systems are still vulnerable to various threats n Untrusted environments should not handle confidential data p Secure computing technologies exist n Homomorphic Encryption p Computationally expensive n Trusted Execution Environment (TEE) p Low performance overhead n TEE enables secure computing on variety of platforms p However TEEs have limitations on I/O operations 2021/7/20 SWoPP 2021 2 Utilize byte-addressable non-volatile memory (NVM) modules to handle persistent data objects for TEEs
  • 3. Goal of this research 2021/7/20 SWoPP 2021 3 Utilize byte-addressable non-volatile memory (NVM) modules to handle persistent data objects for TEEs Enable NVMM accesses from an enclave application in Keystone TEE Make modifications to the Keystone Runtime to add page table management for the NVMM Use two different free lists to distinguish between DRAM and NVMM free memory As a tentative design, File Descriptor (fd) is used to distinguish mmap and munmap between DRAM and NVMM fd = -1 for DRAM fd = -2 for NVMM As a first step in achieving this goal
  • 4. What is a TEE? p TEE generally divides system into separate regions n Untrusted area n Trusted area p Contains the TEE, code and data inside is relatively secure compared to the untrusted p Sometimes referred to as an Enclave p There exist multiple TEE implementations n Intel SGX n ARM TrustZone n RISC-V Keystone 2021/7/20 SWoPP 2021 4
  • 5. Limitations of a TEE p Delegates I/O operations to the untrusted OS n Enclave program unable to handle I/O operations p Including file system accesses n Causes additional overhead n Poses a security risk p Untrusted OS can momentarily access sensitive data 2021/7/20 SWoPP 2021 5 Introduce byte-accessible non-volatile memory as a main memory (NVMM) in TEE to overcome these limitations
  • 6. How might a NVMM overcome the limitations? p CPU can store persistent data objects n Only requires ordinary load and store instructions n No need to use complicated runtime software in a TEE for management p Host kernel does not intervene during I/O operation n Ensures only the TEE can touch sensitive data n As long as the page table for NVMM is prepared 2021/7/20 SWoPP 2021 6
  • 7. Keystone TEE p Open-source project for building customizable TEE based on RISC-V n Provides building blocks for creating a custom TEE n TEEs can be created with only the required functionality p Reduces Trusted Computing Base (TCB) → Fully open-source, can be modified to allow NVMM usage 2021/7/20 SWoPP 2021 7
  • 8. Layered Keystone Architecture p U-Mode n Enclave Application (Eapp) n Host Application p S-Mode n Enclave Runtime p Modified for the implementation n Host OS p M-Mode n Security Monitor (SM) p Trusted Hardware n RISC-V Core n Optional Hardware features n Root of Trust 2021/7/20 SWoPP 2021 8 High Privilege Low Privilege
  • 9. Security Monitor (SM) p SM responsible for most security guarantees of Keystone TEE p RISC-V primitive Physical Memory Protection (PMP) n Used to enforce memory isolation by SM n PMP can grant/revoke access permissions n S-Mode and U-Mode have no permissions by default n M-Mode have full permissions by default p PMP entries prioritized by index n Highest priority PMP[0] used for SM p SM responsible for managing PMP n Next highest priority PMP[1] used for enclave n Lowest priority PMP[N-1] used for shared memory 2021/7/20 SWoPP 2021 9
  • 10. Runtime (RT) p Each enclave has its own RT, acts like the enclaveʼs kernel n Manages enclave memory p Memory isolated by PMP p OS cannot access enclave memory n Implements enclave functionality p Customizable enclave functionality provided in the form of plugins n Free memory n Edge call interface 2021/7/20 SWoPP 2021 10
  • 11. Free memory (Freemem) p Freemem is reserved physical memory area by enclave n This memory does not have to be mapped at time of creation p Allows RT to perform page table changes p Mmap from Eapp utilizes Free pages in Freemem → Required for DRAM and NVMM page table management 2021/7/20 SWoPP 2021 11 Enclave memory before modification Enclave memory after modification
  • 12. Edge Calls and System calls p Interface that allows function calls to cross in or out of enclaves p Outbound Call (ocall) n Function call that crosses out of the enclave into host p Eapp can invoke a function inside host n Shared memory used for copying between host and enclave p System calls n Some syscalls (mmap, munmap, brk) are handled in Enclave RT n Some syscalls forwarded from Enclave to host OS through ocall 2021/7/20 SWoPP 2021 12
  • 13. Enclave Lifecycle p Three distinct phases in Enclave lifecycle 2021/7/20 SWoPP 2021 13 Invalid Allocated Fresh Running Stopped Destroying CREATE CREATE EXECUTE EXIT/STOP DESTROY DESTROY DESTROY Create • Host allocates contiguous range of physical memory for enclave • Enclave page tables, RT, Eapp initialized • PMP entry set for enclave memory, status propagated through cores Execute • SM releases PMP permission to core containing enclave, and enters enclave • Includes RT boot • Page table management is done in Running state Destroy • Clears enclave memory • Releases PMP entry • Returns memory to host • SM cleans and frees all enclave resources, PMP entries, enclave metadata Benchmark these to measure initialization, preparation and clearing overhead of NVMM page table and Freemem
  • 14. Original RT Memory Management p Sv39 addressing mode used p 3-level page table n Root Page Table, Kernel L2, L3, DRAM L2, L3 p Memory is prepared during RT boot n Creation of Page Table entries p Create root page table entry, Kernel L2 entries, and Kernel L3 entries p Create root page table entry, DRAM L2 entries, and DRAM L3 entries n Freemem initialization p All free pages of DRAM put inside free list p Simple Page Allocator (SPA) stores pages based on linked list 2021/7/20 SWoPP 2021 14
  • 15. Prototype RT Memory Management for NVMM support p Modified to allow mapping to the NVMM p NVMM L2, L3 page tables added n Initialized and managed similarly to DRAM L2, L3 n Create root page table entry, NVMM L2 entries, and NVMM L3 entries p DRAM and NVMM free lists are used p Memory composition for testing n Entirety of NVMM region given to NVMM Freemem n DRAM and NVMM regions are contiguous 2021/7/20 SWoPP 2021 15
  • 16. Mapping from the Eapp p Mmap from Eapp n RT only supports anonymous mapping n RT checks performed p Checks continuous virtual address space that fits required size p Checks DRAM/NVMM free list for number of pages available v fd = -1 for DRAM v fd = -2 for NVMM (tentative design for implementation) p Maps from DRAM/NVMM Freemem n Walks page table to find page table entry p Mapping is created if non-existent p Munmap from Eapp n Pages are freed and put back into DRAM/NVMM free list 2021/7/20 SWoPP 2021 16
  • 17. Testing the implementation p First tested if modified Keystone works n Confirmed write/read works for the DRAM and NVMM mmap regions p Benchmarks n Ocall overhead n Mmap 5 pages from DRAM n Mmap 5 pages from NVMM n Munmap 5 pages from DRAM n Munmap 5 pages from NVMM n Enclave creation and destruction n RT boot time 2021/7/20 SWoPP 2021 17
  • 18. FPGA used for Experimental Evaluation p Test executed on a Freedom U500 VC707 FPGA Dev Kit 2021/7/20 SWoPP 2021 18
  • 19. Test Eapp p Clock function in the host used to measure Clock Cycles n Eapp uses Ocall to start/stop clock function 2021/7/20 SWoPP 2021 19 Prints string in host Fd to distinguish between DRAM and NVMM mmap Shared Memory Eapp ocall_measure_clock(x) Enclave Untrusted Trusted OS ocall_print_string(xxxx) Output Runtime Clock Cycles is XXX Enclave said: “mmap into DRAM region successful” Clock Cycles is XXX Enclave said: “mmap into NVM region successful” print_string() clock_start() clock_stop() mmap_dram() mmap_nvm()
  • 20. Results p The test app was executed 10 times on the board, and average is taken 2021/7/20 SWoPP 2021 20
  • 21. Discussion p NVM emulator uses part of DRAM region n Timing parameters of NVM region set to same as DRAM n Test overhead due to RT modification p Clock Cycle increase in operations after modifying the RT n Ocall had 1.66% increase n mmap had 0.274% increase n munmap had 0.585% increase n RT boot had 0.822% increase p Additional page table p Initialization of NVMM Freemem alongside DRAM Freemem n Enclave creation had 1.04% increase n Enclave destruction had 0.0894% increase p No significant increase in Clock Cycles due to RT modifications 2021/7/20 SWoPP 2021 21
  • 22. Limitations p Ocall overhead is large n Multiple context switching between Enclave and host n Shared memory copy operations n Difficult to make precise measurements p NVMM region set to be contiguous with DRAM region n Unrealistic for them to be contiguous n Keystoneʼs only support contiguous enclave memory 2021/7/20 SWoPP 2021 22
  • 23. Related Works p Trusted I/O path in a TEE n Secure execution environment in TEE not enough n Allow secure communication between TEE and peripherals p Generic trusted path architecture in Intel SGX n Intel SGX does not support secure I/O and syscall n Allow trusted paths to generic I/O devices p Secure Storage models for TrustZone n Secure storage of private files using encryption 2021/7/20 SWoPP 2021 23
  • 24. Conclusion p Implemented a prototype NVMM support for RISC-V Keystone n Modified RT to mmap into DRAM and NVMM regions n Modified RT did not have a significant impact on the operations p Future work n Test implementation on NVMM emulator with appropriate latencies n Design persistent data management on the NVMM and OS n Investigate overhead associated with multi-core PMP synchronization 2021/7/20 SWoPP 2021 24