Process abstraction - 편집 역사

2025년 1월 14일 (화) 14:10에 Ahn9807님의 편집

2025-01-14T14:10:49Z

@@ 99번째 줄: / 99번째 줄: @@
 | -
 |Library OS
 |-
 |NaCL

2025년 1월 9일 (목) 10:34에 Ahn9807님의 편집

2025-01-09T10:34:46Z

@@ 88번째 줄: / 88번째 줄: @@
 |Low
 |CoW
 |-
 |NaCL

2025년 1월 7일 (화) 04:31에 Ahn9807님의 편집

2025-01-07T04:31:14Z

← 이전 판		2025년 1월 7일 (화) 04:31 판
32번째 줄:		32번째 줄:
	!Fault Recovery		!Fault Recovery
	!Performance Overhead		!Performance Overhead
	!~~Memory Model~~		!Protection Mechanism
	\|-		\|-
	\|[[~~Light-Weight Contexts: An OS Abstraction for Safety and Performance~~\|~~LwC~~]]		\|[[Process\|Process (fork)]]
	\|O ~~(Default CoW)~~		\|O
			\|O
			\| O
	\|O		\|O
	\|O		\|O
			\|Genernal
	\|X		\|X
	\|X		\|None
	~~\|Secure partition~~
	~~\|Snapshot~~
	~~\|Low~~
	\|CoW		\|CoW
	\|-		\|-
	\|[[~~Operating System Support for Safe and Efﬁcient Auxiliary Execution~~\|~~Orbit~~]]		\|[[POSIX Threads\|Pthread]]
	\|~~O (Default RO)~~		\|X
			\|X
	\|O		\|O
	\|O		\|O
	\|O		\|O
			\|Genernal
	\|X		\|X
	\|~~Maintenance~~		\|None
	\|~~MVCC~~		\| -
			\|-
			\|[[Light-Weight Contexts: An OS Abstraction for Safety and Performance\|LwC]]
			\|O (Default CoW)
			\|O
			\|X
			\|O
			\|X
			\|Secure partition
			\|Snapshot
	\|Low		\|Low
	\|CoW		\|CoW
65번째 줄:		76번째 줄:
	\|X		\|X
	\|Moderate		\|Moderate
	~~\|Tagged-memory~~
	\|-
	~~\|[[Process\|Process (fork)]]~~
	\|O
	\|O
	\|O
	\|O
	\|O
	~~\|Genernal~~
	\|X
	~~\|None~~
	\|CoW		\|CoW
	\|-		\|-
	\|[[~~POSIX Threads~~\|~~Pthread~~]]		\|[[Operating System Support for Safe and Efﬁcient Auxiliary Execution\|Orbit]]
	\|X		\|O (Default RO)
	\|X		\|X
	\|O		\|O
	\|O		\|O
	\| O		\|△
	\|~~Genernal~~		\|Maintenance
	\|X		\| MVCC
	\|~~None~~		\|Low
	\|~~Shared~~		\|CoW
	\|-		\|-
	\|NaCL		\|NaCL
	\|O		\|O
	\| O		\|O
	\|X		\| X
	\|X		\|X
	\|O		\|O
	\|Extensibility		\|Extensibility
	\|X		\|X
	\|High		\|High
	\|~~Sandboxing~~		\|SFI
	\|-		\|-
	\|Trellis		\|Trellis
	\|		\|
	\|		\|
131번째 줄:		131번째 줄:
	\|		\|
	\|		\|
	\|		\|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들이 임의로 접근하거나 프로그램의 상태를 변경시키는 것을 막는가?		*Privilege Separation (Protection): 권한 분리를 통해서 서로다른 Abstraction들이 임의로 접근하거나 프로그램의 상태를 변경시키는 것을 막는가?
	* ~~Memory Isolation~~: ~~메모리접근을 통제하여, 임의로 다른 객체의 매모리에 접근하지 못하도록 하는가?~~		**LwC: Default-allow policy임(Private-copy를 생성). Parent는 Child의 Resource접근 권한을 제한할 수 있음. 추후 Dynamic하게 수정하는 것을 허용함.
	*First-class: 스케쥴링가능한 단위인가?		**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로 간주하였다.		*Observability: 다른 객체(혹은 다른 보호 도메인)의 내부 상태를 쉽게 모니터링/검사하고, 필요 시 변경할 수 있는가? 많은 Isolation기법이 채택하고 있는 Default-deny모델은 X로 간주하였다.
			**LwC와 Wedge는 기본적으로 생성한 프로세서의 Snapshot을 Fork처럼 CoW로 가지고 있기 때문에 Observability가 좋으나, Wedge는 Default-denty정책을 취하고 있다. SFI를 사용하는 NaCL과 같은 기법들은 메모리의 일부분만 접근 가능하기 때문에 마찬가지로 Observability가 낮다.
	*Transparent: 개발자가 이미 개발한 프로그램에 명시적으로 인지하고 제어해야 하는 추가적인 부분이 있는가?		*Transparent: 개발자가 이미 개발한 프로그램에 명시적으로 인지하고 제어해야 하는 추가적인 부분이 있는가?
	*Fault recovery: 만약 한 객체의 작동이 잘못되었을 경우, 잘못되기 전으로 프로그램의 State를 복구 가능한가?		*Fault recovery: 만약 한 객체의 작동이 잘못되었을 경우, 잘못되기 전으로 프로그램의 State를 복구 가능한가?

2025년 1월 6일 (월) 11:34에 Ahn9807님의 편집

2025-01-06T11:34:08Z

← 이전 판		2025년 1월 6일 (월) 11:34 판
9번째 줄:		9번째 줄:

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

	*Extensibility: Application의 기능 확장을 하는 Extenstion을 안전하게 분리하여 실행시키기 위한 방법으로 [[SFI]]와 같은 방식이 사용된다.		*Extensibility: Application의 기능 확장을 하는 Extenstion을 안전하게 분리하여 실행시키기 위한 방법으로 [[SFI]]와 같은 방식이 사용된다.
22번째 줄:		24번째 줄:
	\|+		\|+
	!Research		!Research
	!~~Protection~~		!Memory Isolation
	!~~Isolation~~		!Prvilege Separation
	!First-class		!First-class
	!Observability		!Observability
	!Transparent		!Transparent
	!Usages		!Usages
	!Fault ~~recovery~~		!Fault Recovery
	!Performance ~~overhead~~		!Performance Overhead
	!Memory ~~model~~		!Memory Model
	\|-		\|-
	\|[[Light-Weight Contexts: An OS Abstraction for Safety and Performance\|LwC]]		\|[[Light-Weight Contexts: An OS Abstraction for Safety and Performance\|LwC]]
	\|O		\|O (Default CoW)
	\|O		\|O
	\|O		\|O
44번째 줄:		46번째 줄:
	\|-		\|-
	\|[[Operating System Support for Safe and Efﬁcient Auxiliary Execution\|Orbit]]		\|[[Operating System Support for Safe and Efﬁcient Auxiliary Execution\|Orbit]]
	\|O		\|O (Default RO)
	\|O		\|O
	\|O		\|O
55번째 줄:		57번째 줄:
	\|-		\|-
	\|[[Wedge: Splitting Applications into Reduced-Privilege Compartments\|Wedge]]		\|[[Wedge: Splitting Applications into Reduced-Privilege Compartments\|Wedge]]
			\|O (Default deny)
	\|O		\|O
	\|O		\|O
	\|X
	\|X		\|X
	\|△		\|△
132번째 줄:		134번째 줄:
	\|}		\|}

	*Protection: 권한 분리를 통해서 서로다른 Abstraction들이 임의로 접근하거나 프로그램의 상태를 변경시키는 것을 막는가?		*Privilege Separation (Protection): 권한 분리를 통해서 서로다른 Abstraction들이 임의로 접근하거나 프로그램의 상태를 변경시키는 것을 막는가?
	* Isolation: 메모리접근을 통제하여, 임의로 다른 객체의 매모리에 접근하지 못하도록 하는가?		* Memory Isolation: 메모리접근을 통제하여, 임의로 다른 객체의 매모리에 접근하지 못하도록 하는가?
	*First-class: 스케쥴링가능한 단위인가?		*First-class: 스케쥴링가능한 단위인가?
	*Observability: 다른 객체(혹은 다른 보호 도메인)의 내부 상태를 쉽게 모니터링/검사하고, 필요 시 변경할 수 있는가? 많은 Isolation기법이 채택하고 있는 Default-deny모델은 X로 간주하였다.		*Observability: 다른 객체(혹은 다른 보호 도메인)의 내부 상태를 쉽게 모니터링/검사하고, 필요 시 변경할 수 있는가? 많은 Isolation기법이 채택하고 있는 Default-deny모델은 X로 간주하였다.
	*Transparent: 개발자가 이미 개발한 프로그램에 명시적으로 인지하고 제어해야 하는 추가적인 부분이 있는가?		*Transparent: 개발자가 이미 개발한 프로그램에 명시적으로 인지하고 제어해야 하는 추가적인 부분이 있는가?
	*Fault recovery: 만약 한 객체의 작동이 잘못되었을 경우, 잘못되기 전으로 프로그램의 State를 복구 가능한가?		*Fault recovery: 만약 한 객체의 작동이 잘못되었을 경우, 잘못되기 전으로 프로그램의 State를 복구 가능한가?

2025년 1월 6일 (월) 10:20에 Ahn9807님의 편집

2025-01-06T10:20:37Z

← 이전 판		2025년 1월 6일 (월) 10:20 판
9번째 줄:		9번째 줄:

	==연구 방향==		==연구 방향==
	~~===Protection===~~
	Protection을 위한 방식은 크게 2가지로 분류 가능하다. [[Operating System Support for Safe and Efﬁcient Auxiliary Execution\|Orbit]]에서는 추가로 Maintenance라는 Protection senario를 추가하였다.		Protection을 위한 방식은 크게 2가지로 분류 가능하다. [[Operating System Support for Safe and Efﬁcient Auxiliary Execution\|Orbit]]에서는 추가로 Maintenance라는 Protection senario를 추가하였다.

2025년 1월 6일 (월) 09:07에 Ahn9807님의 편집

2025-01-06T09:07:45Z

← 이전 판		2025년 1월 6일 (월) 09:07 판
33번째 줄:		33번째 줄:
	!Memory model		!Memory model
	\|-		\|-
	\|LwC		\|[[Light-Weight Contexts: An OS Abstraction for Safety and Performance\|LwC]]
	\|O		\|O
	\|O		\|O
44번째 줄:		44번째 줄:
	\|CoW		\|CoW
	\|-		\|-
	\|Orbit		\|[[Operating System Support for Safe and Efﬁcient Auxiliary Execution\|Orbit]]
	\|O		\|O
	\|O		\|O
55번째 줄:		55번째 줄:
	\|CoW		\|CoW
	\|-		\|-
	\|Wedge		\|[[Wedge: Splitting Applications into Reduced-Privilege Compartments\|Wedge]]
	\|O
	\|O		\|O
	\|O		\|O
	\|X		\|X
	\|X		\|X
			\|△
	\|Secure partition		\|Secure partition
	\|X		\|X
	\|~~Low~~		\|Moderate
	\|~~CoW~~		\|Tagged-memory
	\|-		\|-
	\|Process (fork)		\|[[Process\|Process (fork)]]
			\|O
	\|O		\|O
	\|O		\|O
	\|O		\|O
	\|X
	\|O		\|O
	\|Genernal		\|Genernal
77번째 줄:		77번째 줄:
	\|CoW		\|CoW
	\|-		\|-
	\|Pthread		\|[[POSIX Threads\|Pthread]]
	\|X		\|X
	\|X		\|X
	\|O		\|O
	\|O		\|O
	\|O		\| O
	\|Genernal		\|Genernal
	\|X		\|X
	\|None		\|None
90번째 줄:		90번째 줄:
	\|NaCL		\|NaCL
	\|O		\|O
	\|O		\| O
	\|X		\|X
	\|X		\|X
96번째 줄:		96번째 줄:
	\|Extensibility		\|Extensibility
	\|X		\|X
	\|High		\|High
	\|Sandboxing		\|Sandboxing
	\|-		\|-
	\|Trellis		\|Trellis
	\|		\|
	\|		\|
133번째 줄:		133번째 줄:
	\|}		\|}

	* Protection: 권한 분리를 통해서 서로다른 Abstraction들이 임의로 접근하거나 프로그램의 상태를 변경시키는 것을 막는가?		*Protection: 권한 분리를 통해서 서로다른 Abstraction들이 임의로 접근하거나 프로그램의 상태를 변경시키는 것을 막는가?
	* Isolation: 메모리접근을 통제하여, 임의로 다른 객체의 매모리에 접근하지 못하도록 하는가?		* Isolation: 메모리접근을 통제하여, 임의로 다른 객체의 매모리에 접근하지 못하도록 하는가?
	* First-class: 스케쥴링가능한 단위인가?		*First-class: 스케쥴링가능한 단위인가?
	* Observability: 다른 객체(혹은 다른 보호 도메인)의 내부 상태를 쉽게 모니터링/검사하고, 필요 시 변경할 수 있는가?		*Observability: 다른 객체(혹은 다른 보호 도메인)의 내부 상태를 쉽게 모니터링/검사하고, 필요 시 변경할 수 있는가? 많은 Isolation기법이 채택하고 있는 Default-deny모델은 X로 간주하였다.
	* Transparent: 개발자가 이미 개발한 프로그램에 명시적으로 인지하고 제어해야 하는 추가적인 부분이 있는가?		*Transparent: 개발자가 이미 개발한 프로그램에 명시적으로 인지하고 제어해야 하는 추가적인 부분이 있는가?
	* Fault recovery: 만약 한 객체의 작동이 잘못되었을 경우, 잘못되기 전으로 프로그램의 State를 복구 가능한가?		*Fault recovery: 만약 한 객체의 작동이 잘못되었을 경우, 잘못되기 전으로 프로그램의 State를 복구 가능한가?

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

2025-01-06T05:56:58Z

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

새 문서

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

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

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

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

==연구 방향==
===Protection===
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
!Protection
!Isolation
!First-class
!Observability
!Transparent
!Usages
!Fault recovery
!Performance overhead
!Memory model
|-
|LwC
|O
|O
|O
|X
|X
|Secure partition
|Snapshot
|Low
|CoW
|-
|Orbit
|O
|O
|O
|O
|X
|Maintenance
|MVCC
|Low
|CoW
|-
|Wedge
|O
|O
|O
|X
|X
|Secure partition
|X
|Low
|CoW
|-
|Process (fork)
|O
|O
|O
|X
|O
|Genernal
|X
|None
|CoW
|-
|Pthread
|X
|X
|O
|O
|O
|Genernal
|X
|None
|Shared
|-
|NaCL
|O
|O
|X
|X
|O
|Extensibility
|X
|High
|Sandboxing
|-
|Trellis
|
|
|
|
|
|
|
|
|
|-
|SASOS
|
|
|
|
|
|
|
|
|Capability
|-
|Mondrix
|
|
|
|
|
|
|
|
|
|}

* Protection: 권한 분리를 통해서 서로다른 Abstraction들이 임의로 접근하거나 프로그램의 상태를 변경시키는 것을 막는가?
* Isolation: 메모리접근을 통제하여, 임의로 다른 객체의 매모리에 접근하지 못하도록 하는가?
* First-class: 스케쥴링가능한 단위인가?
* Observability: 다른 객체(혹은 다른 보호 도메인)의 내부 상태를 쉽게 모니터링/검사하고, 필요 시 변경할 수 있는가?
* Transparent: 개발자가 이미 개발한 프로그램에 명시적으로 인지하고 제어해야 하는 추가적인 부분이 있는가?
* Fault recovery: 만약 한 객체의 작동이 잘못되었을 경우, 잘못되기 전으로 프로그램의 State를 복구 가능한가?