2016 CCS SMV
Questions
How to determine and represent boundaries?
Which level of the page is tagged? Virtual or Physical?
- ANS: virtual page is tagged with permissions. Memory protection domain is defined as a countigous range of virtual memory.
How to design a secure call gate to cross boundaries?
How many compartments in the benchmarks?
Reference 1
3 generations of privilege separation
1st gen: split a process into different single-process compartments. e.g. OpenSSH by Provos et al., Privtrans, Wedge2 introduced capabilities, Salus3 introduced dynamic security policy.
2nd gen: isolation in multi-threaded applications. Arbiter4, global barrier to tag memory pages for capabilities; human retrofitting efforts are non-trivial.
3nd gen: secure memory views (SMV) for monolithic applications: a model and architecture that efficiently enforces differential security and fault isolation policies in monolithic multithreaded applications at negligible overheads.
Evaluation
| Benchmark | LoC | Overhead |
|---|---|---|
| PARSEC | 2 | 2% |
| Cherokee | 2 | 0.69% |
| Apache httpd | 2 | 0.93% |
| Firefox | 12 | 1.89% |
SMV model
Three abstractions: memory protection domains, secure memory views (SMVs), SMVthreads,
Memory protection domain
A contiguous range of virtual memory.
Secure Memory Views (SMVs)
A thread container, which maintains a collection of memory protection domains for each SMVthreads in the container. Each SMVthreads must follow the privilege settings in SMV.
Focused on restricting memory views for individual threads, and had no control over the accessing permissions for kernel APIs.
Kernel enforcement
Entire kernel is trusted in this paper.
SMV kernel module. exchanging messages between the user space and kernel memory management subsystem. Implemented using Netlink socket family.
Kernel memory management subsystem changes:
- added SMV metadata management, to record the memory access privileges for the SMVs.
memdom_struct: metadata for tracing the virtual memory area and the memory domains mappings.SMV_struct: SMV privilege metadata for accessing memory domains.
- modified page table management logic, to support partially shared page tables.
- added additional checks in the page fault handler (section 4.5). The fault address must be in a valide memory domain with proper access permission in the current SMVThread.
Partially shared memory space
Separates the memory space of SMVs by using a page global directory (pgd_t) for each SMV.
loads thread-private pgd_t into the CR3 register during a context switch.
==> different page table map for same address space ==> overhead?
User space library
memdom_create to create a memory domain.
memdom_alloc to allocate memory blocks private to SMVthreads.
memdom_priv_grant to grant an SMV the privileges to access a memory domain.
memdom_priv_revoke to revoke the privileges to access a memory domain from an SMV.
CMTS
Weaknesses:
The way to determine the boundaries is largely depends on the human understanding of the program’s functionalities.
Kernel has to be trusted. Isolation only works for user space applications. No isolation inside kernrel.
Compatibility: original pthreads assumes sharing of all pages, but SMVthreads assumes all pages as private and require explicit sharing with other SMVthreads. Using SMVthreads increases the burden on developers to setup the correct page sharing. Sometime it can be hard to reason about which page should be shared and which shouldn’t, especially when it comes to data being pointed to by pointer variables and those passed around by third party libraries.
Overhead/Scalability: use different page table directory for different threads and switch page table during thread switch, this is conceptually constructing a heavy weight thread to be much like a process. If the number of threads goes up, the performance is likely to drop dramatically because of context switch and synchronization of shared page mappings.
- Hsu, Terry Ching-Hsiang, Kevin Hoffman, Patrick Eugster, and Mathias Payer. “Enforcing least privilege memory views for multithreaded applications.” In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 393-405. 2016. ↩
- A. Bittau, P. Marchenko, M. Handley, and B. Karp. Wedge: Splitting Applications into Reduced-privilege Compartments. In Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation, NSDI’08, pages 309–322, Berkeley, CA, USA, 2008. USENIX Association. ↩
- R. Strackx, P. Agten, N. Avonds, and F. Piessens. Salus: Kernel Support for Secure Process Compartments. EAI Endorsed Transactions on Security and Safety, 15(3), 1 2015. ↩
- J. Wang, X. Xiong, and P. Liu. Between Mutual Trust and Mutual Distrust: Practical Fine-grained Privilege Separation in Multithreaded Applications. In 2015 USENIX Annual Technical Conference (USENIX ATC 15), pages 361–373, Santa Clara, CA, July 2015. USENIX Association. ↩
If you could revise
the fundmental principles of
computer system design
to improve security...
... what would you change?