안녕하세요? 허니데이즈입니다. 오늘은 지르콘 커널에서 중요한 역할을 하는 프로세스에 대해서 준비해 봤습니다.



지르콘 프로세스는 전통적 의미에서 프로그램의 인스턴스라고 보면 된다. 리소스 모음과 함께 하나 이상의 스레드에서 실행되는 명령 집합이다. 프로세스 개체는 다음 리소스의 컨테이너로 운영된다.

 Handles
 Virtual Memory Address Regions
 Threads

일반적으로 프로세스는 강제 종료되거나 프로그램이 종료 될 때까지 실행중인 코드와 관련된다. 또한 프로세스는 작업에 의해 소유되며 하나 이상의 프로세스로 구성된 어플리케이션을 리소스, 사용 권한 한도, 수명 제어의 관점에서 단일 엔터티로 처리 할 수 ​​있다.

 

 Lifetime은 어떻게 되나요?
zx_process_create()를 통해 프로세스가 생성되고 실행은 zx_process_start()로 시작된다. 다음과 같은 경우에는 프로세스가 실행을 중지한다.

1. 마지막 스레드가 종료
2. 프로세스 호출 zx_process_exit()
3. 상위 작업이 프로세스를 종료
4. 상위 작업이 삭제
zx_process_start()에 대한 호출을 두 번 실행할 수 없다. 새 스레드는 시작된 프로세스에 추가될 수 없으며 마지막 스레드가 종료된다.

 

 SYSCALLS은 어떤 것이 있나요?
process_create - 작업 내에서 새 프로세스 만들기
process_read_memory - 프로세스의 주소 공간에서 읽기
process_start - 새 프로세스가 실행을 시작하기.
process_write_memory - 프로세스의 주소 공간에 쓰기
process_exit - 현재 프로세스 종료하기
job_create - 상위 작업 내에서 새 작업 만들기
vmar_map - 메모리를 주소 공간 범위에 매핑하기
vmar_protect - 주소 공간 범위의 권한 변경하기
vmar_unmap - 주소 공간 범위에서 메모리 맵 해제하기


출처: https://fuchsia.googlesource.com/zircon/+/master/docs/objects/process.md



 

지르콘 커널에 대해 더 알고 싶으시다면 아래 목차에서 클릭! 

지르콘 커널이란?

Zircon

지르콘 커널 개발 환경 구축하기

Getting Started

지르콘 커널 개발에 기여하는 방법

Contributing Patches

지르콘 커널의 개념 알기

Concepts Overview

지르콘 커널 구성요소(Kernel Objects)는?

Kernel Objects

지르콘 커널에서 사용되는 프로세스(Process)란?

Process Objects

지르콘 커널에서 사용되는 쓰레드(Thread)란?

Thread Objects

지르콘 커널에서 사용되는 핸들(Handles)이란?

Handles

지르콘 커널의 시스템콜하는 방식은?

System Calls

지르콘 커널의 드라이버 개발 키트 사용하는 방법 - 장치 모델

Driver Development Kit

지르콘 커널의 드라이버 개발 키트 사용하는 방법 - 장치 프로토콜

지르콘 커널의 드라이버 개발 키트 사용하는 방법 - 지르콘 드라이버 개발

지르콘 커널의 드라이버 개발 키트 사용하는 방법 - 플랫폼 버스

지르콘 커널의 드라이버 개발 키트 사용하는 방법 - 장치 펌웨어

지르콘 커널을 시험하는 방법은?

Testing

지르콘 커널의 취약점은 무엇일까?

Hacking notes

지르콘 커널의 메모리와 자원 사용은 어떻게 할까?

Memory usage analysis tools

지르콘 커널과 LK(Little Kernel)의 관계는?

Relationship with LK

지르콘 커널을 위한 마이크로 벤츠마크는?

Micro-benchmarks


Goals

  1. Isolation
  2. Recovery
  3. Backward Compatibility

 

논문의 목적

커널의 reliability 높이는

 

Extensions이란?

하나의 도메인이면서 모듈 역할을 하는 존재


loadable module 커널의 모듈화를 높여줌

 

하드웨어 지원 없이 isolation 가능하지 않으며 MMU 이용하여 address space 구현한다.

Nooks page table 이용하며 Nooks lightweight protection domain kernel thread limited version이다.

 

Memory object?

프로세스와 쓰레드의 차이점은?

프로세스는 address space 11 맵핑하며 쓰레드는 address space 하나를 공유한다.

 

XPC? To make calls

XPC 다른 address space(extensions 커널이 다른 address space domain)에서 call 경우가 생긴다.

 

Recovery? Steps? Failer 찾는다. 모든 resource들을 해체한다.

Reload restart의 차이점? Reload 프로그램을 메모리에 올리는 것이며 restart 프로그램을 다시 처음부터 시작하는 것이다.

 

xHTTPd performance 낮은 이유는 XPC 높아서….

 

Motivation

Address the ever increasing system crashes due to new OS extensions

Design for fault resistance not fault tolerance

Interested in reliability, not security

 

 

Architecture

Goal and implementation

 1. Isolation

The Nooks isolation mechanisms prevent extension errors from damaging the kernel (or other isolated extensions).

 2. Interposition

The Nooks interposition mechanisms transparently integrate existing extensions into the Nooks environment.

 3. Object Tracking

The NIM's object-tracking functions oversee all kernel resources used by extensions.

  1. Maintains a list of kernel data structures that are manipulated by an extension,
  2. controls all modifications to those structures, and
  3. provides object information for cleanup when an extension fails.

 4. Recovery

Nooks' recovery functions detect and recover from a variety of extension faults. Nooks detects a software fault when an extension invokes a kernel service improperly or when an extension consumes too many resources.

 

Implementation

확장(Extensible) 가능한 운영체제 기술에서 수십 년간의 연구에도 불구하고, 장치 드라이버 확장은 System failures 중대한 원인으로 남아있다. 이 논문에서는 Nooks 이용하였는데, OS를 항상 신뢰하기 위해서 드라이버 실패(driver failures)로부터 운영체제를 분리한 신뢰된 서브시스템을 설명하였으며 목표는 기존 드라이버 및 시스템 코드를 거의 변화하지 않고 기존 드라이버 인한 충돌을 방지하는 것이다. 또한 논문에서 제안한 기법을 증명하기 위해, Nook Linux 운영체제에서 구현하고 여러 가지 장치 드라이버(device driver)를 결함 및 분리하는데 사용하였다.

 

논문에서 제안한 Nooks isolation 기법은 4가지 functions 제공하는데 다음과 같다. isolation, interposition, object Tracking, recovery이다. 첫째로 Isolation에서 Nook isolation 메커니즘은 Extension에서 일어나는 커널의 손상으로부터 오류를 방지한다. 하지만 하드웨어 지원 없이 isolation 가능하지 않으며 MMU 이용하여 address space 구현한다. Isolation 컴포넌트는 Nook 부분으로 구성되어 있다. 메모리 관리와 Extension Procedure Call(XPC) 이루어져 있는데, 메모리 관리는 경량화 보호 기법을 사용하고, XPC extensions 커널 사이에서 안전한 호출을 제어한다. 다시 말해 XPC 경우 다른 address space(extensions 커널이 다른 address space domain)에서 call 경우가 생긴다. 둘째로 interposition Nook interposition 메커니즘은 기존의 확장 기능을 integrate 환경에 통합 할 수 있습니다. Interposition Nooks Extensions 사이에 통신 제어와 intercept 있도록 도와준다객체 추적(object Tracking) 기능은 확장에 의해 사용되는 모든 커널 리소스를 보는 역할을 한다. 복구(recovery) 기능은 다양한 Extension fault로부터 감지하고 복구하는 기능을 가진다. 다시 말해서 Failure 찾은 다음 모든 resource들을 해체한다.

performance에서는 Nooksisolation 서비스의 성능 비용을 평가하는 벤치 마크 결과를 제공합니다. 논문의 실험은 기존 벤치마크와 툴을 이용하여 Nooks 사용한 시스템 성능을 비교하였으며 Web server benchmarks에서는 xHTTPd performance 낮게 나왔으며 원인으로 XPC 높게 나왔다.

 

논문에서는 커널의 확장은 운영체제에서 major source failure 이슈 점이며 Nooks 기법이 신뢰성 있으며 확장과 관련된 failures들을 줄일 있다. 논문에서 실현한 것은 Nooks 구현은 리눅스와 같은 모놀리딕 운영 체제에서도 중간 정도의 엔지니어링 노력으로 성취할 있으며, 장치 드라이버와 같이 extension 적은 양의 extension code 수정으로도 isolation 있다. Isolation recovery  extension faults으로부터 생존 개선 가능하게 하는 시스템의 기능이다

+ Recent posts