KR20080070634A

KR20080070634A - 격리된 익스텐션 및 장치 드라이버의 구성 요구사항을설명하고 처리하는 하나 이상의 프로세서-판독가능 매체

Info

Publication number: KR20080070634A
Application number: KR1020087010060A
Authority: KR
Inventors: 갈렌 씨. 헌트; 제임스 알. 라루스; 마누엘 에이. 판드리치; 오리온 호드슨; 스티븐 피. 레비; 바르네 스틴스가르드; 데이비드 알. 타르디티; 마이클 스페어; 마이클 카빈; 마틴 아바디; 마크 아이켄; 폴 바함; 테드 워버; 브라이언 질; 크리스 하우브리츠젤; 닉 머피
Original assignee: 마이크로소프트 코포레이션
Priority date: 2005-10-26
Filing date: 2006-10-16
Publication date: 2008-07-30
Also published as: JP2009514099A; EP1952251A4; US8074231B2; BRPI0618027A2; JP5009299B2; KR101331361B1; WO2007050364A1; EP1952251A1; RU2443012C2; US20070094673A1; RU2008116714A

Abstract

여기에 설명된 것은 소프트웨어 시스템의 애플리케이션, 익스텐션, 장치 드라이버(300) 및 기타 컴포넌트의 구성 요구사항을 설명하고 및/또는 처리하는 하나 이상의 구현에 관한 것이다.

장치 드라이버, 로컬-액세스 개체, 매니페스트, 프로그램 모듈, 신뢰성 있는런타임

Description

격리된 익스텐션 및 장치 드라이버의 구성 요구사항을 설명하고 처리하는 하나 이상의 프로세서-판독가능 매체{CONFIGURATION OF ISOLATED EXTENSIONS AND DEVICE DRIVERS}

본 발명은 소프트웨어 시스템의 애플리케이션, 익스텐션(extension), 장치 드라이버(300) 및 기타 컴포넌트의 구성 요구사항을 설명하고 및/또는 처리하는 하나 이상의 구현에 관한 것이다.

운영 체제와 같은 소프트웨어 시스템은 통상적으로 다양한 작업을 수행하는 미리 정의된 소프트웨어 모듈 집합이 부속되어 있다. 이들 모듈은 모두 상기 미리 정의된 집합의 일부이기 때문에 서로 관련된다.

그러나, 추가 기능 및/또는 맞춤화가 종종 요구된다. 즉, 기능이 "확장"된다. 통상적으로, 소프트웨어 시스템은 새로운 소프트웨어 모듈 또는 프로세스의 동적 추가를 위해 제공함으로써 확장을 가능하게 한다. 이들 추가는 종종 "익스텐션" 또는 "플러그-인"이라 불린다. 종래의 시스템에서의 익스텐션 또는 플러그-인의 일반적인 예는 운영 체제를 위한 장치 드라이버, 데이터베이스 내의 확장된 저장 절차, 웹 브라우저 내의 플러그-인 및 ActiveX^TM 컨트롤, 웹 서버 내의 ISAPI 콘 텐트 및 필터 익스텐션, 사용자 인터페이스 셸을 위한 셸 익스텐션 등을 포함하지만, 이에 제한되는 것은 아니다. 익스텐션에 의해 추가된 기능은 하드웨어 장치의 갱신된 버전을 위한 단순한 지원에서부터 이메일 클라이언트 내의 워크플로 툴(workflow tool)에 대한 바이러스 스캐너까지 그 범위가 미친다. 그러나, 익스텐션을 통합하는 종래의 방법은 문제가 있을 수 있다.

예를 들어, 종래의 운영 체제(OS)는 실행가능 명령어들의 집합을 커널 보호 도메인 내로 로드함으로써 익스텐션을 로드한다. 일단 드라이버가 이 주소 공간 내로 설치되면, 종래의 커널은 로드된 익스텐션이 컴퓨팅 시스템 내의 임의의(또는 모든) 하드웨어를 액세스하는 것을 막을 수 없다. 따라서, 기형적인 또는 악의적인 익스텐션은 OS 커널 내에서 많은 문제를 초래할 수 있다.

장치 드라이버는 운영 체제에서 볼 수 있는 일종의 익스텐션이다. 장치 드라이버는 특정 장치 또는 장치들의 클래스를 액세스하도록 운영 체제를 확장하는 소프트웨어 모듈이다. 예를 들어, IDE 드라이버는 운영 체제가 IDE 저장 컨트롤러에 부가된 디스크 드라이브를 액세스할 수 있게 한다. 장치 드라이버는 특정 벤더 저장 컨트롤러와 같은 하드웨어의 특정한 것과 통신하는 기구로부터, 디스크 저장소의 판독 및 기입 블록과 같은 운영 체제 또는 애플리케이션에 의해 알려진 일반적인 기능을 추상화하는 중요한 기능을 실행한다. 장치 드라이버는 종종 물리적 장치를 액세스하지만, 본 분야에 숙련된 기술자들은 장치 드라이버가 또한 가상 자원으로의 액세스를 제공할 수 있고, 또는 저장 컨트롤러의 장치 드라이버 위에 놓인 압축 드라이버와 같은 부가 기능을 추가하기 위해 계층화될 수 있다는 것을 알 수 있을 것이다.

장치 드라이버의 복잡도는 사용자가 핫-스와핑(hot-swapping) 및 전력 관리와 같은 풍부한 특징을 기대하게 됨에 따라 지난 10년 동안에 상당히 증가했다. 다수의 종래의 운영 체제는 여러 방식으로 이에 응했지만, 그들의 코어에서, 이들 시스템은 10년 전에 갖추고 있던 것과 동일한 드라이버 모델을 갖추고 있다.

익스텐션과 마찬가지로, 종래의 운영 체제(OS)는 실행가능 명령어를 커널 보호 도메인 내로 로드함으로써 장치 드라이버를 로드한다. 일단 드라이버가 이 주소 공간 내로 설치되면, 종래의 커널은 로드된 드라이버가 컴퓨팅 시스템 내의 임의의(또는 모든) 하드웨어를 액세스하는 것을 막을 수 없다.

더욱이, 이들 드라이버가 통상적으로 하드웨어를 직접 액세스하기 위해 로우-레벨 프리미티브로 기입되기 때문에, 종래의 커널은 드라이버가 적절한 하드웨어 자원만을 사용하는 것을 거의 검증하지 않는다. 그 대신에, 종래의 커널은 드라이버가 서브한다고 주장하는 장치의 하드웨어만을 액세스할 것이라고 믿는다. 더욱이, 종종, 종래의 커널은 드라이버가 정확히 구성한다는 것을 보증할 수 없고, 드라이버가 액티브 프로세스에 할당된 메모리, 또는 심지어 종래의 커널 내의 다른 컴포넌트에 할당된 메모리를 고려할 것이라는 것을 보증할 수 없다.

따라서, 종래의 드라이버는 OS 내의 대부분의 신뢰할 수 없는 컴포넌트들 중의 하나이다. 몇몇 보고서는 가장 대중적인 종래의 OS에서 진단된 파손의 85%가 드라이버에 의해 야기된 것이라고 나타내고 있다. 기타 보고서는 덜 대중적인 종래의 OS용 드라이버가 커널 내의 다른 실행가능 명령어들보다 버그를 포함할 가능 성이 7배나 더 많다고 나타내고 있다.

여기에서 설명된 것은 소프트웨어 시스템의 애플리케이션, 익스텐션, 장치 드라이버 및 기타 컴포넌트의 구성 요구사항을 설명 및/또는 처리하는 하나 이상의 구현에 관한 것이다.

이 요약은 아래의 상세한 설명 부분에서 더욱 설명되는 개념들의 선택을 단순화된 형태로 소개하기 위해 제공된다. 이 요약은 청구된 주제의 핵심 특징이나 주요 특징을 식별하고자 하는 것도 아니고, 청구된 주제의 범위를 결정하는데 도움을 주고자 하는 것도 아니다.

동일한 번호는 동일한 요소 및 특징을 참조하기 위해 도면 전반에 걸쳐 사용된다.

도 1은 여기에서 설명된 하나 이상의 구현을 지원하는 운영 체제 아키텍처의 동작 시나리오.

도 2는 여기에서 설명된 하나 이상의 구현을 지원하는 운영 체제 아키텍처의 블록도.

도 3은 도 2에 도시된 운영 체제 아키텍처의 장치 드라이버 프로세스 내의 개체들 및 그들의 다른 부분과의 관계를 도시한 블록도.

도 4는 여기에서 설명된 다른 방법적인 구현의 플로우차트.

다음 설명은 소프트웨어 시스템의 애플리케이션, 익스텐션, 장치 드라이버 및 기타 컴포넌트의 구성 요구사항을 설명 및/또는 처리하는 기술을 설명한다.

종래의 익스텐션(예를 들어, 장치 드라이버)은 입/출력(I/O), 메모리, 비디오, 사운드, 인터럽트 요청(IRQ) 라인 또는 기타 하드웨어와 같은 컴퓨팅 자원으로의 직접 액세스를 위한 실행가능 명령어를 포함한다. 종래의 익스텐션과 달리, 여기에서 설명된 하나 이상의 구현에 따라 작성된 익스텐션(예를 들어, 장치 드라이버)은 컴퓨팅 자원에 게이트웨이 또는 브리지를 제공하는 개체(즉, 하나 이상의 데이터 구조를 갖는 실행가능 명령어)인 하나 이상의 로컬-액세스 개체를 통해 컴퓨팅 자원을 액세스한다.

하나 이상의 설명된 구현에 따라, 익스텐션은 그들의 구성 요구사항이 이들 자원에 대한 그들의 요구를 포함한다는 것을 지정하는 내재된 메타데이터를 포함한다. 운영 체제(OS)는 이 메타데이터에 기초하여 익스텐션의 컴퓨팅 자원 요구들을 결정한다. OS는 요구된 자원을 할당하고, 익스텐션을 그것의 프로세스 외부의 컴퓨팅 자원에 접속하기 위해 필요한 실행가능 명령어를 (로컬-액세스 개체의 형태로) 제공한다.

이 새로운 분업은 익스텐션의 호스트(장치 드라이버에 대한 하나 이상의 실시예에서 OS)에게, 모든 구성 요구사항을 검증하고, 익스텐션에 의한 I/O 또는 IPC 자원으로의 모든 액세스를 제어할 수 있는 능력을 제공한다.

소프트웨어 격리 프로세스

컴퓨터 과학 부문에서, 더욱 구체적으로 운영 체제 분야에서, "소프트웨어 프로세스"(또는 더욱 단순하게, "프로세스")라는 용어는 잘 알려져 있다. 애플리케이션은 보통 하나 이상의 프로세스로 구성된다. 운영 체제(OS)는 컴퓨터상에서 실행되는 하나 이상의 분리된 프로세스를 알아차리고, 실제로 그 프로세스들을 관리하고 감독할 수 있다.

여기에서, 하나의 프로세스는 실행가능 명령어들을 포함한다. 하나의 프로그램 모듈도 또한 실행가능 명령어들을 포함한다. 하나 이상의 프로세스는 하나의 프로그램 모듈에 기초하여 실행할 수 있다.

여기에서, 하나의 익스텐션은 하나의 프로그램 모듈로서 설명될 수 있다. 더욱이, 장치 드라이버는 익스텐션의 한 예이다. 여기에서 설명된 하나 이상의 실시예는 격리된 프로세스를 통해 구현될 수 있다. 격리된 프로세스의 상황은 도 1과 관련하여 설명된다.

하나 이상의 구현은 SIP(Software-Isolated Process) 추상화 모델의 구성을 위해 제공하고 및/또는 그 구성을 지원하는 OS 모델에서 동작하는 것으로 여기에서 설명된다. SIP는 프로그램 또는 시스템의 부분들을 캡슐화하고, 정보 감춤, 실패 격리 및 강한 인터페이스를 제공한다. SIP는 운영 체제 및 애플리케이션 소프트웨어 전반에 걸쳐 사용된다.

도 1은 SIP의 구성을 위한 동작 시나리오를 도시한 것이다. 도 1은 컴퓨터(120) 상에 저장되고 및/또는 컴퓨터(120) 상에서 실행되는 운영 체제(110)의 일부로서 프로세스 구성 아키텍처(100)를 도시하고 있다. 프로세스 구성 아키텍처(100)는 도 1에 도시된 바와 같이, 운영 체제의 일부일 수 있다. 대안적으로, 프로세스 구성 아키텍처(100)의 전부 또는 일부는 운영 체제에서 분리될 수 있지만, 여전히 운영 체제와 함께 동작한다.

프로세스 구성 아키텍처(100)는 익스텐션 컴포넌트 집합에 의해 편집된 구성 컴포넌트의 동적 집합으로부터 컴퓨터의 작업 메모리 내에 프로세스를 구성한다. 일단 구성되면, 액티브 프로세스의 실행가능 명령어가 고정된다. 일단 고정되면, 액티브 프로세스는 일반적으로 새로운 프로세서-실행가능 명령어를 실행하지 않는다. 그렇게 하기 위해, 프로세스는 통상적으로 그것의 일부로서 새로운 실행가능 명령어로 새로 재구성되고, 또는 새로운 애드-온(add-on) 프로세스가 작성된다.

구성 및 익스텐션 컴포넌트의 동적 집합은 통상적으로 컴퓨터 저장소 내에 저장된 로드 모듈의 집합으로서 표명된다. 프로세스 구성 아키텍처(100)는 여러 가지 바람직한 최적화가 실행될 수 있게 할 뿐만 아니라, 프로세스의 하나 이상의 여러 가지 속성에 관한 분석(예를 들어, 무결성, 보안성, 신뢰성, 이용도, 자원-사용 분석, 완성도 분석 및/또는 안정성)이 실행될 수 있게 하는 방식으로 프로세스를 구성한다.

컴퓨터(120)는 로드 모듈 집합(124)을 저장하는 컴퓨터 저장 장치(122)(예를 들어, 하드 드라이브, RAID 시스템 등) 및 작업 메모리(130)를 포함한다. 도 1의 예에서, 프로세스 구성 아키텍처(100)는 작업 메모리(130) 내에 저장되는 프로세스(140)를 구성한다. 여기에서 나타낸 바와 같이, 프로세스(140)는 프로세스의 익스텐션 컴포넌트에 의해 편집된 프로세스의 구성 컴포넌트의 표명(manifestation)인 로드 모듈(124)로부터 구성된다.

프로세스(140)는 프로세스(140)의 최종 콘텐트를 정의하는 프로세스 매니페스트(manifest)(142)를 포함한다. 그러한 최종 콘텐트의 일부는 프로세스의 익스텐션 컴포넌트에 의해 편집된 프로세스의 구성 컴포넌트를 포함한다. 여기에서 나타낸 바와 같이, 프로세스 매니페스트(142)는 그 구성을 설명하는 프로세스(이를테면, 프로세스(140))와 직접 관련된다.

프로세스 구성시에, 프로세스 구성 아키텍처(100)는 다음과 같은 기능적 컴포넌트들의 하나 이상을 이용할 수 있다: 프로세스 매니페스트 구성자(150), 유형화된 코드(typed-code) 표현 작성자(152), 유형화된 코드 표현 갱신자(154), 최적화기(156), 유형 코드 표현 변환기(158), 프로세스간 간섭 제거기(160) 및 고정된 ID 작성자(162). 도 1은 이들 기능적 컴포넌트를 서로 분리된 것으로 도시하고 있지만, 이들 기능적 컴포넌트의 하나 이상의 기능은 결합될 수 있다.

"양방향 메시지 통로를 이용하는 프로세스간 통신" 애플리케이션은 SIP들(및 또한 OS) 사이에서 사용될 수 있는 프로세스간 통신을 지원하는 OS 모델의 컴포넌트를 개시한다.

SIP들에 있어서, 커널 외부의 모든 실행가능 명령어는 한 SIP에서 실행되고, 견고하게 유형화된 통신 채널을 통해 다른 SIP들과 통신한다. SIP는 데이터 공유 또는 동적 코드 로딩을 허용하지 않는 폐쇄 환경이다. SIP는 여러 방식에서 종래의 OS 프로세스와 다르다.

(여기에서 설명된 구현을 지원하고, 운영 체제(210)에 의해 나타내지는) 새로운 커널은 거의 완전히, 안전한 실행가능 명령어로 구성되고, SIP에서 실행되는 시스템의 나머지는 검증할 수 있게 안전한 실행가능 명령어로 구성되며, 장치 드라이버, 시스템 프로세스 및 애플리케이션을 포함한다. 모든 신뢰할 수 없는 실행가능 명령어가 검증할 수 있게 안전해야 하지만, 신뢰성 있는 기반이라 불리는 새로운 커널 및 런 타임 시스템의 부분들은 검증할 수 있게 안전하지 않다. 언어 안전성은 이 신뢰성 있는 기반을 신뢰할 수 없는 실행가능 명령어로부터 보호한다. 게다가, 각 SIP의 무결성은 명령어 안전성에 의존하고, 한 프로세스가 다른 프로세스의 개체 공간 내로의 참조를 보유하지 않는 전시스템(system-wide) 불변성에 의존한다.

프로세스간 통신

최소한 하나의 설명된 구현에서, SIP는 오로지 채널을 통해 메시지를 보냄으로써 통신한다. 채널은 2개의 프로세스 간의 동작으로 유형화된 양방향 접속이다. 메시지는 송신에서 수신 프로세스로 전달되는 익스체인지 히프(Exchange Heap) 내의 값 또는 메시지 블록의 컬렉션에 태그된다. 채널은 메시지의 포맷, 및 채널을 따른 유효 메시지 순서를 지정하는 계약(contract)에 의해 유형화된다.

SIP는 채널의 2개의 종점-익스포터(exporter) 및 임포터(importer)로서 비대칭으로 유형화됨-을 그 출력 파라미터에서 반환하는 계약의 정적 NewChannel 메소드를 호출함으로써 채널을 작성한다.

SIP는 현존하는 채널을 통해 어느 하나 또는 둘 다의 종점을 다른 프로세스로 보낼 수 있다. 한 종점을 수신하는 프로세스는 다른 대응하는 종점을 보유하는 프로세스로의 채널을 갖는다. 예를 들어, 애플리케이션 프로세스가 시스템 서비스 와 통신하기를 원하면, 애플리케이션은 2개의 종점을 작성하고, 종점을 서비스에 전송하는 시스템의 이름 서버에 하나의 종점을 포함하는 요청을 보냄으로써, 프로세스와 서비스 사이에 채널을 설정한다.

채널 상에서의 송신은 비동기적이다. 수신은 특정 메시지가 도달할 때까지 동기적으로 차단된다. 언어 특징을 사용하여, 스레드는 채널을 따른 메시지 집합의 처음을 기다릴 수 있고, 또는 상이한 채널로부터 메시지의 특정 집합을 기다릴 수 있다. 데이터가 채널을 통해 송신될 때, 소유권은 메시지에 대한 참조를 보유할 수 없는 송신 프로세스에서 수신 프로세스로 넘어간다. 이 소유권 불변성은 언어 및 런 타임 시스템에 의해 시행되고, 3가지 목적으로 쓰인다. 제1 목적은 프로세스들 사이의 공유를 방지하기 위한 것이다. 제2 목적은 메시지의 포인터 앨리어싱(aliasing)을 제거함으로써 정적 프로그램 분석을 용이하게 하기 위한 것이다. 제3 목적은 복사 또는 포인터 전달에 의해 구현될 수 있는 메시지-전달 시맨틱(semantic)을 제공함으로써 구현 융통성을 허용하기 위한 것이다.

격리된 확장성

소프트웨어 작성자는 그들의 시스템 또는 애플리케이션의 사용자에 의해 요구된 전체 기능을 거의 예측하지 않는다. 모놀리식 시스템으로 모든 사람을 만족시키고자 하기보다, 가장 중대한 소프트웨어는 추가 실행가능 명령어를 로드함으로써 그 기능을 늘리는 메커니즘을 제공한다. 예를 들어, 몇몇 종래의 시판중인 퍼스널 컴퓨터 운영 체제는 OS가 거의 모든 하드웨어 장치를 제어할 수 있게 하는 100,000개 이상의 제3자 장치 드라이버를 지원한다. 이와 유사하게, 셀 수 없는 인터넷 브라우저 애드-온 및 익스텐션은 브라우저의 인터페이스 및 웹 페이지용 컴포넌트를 증가시킨다. 심지어 공개 소스 프로젝트도 - 잠재적으로 변경 가능성이 있긴 하지만- "플러그-인" 메커니즘을 제공하는데, 그것은 익스텐션이 새로운 소프트웨어 버전보다 개발하고 배포하기가 더 쉽기 때문이다.

익스텐션은 일반적으로 익스텐션의 부모의 주소 공간 내로 동적으로 로드되는 실행가능 명령어로 이루어진다. 부모의 내부 인터페이스 및 데이터 구조로의 직접 액세스로, 익스텐션은 풍부한 기능을 제공할 수 있다. 그러나, 이 융통성은 비용을 증가시킨다. 익스텐션은 소프트웨어 신뢰성, 보안성 및 역 호환성 문제의 주요 원인이다. 익스텐션 실행가능 명령어는 종종 신뢰할 수 없고, 검증할 수 없고, 불완전하고, 또는 심지어 악의적이긴 하지만, 그들은 호스트와 익스텐션 사이에 하드 인터페이스, 경계 또는 구별 없이 프로그램의 주소 공간 내로 직접 로드된다.

익스텐션은 종종 비호환성, 기능 장애 또는 기타 에러의 소스이다. 게다가, 익스텐션은 하드 인터페이스가 없기 때문에, 그 부모의 구현의 상세에 의존하게 될 수 있는데, 이것은 프로그램의 장래 버전의 발전을 제한하고, 비호환성을 방지하기 위한 광범위한 테스팅을 필요로 한다.

실행가능 명령어의 동적 로딩은 성능 및 정확성에 부차적이고 덜 명백한 부담을 지운다. 실행가능 명령어를 동적으로 로드할 수 있는 시스템은 시스템의 상태, 불변성 또는 유효 변환에 대한 올바른 가정을 하기 어렵거나 할 수 없는 개방 환경이다. 언제든지, 새로운 파일을 로드하고, 클래스 및 메소드 본문을 무효로 하며, 전체 상태를 변경하는 명령어들을 인터럽트, 예외 또는 스레드 스위치가 실행할 수 있는 Java^TM 가상 기계(JVM)를 고려해보자. 일반적으로, 환경이 2개의 실행가능 명령어들 사이에서 임의로 바뀌지 않는 불합리한 가정하의 상태를 제외하고는, 그러한 환경에서 실행되는 프로그램을 분석하는 적당한 방법은 없다.

여기에서 설명된 하나 이상의 구현에 의해 이용된 새로운 방법은 실행가능 명령어의 동적 로딩을 금지하고, 자신의 환경에서 동적으로 작성된 익스텐션을 격리하는 것이다. 이들 방침을 따른 이전의 시도는 격리 메커니즘이 격리 없이 실행되는 위험보다 덜 매력적이게 하는 성능 및 프로그램가능성 문제를 가졌기 때문에 널리 사용되지 못했다.

가장 널리 보급된 격리 메커니즘은 종래의 OS 프로세스인데, 그것의 높은 비용은 그 유용성을 제한한다. 현대 프로세서상의 메모리 관리 하드웨어는 프로세스에 엄격한 경계를 제공하여, 프로세서 상태를 보호하지만, 프로세스간 제어 및 데이터 전송에 매우 불리한 조건이 부과된다. 현대의 x86 프로세서상에서, 프로세스 사이의 스위칭은 TLB 및 캐시 리필 부적중(cache refill miss)을 포함하지 않고, 수백 내지 수천 사이클이 걸릴 수 있다.

Java^TM 가상 기계(JVM) 및 Microsoft® 공용 언어 런타임(CLR)과 같은 더욱 최근의 시스템은 확장성을 위해 설계되고, 따라서, 동일한 주소 공간 내에서 실행되는 계산을 격리하는 메커니즘으로서 하드웨어가 아니라 언어 안전성을 사용한다. 그러나, 안전한 언어는 그 자체로 격리의 불충분한 보증이 될 수 있다. 공유된 데 이터는 계산의 개체 공간 사이에 경로를 제공하는데, 어느 시점에서 반사 API는 데이터 추상화 및 정보 감춤을 파괴하는 메커니즘을 제공한다. 결과적으로, 이들 시스템은 시스템 메커니즘 및 인터페이스로의 액세스를 제어하기 위해 JVM 미세 액세스 제어 또는 CLR의 코드 액세스 보안(Code Acess Security)와 같은 복잡한 보안 메커니즘 및 정책을 필요로 한다.

또한, 런 타임 시스템을 공유하고 동일한 프로세스에서 실행되는 계산들은 실패시에 격리되지 않는다. JVM에서 실행되는 계산이 실패할 때, 전체 JVM 프로세스는 통상적으로 재개시되는데, 그것은 훼손된 데이터를 격리하여 폐기하고, 실패한 계산을 재개시하기 위한 순수한 시점을 찾기 어렵기 때문이다.

여기에서 설명된 최소한 하나의 구현은 폐쇄 환경에서 시스템 컴포넌트의 실행가능 명령어를 캡슐화하기 위해 SIP를 이용한다. 시스템 또는 애플리케이션에 대한 익스텐션은 새로운 SIP에서 실행되고, 제한되고 적절한 기능을 제공하는 채널을 통해 부모와 통신한다. 익스텐션이 실패한 경우, 그것의 SIP는 종료되어, OS가 자원의 반환을 요구하고 통신 파트너에게 통지할 수 있게 한다. 이들 파트너가 익스텐션과 상태를 공유하지 않기 때문에, 에러 복구는 국한되고, 채널의 명시된 프로토콜에 의해 용이하게 된다.

여기에서 설명된 하나 이상의 구현은 새로운 실행가능 명령어를 생성하기 위해 파일이 컴파일될 때 실행되는 기능을 제공하는 컴파일시 반사(compile-time reflection)를 제공한다. 런 타임에서 실행되는 정규 반사는 런 타임 값으로의 액세스를 갖고, CTR보다 더욱 일반적이다. 그러나, 많은 경우에, 바람직한 새로운 실행가능 명령어는 실행 전에 알려진다. 이들 경우에, CTR은 컴파일 동안에 새로운 실행가능 명령어를 생성한다.

격리된 장치 드라이버의 구성을 지원하는 컴퓨터 아키텍처

몇몇 종래의 장치 드라이버는 드라이버의 실행가능 명령어를 커널의 실행가능 명령어로부터 격리하는 메커니즘 없이 커널의 주소 공간 및 하드웨어 보호 도메인 내로 로드된다. 그러나, 하나 이상의 설명된 구현은 격리된 장치 드라이버를 지원하는 운영 체제를 설명했다.

도 2는 격리된 익스텐션 및 장치 드라이버의 구성 및 여기에서 설명된 하나 이상의 구현을 지원하는 예시적인 운영 체제(OS) 아키텍처(200)를 도시한 것이다. 도시된 바와 같이, 예시적인 OS 아키텍처(200)는 커널(210), 하나 이상의 장치 드라이버(220), 하나 이상의 파일 시스템(230) 및 하나 이상의 애플리케이션(240)을 나타내고 있다. 본 분야에 숙련된 기술자들은 OS가 파일 시스템(330)과 같은 SIP에서 실행되는 추가 OS 서비스를 포함할 수 있다는 것을 알 수 있을 것이다.

커널(210)은 하드웨어 자원으로의 액세스를 제어하고, 메모리를 할당하고 그 반환을 요구하며, 스레드를 생성하고 스케쥴링하며, 프로세스내 스레드 동기화를 제공하고, I/O를 관리하는 특권 시스템 컴포넌트이다.

커널(210)은 OS의 핵심 기능을 제공한다. 그것은, 예를 들어 메모리 및 기타 하드웨어 자원의 관리, 프로세스 생성 및 종료, 프로세스간 통신, 채널 동작, 스케쥴링 및 I/O를 포함한다. 이들 커널(210)의 컴포넌트들의 일부로는 IO 매니저(211), 스케쥴러(212), 페이지 매니저(213), 장치 드라이버 조정자(214) 및 하드 웨어 추상화 계층(HAL)(215)을 포함한다.

이 예시적인 OS 아키텍처(200)에서의 실행가능 명령어는 검증되거나 신뢰된다. 검증된 명령어의 유형 안전성 및 메모리 안전성은 컴파일러에 의해 검사된다. 검증할 수 없는 명령어는 OS에 의해 신뢰받아야 하고, HAL(215), 커널(210), 및 신뢰성있는 런 타임(324, 334 및 344)의 부분들에 제한된다. 커널의 대부분은 검증할 수 있게 안전하다.

커널 및 신뢰성 있는 런 타임 외부의 모든 실행가능 명령어는 C# 또는 Java와 같은 안전한 언어로 기입되고, Microsoft® 중간 언어(MSIL)와 같은 안전한 중간 언어로 번역된 다음에, 하나 이상의 기타 백-엔드 컴파일러에 의해 프로세서 실행가능 명령어로 컴파일된다.

커널 명령어와 SIP의 명령어 사이의 경계선은 신뢰성 있는 런 타임 시스템에 의해 희미해진다. 신뢰성 있는 런 타임은 신뢰할 수 있지만 검증할 수 없는 실행가능 명령어를 포함한다. 런 타임의 실행가능 명령어는 SIP의 명령어들로부터 보호되는데, 그것은 그들의 검증된 유형 안전성이 안전한 인터페이스를 통하는 것 이외에는 그들이 런 타임 시스템 및 그 데이터 구조와 상호작용하지 않게 하기 때문이다. 많은 경우에, 백-엔드 컴파일러는 신뢰성 있는 런타임으로부터의 명령어를 SIP의 기타 실행가능 명령어 내로 안전하게 정렬할 수 있고, 이로 인해 종래에 커널 내에서 실행되었을 동작을 사용자 프로세스 내로 안전하게 이동할 수 있다.

장치 드라이버(220)의 실행가능 명령어는 하나 이상의 클래스 라이브러리(222) 및 그것의 신뢰성 있는 런타임(224)으로부터 장치 드라이버 플러스 실행가 능 명령어의 프로그래머에 의해 쓰여진 명령어를 포함한다. 이와 유사하게, 도시된 바와 같이, 파일 시스템(230)은 클래스 라이브러리(232) 및 그것의 신뢰성 있는 런타임(234)으로부터 실행가능 명령어를 포함한다. 게다가, 도시된 바와 같이, 애플리케이션(240)은 클래스 라이브러리(242) 및 그것의 신뢰성 있는 런타임(244)으로부터 실행가능 명령어를 포함한다.

도 3은 여기에서 설명된 하나 이상의 구현에 의해 지원된 예시적인 운영 체제(OS) 아키텍처(200)의 예시적인 장치 드라이버 프로세스(300) 내의 구성에 관련된 개체들 및 그외 다른 부분에 대한 이들의 관계를 도시한 것이다. 도시된 바와 같이, 예시적인 OS 아키텍처(200)는 OS 커널(210), 예시적인 장치 드라이버 프로세스(300), 및 하드웨어 및 기타 컴퓨팅 자원(350)을 나타내고 있다.

OS 커널(310)은 프로세스간 메시지 전달을 가능하게 하는 하나 이상의 채널(312)을 포함한다. 도시된 바와 같이, 하드웨어 및 기타 컴퓨팅 자원(350)은 I/O 포트(352)(I/O 레지스터라고도 알려져 있음), I/O 메모리(354), DMA 컨트롤러(356) 및 인터럽트 요청(IRQ) 라인(358)을 포함한다. 물론, 이들은 몇몇 하드웨어 및 기타 컴퓨팅 자원의 예일 뿐이다. 그외 다른 구현은 기타 일반적인 및 일반적이지 않은 하드웨어 및 기타 컴퓨팅 자원을 포함할 수 있다. 구현은 또한 두 개 이상의 I/O 포트(352), I/O 메모리(354), DMA 컨트롤러(356) 또는 인터럽트 요청 라인(358)을 포함할 수 있다. 어떤 구현은 이들 유형의 하드웨어 자원 모두를 포함하지 않을 수 있다.

예시적인 장치 드라이버 프로세스(300)는 장치 드라이버의 함수를 구현하는 개체인 장치 드라이버 개체(326)를 포함한다. 장치 드라이버 프로세스(300)는 또한 신뢰성 있는 런 타임(224), 0개 이상의 클래스 라이브러리(222) 및 구성 개체(328)를 포함한다.

장치 드라이버 개체(326)는 신뢰할 수 없는 프로그램 모듈의 한 예이다. 종래의 방법과 달리, 장치 드라이버의 실행가능 코드는 자유로운 관리가 부여되지 않는다. 그러나, 그것의 동작도 또한 어느 쪽에서나 감독되거나 감시되지 않는다. 그 대신에, 여기에서 설명된 하나 이상의 구현으로, 신뢰할 수 없는 드라이버는 제한된 컴퓨팅 자원들 집합으로의 자유롭지만 간접적인 액세스가 부여된다.

신뢰성 있는 런 타임(224)은 하드웨어 및 IPC 자원으로의 액세스를 중재하는 액세스 개체를 포함한다. 이들 액세스 개체는 (예시적인 것으로, 제한적인 것은 아님) IoPort(332), IoMemory(334), IoDma(336), IoIrq(338) 및 종점(340)을 포함한다. 신뢰성 있는 런 타임(224) 내의 액세스 개체는 다음과 같은 자원을 위한 게이트웨이로서 작용한다:

ㆍ IoPort(332) → I/O 포트(352);

ㆍ IoMemory(334) → 메모리(354);

ㆍ IoDma(336) → DMA 채널(356);

ㆍ IoIrq(338) → IRQ 라인(358);

ㆍ 종점(340) → 채널 핸들러(312).

종래의 장치 드라이버와 달리, 장치 드라이버 개체(326)의 실행가능 명령어를 포함하는 파일은 장치 드라이버를 구성하기 위한, 또는 참조번호(350)로 나타낸 것과 같은 하드웨어 및 기타 컴퓨팅 자원을 직접 액세스하기 위한 실행가능 명령어를 포함하지 않는다. 그 대신에, 장치 드라이버 개체(326) 내의 실행가능 명령어는 그 실행가능 명령어가 신뢰성 있는 런 타임(224) 내에 포함되는 액세스 개체(332, 334, 336, 338 및 340)를 통해 하드웨어 및 기타 컴퓨팅 자원을 액세스할 뿐이다.

구성 개체(328)를 작성하고, 개체(332, 334, 336, 338 및 340)를 액세스하기 위한 실행가능 명령어는 장치 드라이버 프로그래머에 의해 제공된 파일 내에 포함되지 않는다. 그 대신에, 장치 드라이버 프로그래머는 장치 드라이버용 실행가능 명령어에 부가된 메타데이터로서 구성 요구사항을 포함한다. 하나 이상의 설명된 구현에 따라, 구성 개체(328) 및 액세스 개체(332, 334, 336, 338 및 340)를 작성하는 실행가능 명령어는 장치 드라이버의 개체들의 나머지의 실행가능 명령어로부터 분리되어 떨어져서 설정된다.

하나 이상의 구현에서, 구성 개체(328)를 작성하는 실행가능 명령어는 운영 체제에 의해 제공된다. 한 구현에서, 이들 실행가능 명령어는 컴파일시 반사(CTR) 템플릿을 사용하여 설치시에 생성된다. CTR 템플릿은 장치 드라이버 내에 인코드된 구성 개체의 설명 내에 메타데이터로서 포함된 구성 요구사항을 처리한다. 다른 구현에서, CTR 템플릿은 장치 드라이버 개체(326)용 실행가능 명령어를 포함하는 파일 내의 구성 메타데이터로부터 그 일부분이 작성된 매니페스트를 처리한다. 다른 구현에서, 신뢰성 있는 런타임(224) 내의 실행가능 명령어는 구성 메타데이터 또는 장치 드라이버 매니페스트를 해석함으로써 구성 개체를 작성한다.

예시적인 OS 아키텍처(200)는 분리된 소프트웨어 격리 프로세스(SIP) 내의 각 장치 드라이버(이를테면 드라이버(220))를 실행한다. 예시적인 OS 아키텍처(200)는 다른 SIP의 페이지 상으로 기입할 수 있는 SIP가 하나도 없다는 것을 검증하기 위해 언어 안전성을 사용한다. SIP 내에 캡슐화되어 있으므로, 개별 드라이버는 전체 운영 체제를 내려받지 않고 필요에 따라 정지되고 재개시될 수 있다.

예시적인 OS 아키텍처(200)를 위한 프로그램은 설치시에 신뢰성 있는 런타임으로 정적으로 연결된다. 프로그램이 유형 안전성에 대해 정적으로 검증되지만, 각각의 신뢰성 있는 런타임은 그들 시스템의 신뢰성 있는 컴퓨팅 기반(TCB)의 한 컴포넌트이다. 신뢰성 있는 런타임으로부터의 실행가능 명령어는 프로세스 격리를 유지하여, 프로세스가 다른 프로세스의 메모리 및 하드웨어 자원에 영향을 미칠 가능성이 없이 호스트 프로세서의 특권/감시 모드로 실행될 수 있게 한다. 한 설명된 구현에서, 유형 안전성을 회피할 수 있는 동적 반사 또는 기타 메커니즘은 장치 드라이버 프로그래머에 의해 제공된 실행가능 명령어에서 허용되지 않는다.

장치 드라이버를 위한 신뢰성 있는 런타임은 하드웨어와의 통신을 추상하는 안전한 환경을 제공한다. 인터럽트 요청의 처리, 고정 메모리의 액세스, I/O 포트(I/O 레지스터로도 알려짐)의 액세스, 및 직접 메모리 액세스 컨트롤러(DMA)의 제어를 위한 프로세서 실행가능 명령어는 드라이버 런타임에 의해 노출된 액세스 개체를 통해 보호된다.

모든 프로세스간 통신(IPC)은 견고하게 유형화된 양방향 채널을 통한다. 이들 채널은 정확하게 2개의 종점을 갖는다. 한 채널 상의 메시지는 값 유형에 제한 되고, 이들 메시지의 포맷은 계약에 의해 정의된다. 계약은 또한 채널을 통해 보내진 메시지의 유효 순서를 지정하는 채널 프로토콜로서 소용되고, 통신을 시작하기 위한 주고받기 단계를 포함한다. 계약을 따르는 애플리케이션의 순응은 정적으로 검증될 수 있다.

몇몇 종점은 클라이언트에 의한 접속을 용이하게 할 수 있게 하기 위해 공용 이름을 갖는다. 이것은 단독으로 뿌리내린, 전역적으로 액세스 가능한 네임스페이스를 통해 달성된다. 글로벌 네임스페이스 서버는 네임스페이스를 관리하고, 이름에서 채널 종점, 디렉토리 및 기호 링크로의 매핑을 허용한다. 네임스페이스는 지속 보조 저장소에 부가되지 않는다. 그 대신에, 시스템 정책은 (파일시스템과 같은) 몇몇 애플리케이션이 네임스페이스 내에 가상 서브트리를 작성할 수 있게 하고 이들 트리에 콘텐트를 매핑할 수 있게 한다. 이것은 종래의 파일 시스템에 상당하는 것을 허용하고, 파일 액세스가 채널 추상화를 통한다는 점이 차이난다.

예시적인 OS 아키텍처(200)는 애플리케이션(이를테면, 참조번호(240))을 일등급(first-class) 엔티티로서 처리하는 추상화를 갖는데, 이것은 운영 체제가 애플리케이션에 대해 추론하여 보증을 제공할 수 있게 한다. 장치 드라이버는 이 추상화의 서브클래스이다. 더욱이, 장치 드라이버 설치는 애플리케이션 상에서 OS에 의해 실행된 일등급 동작이다.

예시적인 OS 아키텍처(200)에서, 장치 드라이버는 그것의 I/O 및 IPC 구성 요구사항을 선언한다. 종래의 방법에서, 구성 요구사항은 알아낼 수 없다. 여기에서, 구성 요구사항은 장치 드라이버의 실행가능 명령어와 동일한 파일 내에 인코 드된다. 인코드된 구성 요구사항은 보다 쉬운 처리를 위해, 구성 요구사항을 선언하는 독립 사양으로 변환될 수 있다.

구성 요구사항은 컴파일시, 설치시, 부팅시, 및 실행시에 검증가능하다. 실제로, 장치 드라이버와 동일한 파일로의 구성 요구사항의 인코딩은 구성 요구사항을 자기-설명 아티팩트(self-describing artifact)로 바꾼다. 장치 드라이버를 위한 MSIL 어셈블리의 집합이 주어지면, OS는 장치 드라이버가 정확하게 기능하기 위해 충족되어야 하는 구성 전제조건(및 소프트웨어와 하드웨어 자원에 대한 종속성)에 대해 완전히 추론할 수 있다.

애플리케이션 추상화 및 드라이버 구성 선언으로, 예시적인 OS 아키텍처(200)는 장치 드라이버에 의해 사용된 I/O 및 IPC 자원에 대한 보증을 제공한다. 예를 들어, OS는 새로운 장치 드라이버에 의해 요구된 자원들 집합을 그외 다른 모든 장치 드라이버에 의해 사용된 자원들 집합과 비교하고, I/P 포트 또는 I/O 메모리의 범위와 같은 자원들의 겹침-따라서 충돌-에 대해 조사함으로써, 드라이버가 실행되기 전에 구성 충돌을 검출할 수 있다. 양호한 실시예에서, 구성 충돌은 설치시에 검출되고, 설치는 새로운 장치 드라이버와, 이전에 설치된 모든 장치 드라이버를 포함하는 시스템의 나머지 사이에 충돌이 없는 경우에만 허용된다.

다른 예로서, OS는 각 장치 드라이버로부터 그 구성 종속성들을 추출한 다음에, 그 종속성들 중의 하나의 종속성 전에 초기화되는 장치 드라이버가 없도록 목록을 정렬함으로써, 유효 총 부트 순서-장치 드라이버가 초기화되는 순서-를 작성할 수 있다. 유효 총 시스템 부트 순서의 자동 작성은 부트 순서가 개발시에 OS 내로 하드 코드화되거나, 또는 부트 순서가 관리자에 의해 수동으로 갱신되는 이전의 시스템보다 상당한 발전한 것이다. 선언 구성 요구사항으로부터 도출된 보증의 마지막 예로서, OS는 드라이버의 구성 및 자원의 획득에 관련된 드라이버 초기화를 위한 실행가능 명령어의 전부를 생성할 수 있다. 이와 같이, OS는 드라이버가 선언된 자원만을 사용하고, 자원이 시스템 정책을 따라 획득된다는 것을 보증할 수 있다. 이들 능력은 런 타임 성능면에서 상당한 희생 없이도 시스템의 신뢰성 및 유지보수성을 증가시킬 수 있다.

장치 드라이버 조정

종래의 방법과 달리, 여기에서 설명된 하나 이상의 구현의 장치 드라이버 조정자(214)는 드라이버가 부적절한 메모리 위치 또는 기타 하드웨어 자원을 액세스하지 못하게 한다. 이와 반대로, 장치 드라이버 조정자는 드라이버가 적절한 메모리 위치 및 기타 하드웨어 자원만을 액세스할 수 있게 한다. 더욱이, 드라이버가 (종래의 방법이 허용하는 것인) 하드웨어 및 자원을 직접 액세스하기보다는, 커널(210)이 하드웨어 및 자원으로의 드라이버의 액세스를 조사한다.

여기에서 설명된 하나 이상의 구현은 3개의 계층: HAL(214), I/O 매니저(211) 및 드라이버(220)로 이루어진 입/출력(I/O) 시스템을 갖는다. HAL(214)은 컴퓨터의 하드웨어로의 액세스를 추상하는 신뢰성 있는 실행가능 명령어의 작은 기반이다. 예를 들어, 한 실시예에서, HAL은 하드웨어를 조작처리하는 4개의 액세스 개체: I/O 포트(352)(I/O 레지스터로도 알려짐)를 액세스하는 IoPort 개체(332), I/O 메모리(354)를 액세스하는 IoMemory 개체(334), DMA 컨트롤러(356)를 액세스하 는 IoDma 개체(336), 및 인터럽트 요청 라인(358)을 액세스하는 IoIrq 개체(338)를 구현했다. 한 실시예에서, HAL(314)은 또한 타이머, 인터럽트 컨트롤러 및 실시간 클록 하드웨어를 제어하는 실행가능 명령어를 포함한다. I/O 매니저(211)는 장치 드라이버를 초기화하고, 애플리케이션을 장치 드라이버(220)에 접속시킬 책임이 있다.

커널(210)은 직접 장치 드라이버(200) 구성 메타데이터를 사용하거나, 또는 각 장치 드라이버에 대한 매니페스트(예를 들어, 도 1에 도시된 프로세스 매니페스트(142))를 사용하여, 장치 드라이버(220)를 구성하고, 정확하게 실행할 필요가 있는 자원을 접속시킨다. 기동시에, 커널(210)은 시스템의 플러그 앤 플레이 구성을 한다. 커널(210)은 부트 로더에 의해 BIOS에 의해 획득되고 PCI 버스와 같은 버스로부터 획득된 정보를 사용하여, 장치를 열거하고, 적절한 장치 드라이버를 개시하며, 장치 하드웨어로 액세스를 캡슐화하는 이들 드라이버 개체를 넘긴다.

각 드라이버(220)는 안전한 실행가능 명령어로 기입되고, 그 자신의 프로세스에서 실행된다. 드라이버는 오로지 채널을 통해서, 네트워크 스택 및 파일 시스템을 포함한 시스템의 다른 부분과 통신한다. 드라이버가 시작될 때, I/O 매니저(211)는 장치 드라이버(220)의 매니페스트에 의해 요구된 대로, 장치 하드웨어(352, 354, 356 및 358)와 통신하기 위한 I/O 액세스 개체(332, 334, 336 및 338)를 제공한다. 모든 이러한 액세스 개체는 하드웨어의 메모리 맵 위치를 직접 액세스하기 전에 각 참조를 검사하는 안전한 인터페이스를 제공한다.

소프트웨어 격리를 사용하는 한 실시예에서, I/O 액세스 개체를 위한 전체 실행가능 명령어는 신뢰성 있는 런타임(324) 내에 포함되고, 장치 드라이버 프로세스(300) 내에서 실행된다. 하드웨어로의 액세스가 유효다는 것을 보증하기 위한 검사는 신뢰성 있는 런타임(224) 내의 I/O 액세스 개체(332, 334, 336 및 338) 내의 실행가능 명령어에 의해 실행된다. 하드웨어 격리를 사용하는 다른 실시예에서, 프로세서의 프로세스 격리 하드웨어는 드라이버가 액세스를 승인받은 I/O 포트 공간 또는 I/O 메모리 공간의 특정 영역만을 장치 드라이버가 액세스할 수 있게 프로그램된다. 하드웨어 격리를 사용하는 실시예에서, 프로세스 격리 하드웨어를 구성하는 실행가능 명령어는 OS 커널(210) 내에 존재한다.

드라이버 구성

하나 이상의 구현은 시스템의 부분들을 설명하기 위해 시스템 컴포넌트 내에 메타데이터로 인코드된 구성 요구사항을 사용하고, 그들이 함께 적합하게 하는 방법을 설명하며, 시스템의 다른 부분들과 그들의 동작 상호작용을 지정한다. 메타데이터는 커널, 애플리케이션 또는 장치 드라이버와 같은 시스템의 각 컴포넌트, 및 그 구성 요구사항을 선언적으로 분류 표시한다. 구성 요구사항은 종속성, 내보내진 서비스, 및 자원 요구사항에 대한 정보를 포함한다. 툴은 시스템 컴포넌트의 실행가능 명령어가 정확하게 구성될 수 있다는 것을 검증하기 위해 시스템 실행 전에 이 메타데이터를 사용한다. 이 메타데이터는 시스템의 각 컴포넌트가 프로그래머에 의해 의도된 대로 실행할 수 있도록 시스템의 각 컴포넌트를 정확하게 구성하기 위해 시스템 실행 동안에 사용된다.

시스템 메타데이터는 메니페스트라고 하는 하나 이상의 시스템 저장소 내에 보관된다. 최상위 레벨 시스템 매니페스트는 (장치 드라이버와 같은) 개별 컴포넌트를 설명하는 매니페스트를 나타낸다. 이들 매니페스트를 통해, 부트 로더 또는 시스템 검증기와 같은 소프트웨어는 시스템의 모든 컴포넌트를 밝혀낼 수 있다.

시스템 매니페스트는 시스템의 오프 라인 분석을 충분히 할 수 있게 한다. 여기에서 설명된 구현으로, 관리자는 하드웨어 장치 및 시스템 매니페스트의 설명만을 사용하여 다수의 "장치-드라이버" 관련 질의에 대한 응답을 알아낼 수 있다. 그러한 질의는, 예를 들어 시스템이 특정 하드웨어 상에서 부팅할 것인가, 어떤 드라이버 및 서비스를 초기화할 것인가, 및 어떤 애플리케이션이 실행될 수 있는가를 포함한다.

사양

실행가능 시스템 이미지는 메타데이터로서 포함된 전체 시스템에 대한 구성 요구사항을 포함한다. 메타데이터를 사용하여, 하나 이상의 설명된 구현은 3가지 불변성을 유지한다. 첫째, OS는 시스템의 다른 드라이버 또는 다른 부분과 충돌하는 구성 요구사항으로 인해 성공적으로 시작할 수 없는 장치 드라이버를 결코 설치하지 않을 것이다. 둘째, OS는 구성 충돌 또는 손실 자원으로 인해 성공적으로 실행할 수 없는 장치 드라이버를 결코 시작하지 않을 것이다. 셋째, 장치 드라이버는 그 구성 요구사항에 선언되어 있지 않은 자원을 런타임 시에 사용할 수 없다.

가능한 경우에, 여기에서 설명된 하나 이상의 구현은 구성 요구사항을 소스 코드 내로 인터리빙하기 위해 하이-레벨 언어로 된 사용자 지정 메타데이터 특성을 사용하므로, 단 하나의 소스 문서가 유지되어야 한다. 사용자 지정 특성은 클래 스, 메소드 또는 필드 선언과 같은 소스 코드 엔티티에 부가될 수 있다. 컴파일러는 결과적인 중간-언어 실행가능 명령어를 포함하는 파일 내로 특성을 인코드한다. 컴파일러, 링커(linker), 설치 툴 및 검증 툴은 명령어를 실행하고 있지 않더라도 실행가능 명령어로 인코드된 메타데이터를 판독할 수 있다.

한 예로서, 다음 소스 코드는 (S3^TMTTrio64^TM 비디오 장치 드라이버와 같은) 비디오 장치 드라이버의 구성 요구사항을 선언하기 위해 사용된 몇몇 특성을 나타낸다:

[DriverCategory] 및 [Signature] 특성은 PCI 비디오 장치의 특정 클래스를 위한 장치 드라이버가 되도록 이 모듈을 선언한다. DriverCategory는 특정 하드웨어를 위한 장치 드라이버를 구현하는 애플리케이션의 카테고리를 나타낸다. 그외 다른 카테고리는 소프트웨어 서비스를 구현하는 애플리케이션을 위한 ServiceCategory, 및 웹 서버로의 익스텐션을 위한 WebAppCategory를 포함한다.

[IoMemoryRange] 특성은 frameBuffer가 장치의 PCI 구성 공간 내의 제1 엔트 리에서 얻어진다는 것을 선언한다. 프레임 버퍼의 이 위치는 하드웨어가 구성될 때 결정되고, 메모리 영역의 크기와 같은 하드웨어 파라미터는 특성 내의 구성 값과 호환성이 있어야 한다. [IoFixedMemoryRange] 및 [IoFixedPortRange] 특성은 드라이버가 메모리 맵 액세스를 위한 주소 공간의 고정된 범위, 또는 장치 레지스터를 액세스하기 위한 I/O 포트의 고정된 범위를 필요로 한다는 것을 지정한다.

이 실시예에서, IoDmaRange, IoIrqRange IoMemoryRange 및 IoPortRange 개체는 연속적인 액세스 개체의 수집을 위한 컨테이너이고, 각각 IoDma, IoIrq, IoMemory 및 IoPort 액세스 개체와 교환 가능하게 사용될 수 있다.

[ExtensionEndpoint] 특성은 드라이버가 드라이버의 부모 프로세스와 통신하기 위한 채널 종점을 갖고 구성되어야 한다는 것을 선언한다. S3^TMTrio64^TM과 같은 장치 드라이버의 경우에, I/O 시스템은 부모 프로세스이다.

[ServiceEndpoint] 특성은 드라이버가 시스템 디렉토리 서비스에 대한 채널 종점을 갖고 구성되어야 하고, 비디오 드라이버를 사용하는 애플리케이션이 이 종점을 통해 디렉토리 서비스에 의해 장치 드라이버에 바인딩될 것이라는 것을 선언한다.

컴파일 시간

컴파일시에, 하이-레벨 언어 컴파일러는 장치 드라이버를 위한 중간-언어 실행가능 명령어를 포함하는 파일 내로 메타데이터로서 사용자 지정 특성을 포함한다. 중간-언어 메타데이터 액세스 라이브러리를 사용하여, 하나 이상의 설명된 구 현은 파일 내에 포함된 실행가능 명령어를 실행하지 않고 중간-언어 파일로부터 포함된 메타데이터를 검색할 수 있다.

연결시에, 메니페스트 작성 툴은 애플리케이션 매니페스트를 작성하기 위해 중간-언어로부터 사용자 지정 특성 메타데이터를 판독한다. 애플리케이션 매니페스트는 애플리케이션의 컴포넌트 및 구성 요구사항을 열거하는 XML 파일이다. 애플리케이션 매니페스트는 "Self-Describing Artifacts and Application Abstractions"에서 더욱 상세하게 설명된다.

다음 XML은 (S3^TMTrio64^TM 비디오 장치 드라이버와 같은) 비디오 장치 드라이버를 위한 매니페스트 정보의 일부를 포함한다:

설치 시간

여기에서 설명된 하나 이상의 구현으로, 시스템은 시작할 수 없는 장치 드라이버를 설치하는 것을 보증하지 않는다. 이것을 하기 위해, 시스템은 장치 드라이버의 전체 구성 요구사항이 장치 드라이버 설치 전에 충족될 수 있는 것을 검증한다.

애플리케이션은 여기에서 설명된 하나 이상의 구현을 지원하는 OS 내의 일등급 추상화이다. 이 개념은 "Self-Describing Artifacts and Application Abstractions"에서 더욱 상세하게 설명된다. 한 실시예에서, 실행되도록 하기 위해, 실행가능 명령어 집합은 그 구성 요구사항에 따라 애플리케이션을 초기화하도록 설치 관리자에 의해 애플리케이션에 추가된다. 대안적인 구현에서, 그 구성 요구사항에 따라 애플리케이션을 초기화하는 실행가능 명령어는 신뢰성 있는 런타임 내에 포함되고, 애플리케이션의 구성 메타데이터를 해석함으로써 구성 개체 및 액세스 개체를 작성한다.

설치 관리자는 애플리케이션의 매니페스트 내의 메타데이터에서 시작된다. 설치 관리자는 애플리케이션의 어셈블리 각각이 존재하고, 안전한 유형 및 메모리라는 것을 검증한다. 그것은 또한 모든 채널 계약이 정확하게 구현된다는 것을 검증한다.

일단 이들 내부 속성이 해결되고 검증되면, 설치 관리자는 그 다음에, 모든 외부 종속성을 해결하고 검증하고자 시도한다. 예를 들어, 설치 관리자는 장치 드라이버에 의해 사용된 임의의 하드웨어 자원이 임의의 다른 드라이버에 의해 요구 된 하드웨어 자원과 충돌하지 않는다는 것을 보장한다. 설치 관리자는 또한 애플리케이션에 의해 사용된 채널의 모든 유형의 존재를 검증한다. 애플리케이션이 채널을 내보내면, 설치 관리자는 내보내진 채널이 다른 애플리케이션과 충돌하지 않는다는 것을 검증한다. 충돌이 발생할 때, 시스템 매니페스트 내의 정책은 그것들을 해결한다. 예를 들어, 매니페스트는 단 하나의 장치 드라이버만이 비디오 콘솔 계약을 제공할 수 있다는 것을 선언할 수 있다. 추가 비디오 드라이버의 설치는 허가되지 않을 수 있고, 또는 단일 비디오 드라이버만이 부트시에 활성화될 수 있다.

CTR(Compile Time Reflection)은 시스템 자원을 위한 애플리케이션의 구성 개체 및 액세스 개체를 초기화하기 위해 신뢰성 있는 실행가능 명령어를 생성하는데 사용된다. 한 실시예에서, CTR 템플릿은 애플리케이션 매니페스트에 의해 명명된 어셈블리 내의 부속된 프로그램 요소의 처리를 설치시에 실행한다.

설치 프로세스는 새로운 애플리케이션 또는 장치 드라이버를 편입하도록 시스템 매니페스트 메타데이터를 갱신함으로써 완료된다.

최소한 하나의 구현에서, 전체 설치 프로세스는 다음 시스템 부트시에만 가시화되는 설치로 오프라인으로 발생한다. 대안적으로, 전체 설치 프로세스는 온라인으로 및/또는 부분적으로 온라인으로 실행될 수 있다.

런타임

런타임시에, 메타데이터는 커널, 장치 드라이버, 서비스 및 애플리케이션의 초기화를 구동시킨다. 부트 로더는 어떤 커널, 장치 드라이버 및 서비스가 로드될 것인지 판정하기 위해 시스템 매니페스트의 일부분을 판독한다. 이들이 로드하고 실행을 시작하는 순서는 어디에도 지정되지 않고; 그 대신에, 시스템은 지정된 종속성으로부터 그것을 추론한다.

각 애플리케이션이 시작됨에 따라, 커널은 모든 메타데이터 종속성을 검증하고 해결하며, 커널 내에 프로세스 구성 기록을 설정한다. CTR을 사용하여 애플리케이션으로 발행된 신뢰성 있는 실행가능 명령어는 구성 기록을 구문 분석하여, 구성 개체(328)를 작성하고, 외부 자원을 액세스하는 액세스 개체(332, 334, 336, 338, 340)를 작성한다. CTR은 구성 개체(428)를 위한 실행가능 명령어를 생성한다.

S3^TMTrio64^TM 장치 드라이버의 예로 되돌아가면, 커널은 frameBuffer, textBuffer 및 fontBuffer를 위한 IoMemoryRange 개체에 대한 요구를 드라이버의 구성 기록 내에 기록한다. 커널은 또한 control, advanced 및 gpstat I/O 포트를 위한 IoPortRange 개체를 기록한다. 커널은 장치 드라이버를 I/O 서브시스템에 접속하기 위한 채널, 및 드라이버를 네임스페이스에 접속하기 위한 제2 채널을 작성한다. 채널 종점은 드라이버의 구성 기록에 추가된다.

장치 드라이버가 실행을 시작할 때, 신뢰성 있는 런타임 내의 실행가능 명령어는 드라이버의 개체 공간 내에 적절한 IoMemoryRange 및 IoPortRange 액세스 개체를 작성한다. 이들이 신뢰성 있는 런타임에 의해서만 구성될 수 있기 때문에, 장치 드라이버는 그것의 구성 메타데이터로 선언되고, 커널 I/O 서브시스템에 의한 충돌에 대해 조사된 I/O 자원을 액세스할 수 있을 뿐이다.

구성 메타데이터로 채널 종점을 선언하는 것은 3가지 속성을 보장한다. 첫째, SIP를 위한 실행가능 명령어들은 그들이 엄격하게 채널 계약에 순응하여, 완전히 선언된 채널을 통해서만 통신한다는 보장이 정적으로 검증될 수 있다. 둘째, 애플리케이션은 글로벌 이름을 포함할 필요가 없다. 예를 들어, S3^TMTrio64^TM 비디오 장치 드라이버는 시스템 네임스페이스 내의 /dev/video name을 모른다. 그 대신에, 드라이버는 주어진 계약(ServiceProviderContract)에 따른 채널을 참조하기 위해 로컬 이름 S3Trio64Config.video를 사용한다. I/O 네임스페이스의 전체 레이아웃은 비디오 드라이버 내의 소스 코드의 단일 라인에 영향을 미치지 않고 바뀔 수 있다. 셋째, 애플리케이션은 현재 시스템 내의 에러 및 보안 취약성의 소스를 제거하기 위해 최소 가능 권한의 원리에 따라 "샌드박스화(sandboxed)"될 수 있다. 예를 들어, S3^TMTrio64^TM 드라이버가 시스템 디렉토리 서비스에 접속된 종점을 보유하긴 하지만, 드라이버는 새로운 이름을 작성하거나 임의의 다른 시스템 프로세스에 접속하는 능력이 없다.

격리된 장치 드라이버의 방법적 구현

도 4는 (장치 드라이버와 같은) 임의의 익스텐션의 초기화를 위한 방법(400)을 도시한 것이다. 이 방법(400)으로, OS는 장치 드라이버 개체를 작성하기 위해 장치 드라이버의 매니페스트로부터 메타데이터를 판독한다. 이 방법(400)은 도 1에 도시된 컴포넌트들 중의 하나 이상의 컴포넌트에 의해 실행된다. 더욱이, 이 방법(400)은 소프트웨어, 하드웨어, 펌웨어 또는 그 조합으로 실행될 수 있다.

도 4의 단계(402)에서, 운영 체제(OS)는 (장치 드라이버와 같은) 신뢰할 수 없는 프로그램 모듈을 얻는다. OS는 장치 드라이버의 매니페스트로부터 요구된 또는 요청된 컴퓨팅 자원의 집합을 결정한다. 여기에서, 컴퓨팅 자원은 (채널과 같은) 가상 자원 또는 (I/O 포트 또는 I/O 메모리의 범위와 같은) 하드웨어 자원 또는 기타 그러한 자원을 포함할 수 있다.

OS는 장치 드라이버의 매니페스트를 판독함으로써 이 결정을 할 수 있다. 대안적으로, OS는 장치 드라이버의 실행가능 명령어를 분석할 수 있다. 또한 대안적으로, OS는 실행가능 명령어 또는 관련된 데이터 구조로부터 메타데이터를 추출할 수 있다.

단계(404)에서, OS는 임의의 자원이 OS 또는 다른 장치 드라이버에 이미 할당되었는지 판정한다. 이미 할당되었으면, 프로세스는 단계(406)에서 중단된다. 본 발명의 대안적인 실시예는 자원이 자유로워졌을 때 초기화 프로세스를 재개시하고, 자원을 자유롭게 하도록 현재의 소유자와 협상하며, 사용자에게 충돌하는 드라이버를 정지시키는 허가를 요청하고, 잠재적으로 잘못될 가능성이 있는 자원 요청을 장치 드라이버 쓰기 프로그램(writer)에 통지하는 등등과 같은 추가 정책과 함께 중단을 따를 수 있다.

또한, 여기에서, OS는 장치 드라이버 및 요청된 컴퓨팅 자원에 관련된 다른 판정을 할 수 있다. OS는 장치 드라이버가 요청 컴퓨팅 자원을 액세스하도록 허용되고, 장치 드라이버가 요청하는 방식으로 그 자원을 액세스한다는 것을 확인한다.

단계(408)에서, OS는 장치 드라이버로의 자원의 할당을 기록한다.

단계(410)에서, OS는 장치 드라이버에 의해 사용될 신뢰성 있는 로컬-액세스 개체를 각각의 요구된 또는 요청된 자원에 제공한다. 신뢰성 있는 런타임 개체(도 3에 도시됨)는 로컬 액세스 개체의 예이다.

여기에서 OS가 실행하는 "제공"은 로컬-액세스 개체인 이미 미리 설정되고 고정된 실행가능 명령어(및 데이터)를 단순히 이용하는 것을 포함할 수 있다. 그것은 특정 요구 및 조건에 맞추어진 (아마도 템플릿에 기초한) 새로운 명령어를 생성하는 것을 포함할 수 있다. 또는, OS는 그 사이에 어떤 것을 할 수 있다. 예를 들어, 그것은 로컬-액세스 개체인 현존하는 실행가능 명령어를 구성하거나 약간 변경할 수 있다.

실제로, OS는 장치 드라이버가 삽입된 또는 연결된 로컬-액세스 개체를 통해 액세스를 얻을 수 있도록 신뢰할 수 없는 장치 드라이버에 신뢰성 있는 로컬-액세스 개체의 실행가능 명령어(및 데이터)를 삽입하거나 연결할 수 있다.

단계(412)에서, OS는 요구된 자원을 위한 로컬-액세스 개체들의 집합을 사용하여 장치 구성 개체를 초기화한다. 구성 개체는 매니페스트 내에 지정된 추가 설정을 포함할 수 있다. 추가 설정의 한 예는 정렬 익스텐션(sorting extension)에 사용자의 우선 데이터/시간 포맷을 알려주는 설정일 수 있다.

단계(414)에서, OS는 장치 드라이버 실행가능 명령어의 실행을 시작한다. 장치 드라이버를 초기화하는 실행가능 명령어는 장치 드라이버 프로그래머에 의해서가 아니고, OS 또는 설치 시스템에 의해 제공된다.

단계(416)에서, 실행 장치 드라이버는 로컬-액세스 개체를 통해 요청된 컴퓨팅 자원을 액세스한다. 더욱이, 실행 장치 드라이버는 연결된 또는 삽입된 로컬-액세스 개체를 통해서만, 요청된 컴퓨팅 자원(기타 자원 제외)을 액세스할 수 있을 뿐이다.

결론

여기에서 설명된 기술은 하나 이상의 컴퓨터 네트워크의 일부분으로서, 프로그램 모듈, 범용 및 특수 목적 컴퓨팅 시스템, 네트워크 서버 및 장비, 전용 전자부품 및 하드웨어, 펌웨어를 포함하고, 및/또는 그 조합을 포함하여(제한되는 것은 아님), 여러 방식으로 구현될 수 있다.

하나 이상의 위에서 설명된 구현은 구조적 특징 및/또는 방법적 단계에 특정된 언어로 설명되었지만, 그외 다른 구현이 여기에서 설명된 특정의 예시적인 특징 또는 단계 없이도 실시될 수 있다는 것을 이해할 것이다. 오히려, 특정의 예시적인 특징 및 단계는 하나 이상의 구현의 양호한 형태로서 개시된다. 몇몇 경우에, 잘 알려진 특징은 예시적인 구현의 설명을 명확하게 하기 위해 생략되었거나 단순화되었을 수 있다. 더욱이, 이해를 쉽게 하기 위해, 소정의 방법 단계들은 분리된 단계로서 설명되지만; 이들 분리되어 설명된 단계들은 그 단계들의 수행에서 반드시 종속된 순서로 해석되어서는 안 된다.

Claims

프로세서에 의해 실행될 때, 아래의 액트를 포함하는 방법을 실행하는 프로세서-실행가능 명령어들을 갖는 하나 이상의 프로세서-판독가능 매체에 있어서, 상기 방법은,

장치 드라이버(300)를 얻는 액트 - 상기 장치 드라이버(300)는 실행가능 명령어들의 집합임-;

상기 장치 드라이버(300)의 실행가능 명령어들 집합의 실행을 위해 요구된 컴퓨팅 자원들의 집합(312 및 350)을 결정하는 액트;

상기 요구된 컴퓨팅 자원들의 집합(312 및 350)으로의 액세스를 위해 상기 장치 드라이버(300)에 의해 사용하기 위한 하나 이상의 로컬-액세스 개체들(332, 333, 336, 338 및 340)을 제공하는 액트 - 상기 하나 이상의 로컬-액세스 개체들(332, 333, 336, 338 및 340)의 각각은 실행가능 명령어들을 포함함-; 및

상기 장치 드라이버(300)의 실행가능 명령어들의 집합 및 상기 하나 이상의 로컬-액세스 개체들(332, 333, 336, 338 및 340)의 실행가능 명령어들의 실행을 시작하는 액트

를 포함하는 하나 이상의 프로세서-판독가능 매체.
제1항에 있어서, 상기 결정하는 액트는 상기 장치 드라이버(300)와 관련된 프로세서-판독가능 매니페스트(manifest)(142)를 얻는 액트를 포함하고, 상기 장치 드라이버 매니페스트(142)는 상기 장치 드라이버(300)의 실행가능 명령어들 집합의 실행을 위해 요구된 상기 컴퓨팅 자원들의 집합(312 및 350)을 지정하는 하나 이상의 매체.
제1항에 있어서, 상기 방법은 상기 장치 드라이버(300)가 상기 요구된 컴퓨팅 자원들 집합(312 및 350)을 액세스하는 권한을 부여받은 것을 확인하는 액트를 더 포함하는 하나 이상의 프로세서-판독가능 매체.
제1항에 있어서, 상기 제공하는 액트는 상기 요구된 컴퓨팅 자원들 집합(312 및 350)으로의 액세스를 위해 상기 장치 드라이버(300)에 의해 사용하기 위한 하나 이상의 로컬-액세스 개체들(332, 333, 336, 338 및 340)을 생성하는 액트를 더 포함하고, 상기 로컬-액세스 개체는 운영 체제에 의해 제공되는 하나 이상의 프로세서-판독가능 매체.
프로세서에 의해 실행될 때, 아래의 액트를 포함하는 방법을 실행하는 프로세서-실행가능 명령어들을 갖는 하나 이상의 프로세서-판독가능 매체에 있어서, 상기 방법은,

실행가능 명령어들의 집합을 포함하고, 하나 이상의 컴퓨팅 자원들(312 및 350)을 액세스하도록 구성되는 신뢰할 수 없는 프로그램 모듈(300)을 얻는 액트;

상기 신뢰할 수 없는 프로그램 모듈(300)의 하나 이상의 대상 컴퓨팅 자원 들(312 및 350)을 결정하는 액트 - 상기 하나 이상의 대상 컴퓨팅 자원들(312 및 350)은 상기 신뢰할 수 없는 프로그램 모듈(300)의 실행가능 명령어들의 집합이 실행될 때 상기 신뢰할 수 없는 프로그램 모듈(300)이 액세스하려고 시도할 컴퓨팅 자원들(312 및 350)임-; 및

상기 신뢰할 수 없는 프로그램 모듈이 제공된 하나 이상의 신뢰성 있는 로컬-액세스 개체들(332, 333, 336, 338 및 340)을 통해 상기 하나 이상의 대상 컴퓨팅 자원들(312 및 350)로의 액세스를 얻도록 상기 신뢰할 수 없는 프로그램 모듈(300)에 하나 이상의 신뢰성 있는 로컬-액세스 개체들(332, 333, 336, 338 및 340)을 제공하는 액트

를 포함하는 하나 이상의 프로세서-판독가능 매체.
제5항에 있어서, 상기 신뢰성 있는 로컬-액세스 개체들(332, 333, 336, 338 및 340)의 각각은 하나 이상의 컴퓨팅 자원들(312 및 350)과 관련되고, 상기 신뢰성 있는 로컬-액세스 개체들(332, 333, 336, 338 및 340)의 각각은 실행가능 명령어들의 집합을 포함하는 하나 이상의 프로세서-판독가능 매체.
제5항에 있어서, 상기 신뢰성 있는 로컬-액세스 개체들(332, 333, 336, 338 및 340)의 각각은 하나 이상의 컴퓨팅 자원들과 관련되고, 상기 신뢰성 있는 로컬-액세스 개체들(332, 333, 336, 338 및 340)의 각각은 실행가능 명령어들을 포함하며, 상기 제공하는 액트는 상기 하나 이상의 신뢰성 있는 로컬-액세스 개체들(332, 333, 336, 338 및 340)의 구성된 실행가능 명령어들을 통해 상기 하나 이상의 대상 컴퓨팅 자원들(312 및 350)로의 상기 신뢰할 수 없는 프로그램 모듈(300) 액세스를 제공하도록 상기 하나 이상의 신뢰성 있는 로컬-액세스 개체들(332, 333, 336, 338 및 340)의 실행가능 명령어들을 구성하는 액트를 더 포함하는 하나 이상의 프로세서-판독가능 매체.
제5항에 있어서, 상기 신뢰할 수 없는 프로그램 모듈(300)은 장치 드라이버(300)인 하나 이상의 프로세서-판독가능 매체.
프로세서에 의해 실행될 때, 아래의 액트를 포함하는 방법을 실행하는 프로세서-실행가능 명령어들을 갖는 하나 이상의 프로세서-판독가능 매체에 있어서, 상기 방법은,

실행가능 명령어들의 집합을 포함하고, 하나 이상의 컴퓨팅 자원들(312 및 350)을 액세스하도록 구성되는 신뢰할 수 없는 프로그램 모듈(300)을 얻는 액트;

상기 신뢰할 수 없는 프로그램 모듈(300)의 하나 이상의 대상 컴퓨팅 자원들(312 및 350)을 결정하는 액트 - 상기 하나 이상의 대상 컴퓨팅 자원들(312 및 350)은 상기 프로그램 모듈의 실행가능 명령어들의 집합이 실행될 때 상기 신뢰할 수 없는 프로그램 모듈(300)이 액세스하려고 시도할 컴퓨팅 자원들(312 및 350)임-;

상기 신뢰할 수 없는 프로그램 모듈이 제공된 하나 이상의 신뢰성 있는 로컬 -액세스 개체들(332, 333, 336, 338 및 340)을 통해 상기 하나 이상의 대상 컴퓨팅 자원들(312 및 350)로의 액세스를 얻도록, 상기 신뢰할 수 없는 프로그램 모듈(300)에 하나 이상의 신뢰성 있는 로컬-액세스 개체들(332, 333, 336, 338 및 340)을 제공하는 액트 - 상기 하나 이상의 신뢰성 있는 로컬-액세스 개체들(332, 333, 336, 338 및 340)은 상기 하나 이상의 대상 컴퓨팅 자원들(312 및350)과 관련됨-; 및

상기 프로그램 모듈이 상기 하나 이상의 대상 컴퓨팅 자원들(312 및 350)과 관련된 상기 하나 이상의 신뢰성 있는 로컬-액세스 개체들(332, 333, 336, 338 및 340)을 통해서만 상기 하나 이상의 대상 컴퓨팅 자원들(312 및 350)을 액세스할 수 있게 하는 액트

를 포함하는 하나 이상의 프로세서-판독가능 매체.
제9항에 있어서, 상기 신뢰할 수 없는 프로그램 모듈(300)은 장치 드라이버(300)인 하나 이상의 프로세서-판독가능 매체.