Process abstraction 문서 원본 보기

[[분류:스레드/프로세스]]

==개요==
프로세스 추상화는 [[Isolation]], [[Protection]], 그리고 실행의 [[추상화]]이다. 메모리 분리, 권한 분리, 그리고 여러 다른 프로그램의 동시 실행을 보장하기 위해서 Modern operating system들은 기본적으로 Process abstraction을 [[운영체제]]의 기본 설계 디자인에 포함하고 있다.

프로세스 추상화는 위의 이점을 제공하기도 하나, [[Context switching]], [[IPC]], [[Scheduler]], [[Resource accounting]]과 같은 오버헤드를 동반한다. 특히 대부분의 오버헤드를 차지하는 것은 커널 [[소프트웨어]] 파트로, [[하드웨어]]부분도 일정 오버헤드가 일어나기는 하나, 소프트웨어 파트에 비하면 크게 작다.

따라서 컴퓨팅 시스템 연구에서는 Process abstraction의 한계를 극복하기 위한 다양한 연구들이 수행되고 있다. 본 문서는 이러한 연구를 정리한다.

==연구 방향==

=== Usages ===
Process abstraction sub-protection의 목적은 크게 2가지로 분류 가능하다. [[Operating System Support for Safe and Efﬁcient Auxiliary Execution|Orbit]]에서는 추가로 Maintenance라는 Protection senario를 추가하였다.

*Extensibility: Application의 기능 확장을 하는 Extenstion을 안전하게 분리하여 실행시키기 위한 방법으로 [[SFI]]와 같은 방식이 사용된다. 
**대표적인 연구로 [[NaCL]]을 들 수 있다. E.g., User-defined function, Browser extension 등등
*Secure partition: Application의 일부분을 Main logic과 분리하여 안전하게 실행하기 위한 방법으로 분리되는 부분은 Application의 기능중 Secure sensitive한 부분이 된다. 
**대표적인 연구로 [[Wedge]]나 [[LwC]]가 있다. E.g., Session handler, Key signing 등등
*Maintenance (Auxiliary tasks): Application과는 독립적으로 실행되나, Application의 State를 감시하고 유지 보수하기 위해서 필요한 기능들을 분리하여 안전하게 실행시키기 위한 방법이다. 
**Orbit이 제한한 개념이다. E.g., Fault Detection, Performance Monitor, Resource Management, Recovery 등등

==연구 정리==
{| class="wikitable"
|+
!Research
!Memory Isolation
!Prvilege Separation
!First-class
!Observability
!Transparent
!Usages
!Fault Recovery
!Performance Overhead
!Protection Mechanism
|-
|[[Process|Process (fork)]]
|O
|O
| O
|O
|O
|Genernal
|X
|None
|CoW
|-
|[[POSIX Threads|Pthread]]
|X
|X
|O
|O
|O
|Genernal
|X
|None
| -
|-
|[[Light-Weight Contexts: An OS Abstraction for Safety and Performance|LwC]]
|O (Default CoW)
|O
|X
|O
|X
|Secure partition
|Snapshot
|Low
|CoW
|-
|[[Wedge: Splitting Applications into Reduced-Privilege Compartments|Wedge]]
|O (Default deny)
|O
|O
|X
|△
|Secure partition
|X
|Moderate
|CoW
|-
|[[Operating System Support for Safe and Efﬁcient Auxiliary Execution|Orbit]]
|O (Default RO)
|X
|O
|O
|△
|Maintenance
| MVCC
|Low
|CoW
|-
|[[FlexOS: Towards Flexible OS Isolation|FlexOS]]
|O
|O
|O
|O
|X
|General
|X
| -
|Library OS
|-
|[[Shreds: Fine-grained Execution Units with Private Memory|Shreds]]
|O
|X
|X
|O
|X
|Secure partition
|X
|Low
|MPK
|-
|[[How to Run POSIX Apps in a Minimal Picoprocess|Picoprocess]]
|O
|O
|O
|O
|O
|Compatibility layer
|X
|High
|Library OS
|-
|[[FAASM: Lightweight Isolation for Efficient Stateful Serverless Computing|FAASM]]
|O
|O
|O
|X
|O
|Serverless
|X
|High
|SFI
|-
|[[Designing New Operating Primitives to Improve Fuzzing Performance|FuzzSnap]]
|O
|X
|O
|X
|O
|Fuzzing
|X
|Low
|CoW
|-
|NaCL
|O
|O
| X
|X
|O
|Extensibility
|X
|High
|SFI
|-
|Trellis
|
|
|
|
|
|
|
|
|
|-
|SASOS
|
|
|
|
|
|
|
|
|Capability
|-
|Mondrix
|
|
|
|
|
|
|
|
|Hardware
|}

*Memory Isolation: 메모리접근을 통제하여, 임의로 다른 객체의 매모리에 접근하지 못하도록 하는가?
**LwC: 기본적으로 CoW로 공유하며, API를 통해서 CoW, Shared, UNMAP을 결정할 수 있음. Dynmic하게 수정하는 것을 허용함.
**Wedge: 기본적으로 Default-deny정책을 취하고 있으며, Memory alloc시 Tagging을 통하여, 허용된 Tag만 수정 가능.
**Orbit: arena라는 영역에 할당된 메모리를 CoW로 공유하며, Protected영역에 메모리 업데이트를 위해선 MVCC를 이용해야 함.
*Privilege Separation (Protection): 권한 분리를 통해서 서로다른 Abstraction들이 임의로 접근하거나 프로그램의 상태를 변경시키는 것을 막는가?
**LwC: Default-allow policy임(Private-copy를 생성). Parent는 Child의 Resource접근 권한을 제한할 수 있음. 추후 Dynamic하게 수정하는 것을 허용함.
**Wedge: Default-denty policy임. Callgat란 RPC콜을 이용하여 제한된 Resource만을 접근할 수 있도록 함.
**Orbit: Privilege Separation을 구현하지 않음. 이는 Orbit의 Motivation이 Secure partition이 아니기 때문.
*First-class: 스케쥴링가능한 단위인가? LwC는 스케쥴링이 불가능하여 일단 First-class에 분류하지는 않음 (스레드 내부에 생성하는 방식으로는 우회 가능).
**LwC: 객체이나 스스로 스케쥴링의 단위가 아님. 이를 통해서 Kernel scheduling오버헤드를 피함.
**Wedge: 확장된 Thread모델을 사용함.
**Orbit: 확장된 Thread모델을 사용함.
*Observability: 다른 객체(혹은 다른 보호 도메인)의 내부 상태를 쉽게 모니터링/검사하고, 필요 시 변경할 수 있는가? 많은 Isolation기법이 채택하고 있는 Default-deny모델은 X로 간주하였다.
**LwC와 Wedge는 기본적으로 생성한 프로세서의 Snapshot을 Fork처럼 CoW로 가지고 있기 때문에 Observability가 좋으나, Wedge는 Default-denty정책을 취하고 있다. SFI를 사용하는 NaCL과 같은 기법들은 메모리의 일부분만 접근 가능하기 때문에 마찬가지로 Observability가 낮다.
*Transparent: 개발자가 이미 개발한 프로그램에 명시적으로 인지하고 제어해야 하는 추가적인  부분이 있는가?
*Fault recovery: 만약 한 객체의 작동이 잘못되었을 경우, 잘못되기 전으로 프로그램의 State를 복구 가능한가?