Intra-process isolation:
Why we want's Intra-process isolation?
- Security reason.
- Code/Data may have security level in legency:
- a. RSA and session keys in webserver.
- b. Code pointers: may be hijacked.(Code pointer integrity)
- c. Sensitive data: if ( task_struct->is_root)
- Performance reason.
-
Why we want put multipule task into one domain:
Process-in-process: techniques for practical address-space sharing (HPDC '18) Despite architecture gain, putting multitask into one address space are mainly for fast IPC. -
But, how fast we can achieve with different address space for IPC?
SkyBridge: Fast and Secure IPC for Microkernels (EuroSys '19)
XPC: architectural support for secure and efficient cross process call (ISCA '19)Despite of limitation of these methods, even with the performance improvment on IPC, the key problem is that the number of IPC is still high, which disallow the performance to achieve as one address space method.
- The root cause of isolation: memory bugs:
SoK: Eternal War in Memory (S&P '13)
So, a memory safty domain is also isolated from the rest part of the system.
How to achieve efficient, flexible, and compatible intra-process isolation, I think, it's a building block in computer security area.
An overview about isolation in one address space, how many methods we have and how to compare them:
No Need to Hide: Protecting Safe Regions on Commodity Hardware (Eurosys '17)
- Hardware methods
-
x86 memory segment Native Client: A Sandbox for Portable, Untrusted x86 Native Code (S&P '09)
-
Page table permission extension:
-
Intel MPK (only usable in user space.)
Can we use MPK without CFI:
ERIM: Secure, Efficient in-process Isolation with Memory Protection Keys (Sec’19)Can we use MPK in kernel space:
IskiOS: Lightweight defense against kernel-level code-reuse attacks (Arxiv '2019) -
optional:
Hodor: Intra-process isolation for high-throughput data plane libraries (ATC’19)ARM DARC(deprecated on AArch64):
Domain Isolated Kernel: A lightweight sandbox for untrusted kernel extensions (C&P’18)
-
-
Memory tagging
-
Trust Execution enviroment
Secured Routines: Language-based Construction of Trusted Execution Environments (ATC '19):
- Langage based methods
- SFI
- Masking:
Evaluating SFI for a CISC Architecture (Security '06)
Adapting Software Fault Isolation to Contemporary CPU Architectures (Security '10). - Access check list: Software fault isolation with API integrity and multi-principal modules
- optional
XFI: Software guards for system address spaces (OSDI '06)
Fast byte-granularity software fault isolation (SOSP '09)
- optional
- SFI+MPX
- Masking:
- Safe language
- Rust: NetBricks: Taking the V out of NFV(OSDI’16)
- WebAssembly: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code (ATC '19)
- Singularity: Rethinking the Software Stack (OSR '07)
But,byond the memory isolation, is it enough?
Time protection: the missing OS abstraction (Eurosys '19)