[UEFI] Driver Execution Environment (DXE)

https://github.com/tianocore/tianocore.github.io/wiki/UEFI-EDKII-Learning-Dev

UEFI EDKII Learning Dev

2강의 내용을 정리한다.

---

DXE

DXE(드라이버 실행 환경)은 부팅 과정의 핵심적인 작업 대부분이 수행되는 단계다. 장치 열거 및 초기화가 이루어지고, UEFI 서비스가 지원되며, 각종 프로토콜과 드라이버가 구현된다. 또한 UEFI 인터페이스를 구성하는 System Table 등이 생성된다.

 

DXE는 'Green H'의 상단부에 위치한다. 이 시점에는 시스템 메모리가 이미 초기화된 상태이며, 칩셋 초기화 작업이 진행된다.

 

 

 

 

IMPORTANCE OF DXE

DXE는 부팅 프로세스에서 중요한 역할을 수행한다. DXE 단계의 유무에 따라 부팅 환경이 달라진다.

 

- DXE가 없는 경우

• BIOS 기능들이 제조사 독자 규격에 맞춰 코딩된다.
• 사실상 하나의 커다란 펌웨어 모듈이 부팅 흐름 전체를 통제하는 구조에 가깝다

- DXE가 있는 경우

• 마치 운영체제처럼 동작한다.
• 수많은 회사(제조사)들이 참여해 드라이버를 작성할 수 있다.

 

 

 

 

DXE FOUNDATION’S FUNCTIONS

DXE 단계의 심장부인 DXE 파운데이션은 다음과 같은 기능을 수행한다.

 

- 플랫폼 초기화: 칩셋과 플랫폼의 초기화를 담당한다.파운데이션의 주요 기능 중 하나는 부트 매니저와 운영체제를 로드할 수 있는 환경을 구축하는 드라이버들을 로드하는 것이다.

 

- DXE 디스패치: DXE 드라이버와 UEFI 드라이버 모두를 디스패치(로드 및 실행)를 담당한다. 특히 DXE 드라이버는 특정 의존성 규칙(DEPEX)을 가질 수 있다는 특징이 있다. 이러한 규칙은 논리 기반의 문법을 사용하며, 이를 통해 드라이버의 디스패치 순서가 결정된다.

 

- UEFI 디스패치: 모든 DXE 드라이버를 디스패치한 후 UEFI 드라이버를 디스패치한다. UEFI 드라이버는 DXE 드라이버와 달리 명시적인 의존성 규칙을 가지고 있지 않기 때문에, DXE 드라이버 이후에 실행된다. 비록 명시적인 의존성 규칙은 없으나, '모든 부트 서비스와 런타임 서비스가 초기화되어 있어야 한다'는 확실한 전제 조건이 따른다.

 

- 부트 매니저 로드 : DXE 디스패처는 각 드라이버의 진입점을 호출하고, 실행된 드라이버는 자신이 제공하는 프로토콜을 시스템에 설치한다. 이때 드라이버는 자신의 기능을 등록만 할 뿐 즉시 하드웨어를 제어하지는 않는다. 이러한 구조 덕분에 DXE 파운데이션은 실제 부팅에 필요한 장치가 결정될 때까지 구체적인 장치 초기화를 유보할 수 있다. 모든 준비가 끝나면 최종적으로 부트 매니저를 로드하고 제어권을 BDS 단계로 전달한다.

 

 

 

 

DXE FOUNDATION’S PROPERTIES

DXE 파운데이션의 주요 특성은 다음과 같다.

 

- HOB 리스트 의존성: DXE 파운데이션은 PEI 단계에서 생성된 HOB 리스트를 수신하는 것으로 실행을 시작한다. 초기화된 하드웨어 및 리소스의 모든 상태 정보는 이 HOB를 통해 PEI에서 DXE로 전달된다. 이러한 방식 덕분에 PI 아키텍처는 스택의 절대 주소나 DXE 파운데이션이 로드된 메모리 위치와 같은 고정된 주소 정보에 의존하지 않고도 유연하게 동작할 수 있다.

 

- 하드웨어 비종속성: DXE 파운데이션은 하드웨어 독립적으로 설계되어야 하며, 특정 하드웨어 환경에 종속된 코드를 포함해서는 안 된다. 만약 특정 I/O 주소가 고정되어 있다고 가정하고 해당 주소에 쓰기 작업을 수행할 경우, 시스템이 멈추거나 부팅 실패를 일으킬 수 있다. 따라서 DXE 파운데이션은 직접 하드웨어를 제어하는 대신, 하드웨어 접근을 추상화하여 제공하는 DXE 드라이버인 아키텍처 프로토콜을 사용하여 하드웨어를 제어한다.

 

- 하드코딩된 주소 부재: DXE 파운데이션은 하드코딩된 고정 주소를 사용하지 않으므로, 가용한 시스템 메모리의 어느 위치에든 로드되어 실행될 수 있다.

 

 

 

 

DXE COMPONENTS

- 드라이버: 프로세서, 칩셋 및 플랫폼 구성 요소의 초기화를 수행하는 모듈이다. 특히 일부 드라이버는 아키텍처 프로토콜(AP)을 생산하여, DXE 파운데이션이 특정 플랫폼 하드웨어에 직접 종속되지 않도록 하는 추상화 계층을 제공한다.

 

- 파운데이션 (DXE Core): DXE 단계의 메인 실행 바이너리이다. 드라이버의 디스패치를 주관하며, 시스템 전반에서 사용되는 부트 서비스, 런타임 서비스, 그리고 DXE 서비스를 생성하고 제공한다.

 

- 아키텍처 프로토콜 (APs): AP는 하드웨어와 DXE 파운데이션 사이를 격리하는 추상화 인터페이스다. DXE 드라이버가 이를 생성하면, DXE 파운데이션은 이 AP를 통해서만 하드웨어를 제어한다. 즉, 프로세서나 칩셋의 물리적 상세 사양을 캡슐화함으로써 파운데이션의 범용성을 보장한다.

 

- 디스패처: DXE 파운데이션의 내부 구성 요소다. 펌웨어 볼륨 내의 드라이버들을 탐색하고, 각 드라이버의 의존성 표현식(DEPEX)을 평가하여 정해진 의존성 규칙에 따라 올바른 순서대로 실행하는 스케줄러 역할을 수행한다

 

- UEFI 시스템 테이블: 펌웨어의 핵심 데이터 구조체다. 부트 및 런타임 서비스 테이블, 시스템 설정 테이블(ex: ACPI, SMBIOS), 그리고 콘솔 입출력 장치에 대한 포인터를 포함하고 있어, 드라이버나 애플리케이션이 UEFI의 다양한 기능과 데이터(핸들 데이터베이스 등)에 접근할 수 있는 중앙 관문 역할을 한다.

 

 

 

 

PEI TO DXE ENTRY

PEI에서 DXE로 전환되는 과정을 복습해보면 다음과 같다.

 

PEI 단계는 시스템 초기화를 수행하는 동안 발견된 모든 시스템 리소스와 상태 정보를 HOB 리스트에 저장한다. 초기화가 완료되면 PEI는 DXE IPL 모듈을 호출하여 실행 흐름을 넘긴다. 이후 DXE IPL은 DXE 파운데이션을 실행하고, 제어권을 넘겨받은 파운데이션은 펌웨어 볼륨에 접근하여 내장된 DXE 드라이버들을 추출하고 로드한다.

 

 

PEI 단계에서 DXE 파운데이션으로 시스템 상태 정보를 전달하는 핵심 매개체는 HOB 리스트이다. DXE 파운데이션은 이 HOB 리스트를 수신해 초기화가 완료된 시스템 상태를 파악한 뒤, 이후 작업을 진행한다.

 

DXE 파운데이션은 아키텍처 프로토콜들을 수집하고 로드함으로써 자신의 핵심 기능을 수행할 준비를 갖춘다. 구조적으로 볼 때 아키텍처 프로토콜(AP)은 DXE 파운데이션을 대신해 프로세서나 칩셋과 같은 플랫폼 하드웨어에 접근하는 역할을 담당하는 드라이버다.

 

따라서 DXE 파운데이션이 하드웨어 기능을 활용할 때는 직접 접근하기보다는 아키텍처 프로토콜이 제공하는 추상화된 인터페이스를 경유하는 것이 일반적이며, 하드웨어 제어는 이 AP 계층을 통해 이루어지도록 설계된다.

 

 

 

 

DXE PHASE FLOW

DXE 단계의 실행 프로세스는 크게 서비스 초기화, Apriori(선결) 처리, 그리고 일반 디스패치의 순서로 진행된다.

 

1. 핵심 서비스 초기화: 우선 DXE 파운데이션은 부트 서비스 및 런타임 서비스와 같은 시스템 핵심 서비스를 초기화한다. 이 초기화 작업이 완료되면, 파운데이션은 본격적으로 DXE 드라이버들을 디스패치하기 시작한다.

 

2. Apriori(선결) 파일 처리: DXE 디스패처는 가장 먼저 펌웨어 볼륨 내에서 Apriori(선결) 파일을 탐색한다. 이 파일은 시스템 구동에 필수적인 드라이버들의 목록을 담고 있다. 여기에 나열된 드라이버들은 일반적인 의존성 규칙(DEPEX)보다 우선권을 가지며, 리스트에 명시된 순서 그대로 강제 디스패치된다. 이때 디스패처는 해당 드라이버의 이미지를 시스템 메모리에 로드한 뒤, 드라이버의 엔트리 포인트를 호출하여 실행한다.

 

3. 일반 드라이버 탐색 및 디스패치: 'Apriori' 파일 처리가 완료되면, 디스패처는 펌웨어 볼륨 내에 남아있는 나머지 드라이버들을 대상으로 탐색을 이어간다. 이 과정은 모든 드라이버가 확인될 때까지 반복된다. 디스패처는 발견된 각 드라이버에 대해 의존성 표현식(DEPEX)을 평가하고, 필요한 자원이 모두 갖춰져 실행 가능한 상태인지 판단하여 로드 여부를 결정한다.

 

 

 

 

EFI SYSTEM TABLE

EFI 시스템 테이블은 시스템 내의 모든 데이터 구조체를 가리키는 포인터들의 집합체(데이터 구조체)다.

EFI 시스템 테이블은 단순한 메모리 주소가 아니라 시스템의 모든 핵심 데이터 구조체와 서비스에 접근할 수 있는 포인터들의 집합체인 구조체이다. 테이블의 작동 및 활용 방식은 다음과 같다.

 

1. 전달 및 접근: DXE 디스패처가 각 드라이버의 진입점을 호출할 때, EFI 시스템 테이블은 매개변수로 드라이버에 전달된다. 이 테이블 안에는 모든 시스템 서비스를 가리키는 포인터가 포함되어 있으므로, 드라이버는 이를 통해 필요한 시스템 자원에 접근할 수 있다.

 

2. 시스템 서비스의 분류: 시스템 서비스는 모든 UEFI 호환 시스템이 제공하는 표준 인터페이스를 의미하며, 그 성격에 따라 크게 세 가지로 분류된다.

• Boot Services: 시스템 서비스의 부분 집합으로, 오직 ExitBootServices() 함수가 호출되기 전(운영체제 로딩 전)까지만 유효하다. OS가 제어권을 넘겨받으면 메모리에서 해제된다.
• Runtime Services: 또 다른 부분 집합으로, ExitBootServices() 호출 전후와 관계없이, 운영체제 실행 중에도 계속해서 사용할 수 있는 상주 서비스다.
• System Configuration: ACPI나 SMBIOS와 같은 산업 표준 사양을 준수하는 정보 테이블들에 대한 포인터를 포함한다. 또한, 부팅 단계에서는 이 구성 테이블을 참조하여 DXE 서비스 테이블의 위치를 파악하기도 한다.

3. 주의사항: 시스템 구성 테이블(System Configuration)은 ExitBootServices() 실행 후에도 메모리에 남아 운영체제가 참조할 수 있다. 단 DXE 서비스 테이블 자체는 부팅 단계 전용이므로, 런타임 단계에서는 유효하지 않다는 점에 유의해야 한다.

 

 

 

 

DXE FOUNDATION DATA STRUCTURES

DXE 파운데이션은 시스템 관리를 위해 다양한 데이터 구조를 운용한다. 이 중에서 강의에서 언급된 주요 데이터 구조와 그 역할은 다음과 같다.

 

1. EFI 시스템 테이블: 드라이버의 진입점이 호출될 때 매개변수로 전달되는 최상위 데이터 구조체다.

• 시스템 구성 테이블 포인터: EFI 시스템 테이블은 시스템 구성 테이블을 가리키는 포인터를 포함한다. 이 구성 테이블은 GUID 포인터가 쌍을 이루는 구조로 되어 있어, 버전 정보나 펌웨어 업데이트 등에 활용된다.
• 콘솔 서비스: 현재 활성화된 콘솔(입출력 장치)에 대한 인터페이스를 제공한다. 개발자는 이를 통해 printf와 같은 문자열 출력 기능을 사용할 수 있다.

2. UEFI 부트 서비스와 핸들: 부트 서비스 테이블은 다양한 서비스 함수를 제공하며, 그중 대표적인 기능이 핸들 데이터베이스 관리다.

• 핸들의 정의: 모든 장치, 구성 요소, 이미지 등에 부여된 검색 가능한 고유 식별자를 의미한다.
• 핸들 데이터베이스 관리: DXE 파운데이션은 핸들 데이터베이스를 통해 드라이버가 생성한 프로토콜들을 관리한다. 프로토콜 핸들러 서비스는 이 데이터베이스를 검색하여 드라이버 간 연결을 지원한다.

3. 서비스 유효 범위 및 주의사항

• UEFI 런타임 서비스: 운영체제실행 중에도 계속 사용할 수 있는 서비스다.
• DXE 서비스: DXE 단계 전용 서비스로, 대부분 부팅 중에만 유효하다.
• 잘못된 의존성 주의: 시스템 구성 테이블 내에 DXE 서비스 테이블을 가리키는 포인터가 존재할 수 있다. 시스템 구성 테이블 자체는 OS 부팅 후에도 접근 가능하지만, 그 안의 DXE 서비스 포인터는 OS 실행 단계에서 유효하지 않다. 따라서 런타임 단계에서 부트 전용 서비스에 접근하지 않도록 각별히 주의해야 한다.

 

 

 

 

EVENTS

이벤트는 프로토콜과 같은 다른 객체에 신호를 전달하는 메시징 메커니즘이다. UEFI는 프로세서 아키텍처에 종속되지 않는 특성 때문에, 하드웨어 인터럽트 대신 이벤트를 사용하여 비동기 작업을 처리한다.

- Signal Events: 이벤트 상태가 Waiting에서 Signaled 상태로 전환될 때, 사전에 등록된 알림 함수가 실행되도록 예약되는 이벤트다.

• Exit Boot Services Events: UEFI 부트 서비스인 ExitBootServices()가 호출되는 시점에 대기 상태에서 Signaled 상태로 전환되는 이벤트다.
• Set Virtual Address Map Events: UEFI 런타임 서비스인 SetVirtualAddressMap()이 호출되는 시점에 Signaled 상태로 전환되는 이벤트다
• Timer Events: 지정된 시간이 경과하면 대기 상태에서 Signaled 상태로 전환되는 이벤트 유형이다.
  • Periodic Timer Events: 지정된 주기마다 대기 상태에서 Signaled 상태로 반복적으로 전환된다.
  • One Shot Timer Events: 설정된 시간이 경과한 직후, 대기 상태에서 Signaled 상태로 단 한 번만 전환된다.

 

- Wait Events: 주로 데이터 수신 대기와 같이 특정 조건이 충족될 때까지 실행을 잠시 멈추기 위해 사용된다. 일반적으로 WaitForEvent() 서비스와 함께 사용되며, 조건이 만족되면 대기 상태에서 Signaled 상태로 전환되어 대기 중이던 실행 흐름을 재개시킨다.

 

 

 

 

DXE FOUNDATION CODE FLOW

DXE 파운데이션의 실행 모델은 단일 스레드 환경과 단일 인터럽트라는 두 가지 속성을 기반으로 동작한다.

 

- 단일 스레드 환경

• 부트 스트랩 프로세서(BSP)만이 유일하게 DXE 파운데이션 코드를 실행하는 주체다.
• 나머지 모든 애플리케이션 프로세서(AP)는 별도의 명령이 있을 때까지 대기 모드 상태로 유지된다.

- 단일 인터럽트

• DXE 파운데이션은 시스템 타이머 틱을 아키텍처 상의 유일한 인터럽트 소스로 활용하여 시스템을 구동한다.
• 타이머 인터럽트만이 유일하게 활성화되어 있으므로, 모든 주변 장치 제어는 인터럽트 구동 방식이 아닌 폴링 방식을 따른다고 볼 수 있다.
• 즉 DXE 파운데이션은 복잡한 다중 하드웨어 인터럽트 처리 대신, 이벤트 메커니즘을 사용하여 비동기 작업을 처리한다.

 

 

 

 

DXE MAIN

DXE MAIN은 EDK II 구현에서 DXE 단계의 공식적인 Entry Point 함수다.

DXE MAIN은 DXE 파운데이션을 초기화하며, 구체적으로 다음과 같은 세부 기능을 수행한다.

 

- HOB 리스트 처리: PEI 단계에서 전달받은 HOB 리스트를 인수하여 메모리 정보 등을 파악한다.

- 주요 테이블 생성: 운영체제와 펌웨어 간의 인터페이스가 될 테이블들을 할당하고 초기화한다.

• EFI 시스템 테이블 (EFI System Table)
• UEFI 부트 서비스 테이블 (UEFI Boot Services Table)
• UEFI 런타임 서비스 테이블 (UEFI Runtime Services Table)
• DXE 서비스 테이블 (DXE Services Table)

- 메모리 기반 부트 서비스 활성화: 초기화 단계에서 메모리 전용 부트 서비스를 사용할 수 있도록 준비한다.

- 펌웨어 볼륨 접근 확보: 드라이버 로딩을 위해 펌웨어 볼륨에 대한 접근 권한을 획득한다.

- 제어권 전달: 모든 초기화 준비가 끝나면, DXE 디스패처에게 제어권을 넘겨 드라이버 로드 과정을 시작한다.

 

 

 

 

ARCHITECTURAL PROTOCOLS

DXE 드라이버는 DXE 파운데이션을 실제 하드웨어로부터 추상화하기 위해 아키텍처 프로토콜을 생성한다.

 

1. 기능 : 아키텍처 프로토콜은 플랫폼에 종속적인 하드웨어 세부 사항을 격리하는 래퍼역할을 수행한다.

• 예시: CPU 아키텍처 프로토콜은 인터럽트 관리, 프로세서 정보 조회, 타이머 제어 등의 기능을 제공한다. 덕분에 DXE 파운데이션은 하드웨어의 물리적 제어 방식을 직접 알지 못해도 해당 기능을 사용할 수 있다.

2. 지원: AP는 UEFI 부트 서비스와 런타임 서비스의 구현을 뒷받침하는 저수준 프로토콜이다. 상위 레벨의 플랫폼 함수들이 호출할 수 있는 하위 인터페이스를 제공함으로써 시스템 서비스를 지원한다.

 

3. 의존성: 특정 아키텍처 프로토콜은 다른 프로토콜에 의존성을 가질 수 있다.

• 예시: 워치독 타이머 AP가 작동하려면 I/O 접근 및 기본 타이머 기능이 먼저 활성화되어야 한다.
• 의존성 로드 순서 제어 방법: 드라이버 간의 의존성 문제를 해결하고 올바른 순서로 로드하기 위해 다음 세 가지 방법을 사용한다.
  • 의존성 표현식 (Depex): DXE 드라이버가 올바른 순서로 로드되도록, 드라이버 헤더에 필요한 프로토콜을 명시하는 문법이다. 디스패처는 이를 평가하여 로드 시점을 결정한다.
  • 프로토콜 알림 등록 : 특정 AP나 프로토콜이 설치되는 시점을 감지하여, 즉시 콜백 함수가 실행되도록 시스템에 알림을 등록하는 이벤트 기반 방식이다.
  • Apriori 리스트 : 펌웨어 볼륨 내에 존재하는 특수 파일이다. 여기에 나열된 드라이버들은 일반적인 DEPEX 평가보다 우선권을 가지며, 리스트에 명시된 순서대로 강제 로드된다.

DXE 파운데이션과 하드웨어 사이를 중재하는 아키텍처 프로토콜의 계층 구조를 나타낸다.

 

 

 

 

DXE APs’ LOCATIONS

 

 

 

 

DXE DISPATCHER

DXE 디스패처는 펌웨어 볼륨 내에서 탐색된 DXE 및 UEFI 드라이버를 메모리에 로드하고, 적절한 순서대로 실행하는 모듈이다.

 

DXE 디스패처의 목표

• 실행 순서 조정: UEFI 드라이버는 서로 다른 조직, 부서, 또는 벤더에 의해 작성될 수 있다. 따라서 DXE 디스패처는 드라이버 간의 의존성을 분석하여 충돌 없이 올바른 실행 순서를 결정하고 해결한다.
• 유지보수 및 패치 지원:
  • DXE 디스패처는 펌웨어 유지보수 과정에서 발생하는 이슈를 해결하기 위해, 긴급 패치를 적용하는 표준화된 방법을 지원한다.
  • 또한 개발자가 자신의 드라이버를 시스템에 보다 쉽게 통합할 수 있는 유연한 환경을 제공한다.
• 확장성: DXE 디스패처는 설계 단계부터 보안 검증과 같은 추가 기능을 수행할 수 있도록, 내부 로직에 확장 훅을 내장하고 있다.

 

 

 

 

DXE DISPATCHER DRIVER ENTRY POINT

DXE 디스패처 코드

EDK II - \MdeModulePkg\Core\Dxe\Image\Image.c

EDK I - - \Foundation\Core\Dxe\Image\Image.c

 

 

 

 

DXE DISPATCHER STATE MACHINE

위의 흐름도는 개별 드라이버 모듈이 DXE 디스패처의 제어 로직을 통과하며 겪게 되는 상태 변화 과정을 도식화한 것이다.

 

다음 내용에서 여러가지 DXE 드라이버의 예시를 통해, 이 상태 다이어그램이 구체적으로 어떻게 작동하는지 확인해보자.

 

 

 

 

DXE 디스패처 작동 예시

다음 내용은 DXE 디스패처의 상태 머신이 실제로 어떻게 작동하는지를 단계별로 보여준다. 전체적인 시스템 구성은 다음과 같다.

• Handle Database: 현재 시스템에 로드되어 사용할 수 있는 자원 목록이다. 아래 예제에서는 Loaded Image Protocol만 존재한다.
• DXE Dispatcher: 상태 머신을 통해 드라이버를 처리하는 DXE 디스패처의 내부 상태를 나타낸다.
• Main Firmware Volume: 펌웨어 볼륨에 저장된 DXE 드라이버 목록(Driver A, B, C)이다. 이 예제에서 해당 드라이버들은 모두 아키텍처 프로토콜이다.

 

1. 의존성 평가 실패

DXE 디스패처는 펌웨어 볼륨에 있는 드라이버들을 순차적으로 탐색한다. 그림의 사각형 A, B, C는 각각 드라이버 A, B, C를 나타낸다.

1. 탐색: DXE 디스패처는 가장 먼저 드라이버 A(Timer_AP)를 발견한다.
2. 의존성 확인: 드라이버 A의 의존성 표현식(Depex)을 분석한 결과, 이 드라이버가 실행되려면 CPU 아키텍처 프로토콜(CPU_AP)이 필수적임을 파악한다.
3. 평가: DXE 디스패처는 현재 핸들 데이터베이스를 조회하지만, 아직 CPU_AP가 생성되지 않았음을 확인한다.
4. 결과: 필요한 자원이 없으므로 의존성 표현식의 평가 결과는 거짓이 된다 결과적으로 드라이버 A는 Scheduled'상태로 넘어가지 못하고 Dependent'상태에 머물게 된다.

 

2. 의존성 평가 성공

드라이버 A의 실행이 보류된 후, DXE 디스패처는 다음 순서인 드라이버 B로 이동하여 의존성 검사를 계속 진행한다.

1. 순회: DXE 디스패처는 펌웨어 볼륨의 다음 모듈인 드라이버 B로 이동하여 의존성 표현식(Depex)을 검사한다.
2. 평가: 드라이버 B의 의존성 표현식을 평가한 결과, 참이 된다. 드라이버 B(CPU_AP)는 대개 다른 프로토콜에 의존하지 않거나, 이미 만족된 조건을 가지고 있기 때문에 즉시 실행 가능한 상태가 된다.
3. 결과: 평가 결과가 참이므로, 드라이버 B는 예약됨(Scheduled) 상태로 전환되어 실행 대기열에 추가된다.

 

3. 드라이버 B 스케줄링 및 드라이버 C 평가

DXE 디스패처는 앞서 의존성 평가를 통과한 드라이버 B를 스케줄링 상태로 전환한다. 이어서 DXE 디스패처는 펌웨어 볼륨 내의 다음 모듈인 드라이버 C를 탐색하고, 실행에 필요한 의존성을 분석한다.

• 의존성 조건: 드라이버 C는 CPU 아키텍처 프로토콜(CPU_AP)과 타이머 아키텍처 프로토콜(Timer_AP) 두 가지 모두를 요구한다.
• 자원 확인: DXE 디스패처가 현재 가용 자원(핸들 데이터베이스)을 확인한 결과, 아직 CPU_AP나 Timer_AP가 생성되지 않았음을 파악한다.
• 결과: 필수 자원이 부재하므로, 드라이버 C의 의존성 표현식 평가는 거짓이 된다.

 

4. 드라이버 B 초기화 완료 및 자원 등록

드라이버 B의 초기화가 성공적으로 완료되면, 이 드라이버가 생산한 CPU 아키텍처 프로토콜(CPU AP)은 이제 핸들 데이터베이스 내의 사용 가능한 자원으로 등록된다.

• 상태 변화: 드라이버 B는 Initializing 단계를 거쳐 Initialized 상태가 된다.
• 자원 갱신: 좌측의 핸들 데이터베이스를 보면, 기존의 Loaded Image Protocol 외에 새롭게 CPU Architectural Protocol이 추가된 것을 확인할 수 있다.

 

5. 드라이버 A 의존성 재평가 및 해결

DXE 디스패처는 보류 상태였던 드라이버 A로 다시 돌아가 의존성 표현식을 재평가한다.

1. 자원 조회: 디스패처는 핸들 데이터베이스를 조회하여, 앞서 드라이버 B가 설치한 CPU 아키텍처 프로토콜(CPU AP)이 현재 정의되어 있음을 확인한다.
2. 평가 결과: 필수 자원인 CPU AP가 존재하므로, 드라이버 A의 의존성 표현식은 이제 참으로 평가된다.

 

6. 드라이버 A 스케줄링 및 드라이버 C 평가

현재 시점에서 DXE 디스패처는 드라이버 A를 스케줄링 상태로 전환했고, 드라이버 B는 이미 초기화를 완료했다. 이제 디스패처는 드라이버 C에 대한 평가를 시작한다.

 

DXE 디스패처가 드라이버 C를 평가한 결과, 필수 의존성인 타이머 아키텍처 프로토콜(Timer AP)이 아직 존재하지 않으므로, 드라이버 C의 의존성 조건은 여전히 거짓으로 판정된다.

 

7. 드라이버 A 초기화 및 타이머 자원 등록

스케줄링 상태였던 드라이버 A가 실행되어 초기화를 완료한다. 이 과정에서 드라이버 A는 타이머 아키텍처 프로토콜(Timer AP)을 생산하여 핸들 데이터베이스 에 등록한다.

• 상태 변화: 드라이버 A의 상태가 Scheduled에서 Initialized로 변경되었다. 이제 드라이버 A와 B 모두 초기화가 완료된 상태다.
• 자원 갱신: 좌측 핸들 데이터베이스를 보면, 기존 자원에 3. Timer Architectural Protocol이 새롭게 추가된 것을 확인할 수 있다.

 

8. 드라이버 C 의존성 최종 해결

DXE 디스패처는 마지막으로 남은 '드라이버 C'에 대해 의존성 표현식을 재평가한다.

1. 자원 확인: 핸들 데이터베이스를 조회한 결과, 드라이버 C가 요구하던 CPU 아키텍처 프로토콜과 타이머 아키텍처 프로토콜(Timer AP)이 모두 등록되어 있음을 확인한다.
2. 최종 결과: 모든 의존성 문제가 해결되었으므로, 드라이버 C의 평가 결과는 참이 된다.

이제 드라이버 C 또한 Scheduled 상태로 전환되어 실행을 위한 준비를 마친다.

 

9. 드라이버 C 초기화 완료 (Final Step)

최종적으로 드라이버 C 또한 실행 대기열에 등록된 후, 앞선 드라이버 A, B와 마찬가지로 초기화 과정을 성공적으로 마친다.

• 상태 완료: DXE 디스패처의 상태창을 보면, 드라이버 A, B, C가 모두 초기화 완료 상태로 전환된 것을 확인할 수 있다.
• 디스패치 종료: 펌웨어 볼륨 내의 모든 드라이버가 의존성 규칙에 따라 순차적으로 로드되었으므로, 디스패처의 핵심 역할이 완수되었다.

 

 

 

 

Firmware Ordering

앞서 살펴본 예제에서 드라이버의 의존성 평가가 실패할 때마다 DXE 디스패처는 해당 드라이버를 건너뛰고 다른 드라이버를 탐색해야 했다.

• 문제점: 이러한 재탐색 및 반복적인 평가 과정은 결국 불필요한 오버헤드를 발생시켜, 전체 부팅 실행 흐름을 지연시키는 원인이 된다.
• 해결책: 이러한 지연을 방지하기 위해, 아키텍처 프로토콜(AP)과 같이 의존성 순서가 이미 명확하게 알려진 드라이버들에 대해서는 Apriori 파일을 사용하여 강제로 로드 순서를 지정할 수 있다.

Apriori 파일은 펌웨어 볼륨 내에서 가장 먼저 처리되어야 할 드라이버들의 GUID 목록을 담고 있으며, 디스패처는 이 리스트에 적힌 순서대로 드라이버를 즉시 로드하여 불필요한 탐색 비용을 줄인다.

 

 

 

 

DXE DRIVER TYPES

DDXE 드라이버는 장치 제어 및 시스템 서비스를 담당하는 모듈이다. 일반적으로 초기화 목적의 DXE 드라이버는 UEFI 드라이버 모델을 따르는 드라이버보다 먼저 실행된다. DXE 단계의 드라이버는 크게 다음 두 가지 유형 나누어 설명할 수 있다.

 

1. 초기 DXE 단계 드라이버 (Early DXE Phase Drivers)

• 실행 순서: DXE 단계에서 가장 먼저 실행된다.
• 의존성 관리: 실행 순서를 정의하기 위해 의존성 표현식(DEPEX)을 포함한다.
• 역할: DXE 파운데이션을 위한 아키텍처 프로토콜(AP)을 생산하여 하드웨어 추상화를 제공한다.
• 구성: 주로 시스템 기본 서비스, 플랫폼 초기화 코드, 그리고 프로세서 및 칩셋 초기화 코드를 포함한다.

2. UEFI 드라이버

• 초기화 특성 : Entry Point 실행 시점에는 하드웨어를 직접 초기화하거나 제어하지 않는다.
• 규격 준수: UEFI 드라이버 모델 규격을 철저히 준수한다.
• 기능 및 추상화: 콘솔 및 부팅 장치에 대한 접근을 제공하며, 버스 컨트롤러(Bus Controllers) 등을 추상화하여 상위 계층에 제공한다.
• 최적화: 모든 장치를 다 띄우는 것이 아니라, 운영체제 부팅에 실제로 필요한 드라이버만 선별적으로 연결되어 초기화된다.

 

 

 

 

BOOT DEVICE SELECTION (BDS) DRIVER

BDS 드라이버는 시스템 부팅을 위해 다음과 같은 작업을 수행한다.

• 콘솔 연결: 사용자와 상호작용할 수 있도록 키보드(입력)와 비디오(출력) 등의 콘솔 장치를 연결하고 활성화한다.
• 부트 옵션 처리: NVRAM에 저장된 UEFI 부트 순서와 부트 옵션을 분석한다. 이 정보를 바탕으로 리스트에 등록된 운영체제 로더를 순차적으로 호출하여 부팅을 시도한다.

 

 

 

 

SYSTEM MANAGEMENT MODE SERVICES

시스템 관리 모드(SMM) 서비스는 런타임 중에도 시스템 제어권을 확보할 수 있는 최고 우선순위 인터럽트인 시스템 관리 인터럽트(SMI)를 통해 구동되는 기능이다. SMM 구동을 위한 인프라는 DXE 단계에서 구축된다.

 

- 주요 특징

• 진입 벡터: SMI가 발생하면 프로세서는 실행 중인 작업을 즉시 중단하고, 사전에 정의된 특정 진입 벡터로 이동하여 SMM 코드를 실행한다.
• 보안 메모리: SMM 코드는 SMRAM이라 불리는 특수 영역에 상주한다. 보안을 위해 SMM 초기화가 완료된 후에는 외부 접근이 차단된다.
• 인터럽트 제어: SMI는 특정 하드웨어 이벤트나 시스템 인터럽트에 의해 생성되며, 소프트웨어적으로 이를 감지, 삭제, 또는 비활성화 할 수 있다.

- 서비스 구조

• 핸들러 구성: SMM 서비스는 SMI 발생 시 호출되는 핸들러들의 목록으로 구성되며, 기능적으로 DXE 파운데이션 서비스(Boot Services)의 축소판 성격을 띤다.
• 기능적 유사성 및 격리: SMM 서비스는 프로토콜 설치나 메모리 할당 등 DXE 서비스와 유사한 기능을 제공하지만, 실행 환경은 엄격히 구분된다. 모든 SMM 서비스는 오직 격리된 공간인 SMRAM 내부에서만 존재하고 실행된다.

 

 

 

 

SYSTEM MANAGEMENT MODE FLOW

DXE 단계의 실행 흐름 속에서 SMM이 어떻게 위치하고 구축되는지 살펴보자. DXE 디스패처가 실행하는 드라이버 중에는 SMM IPL(Initial Program Load) 생성자가 포함되어 있다. 이 생성자는 다음과 같은 과정을 통해 SMM 환경을 구축한다.

• 하드웨어 준비: 시스템 관리 인터럽트(SMI)가 정상적으로 생성 및 전달될 수 있도록 관련 하드웨어를 초기화한다.
• 자원 관리: SMM 자원 관리에 필요한 데이터 구조를 생성한다.
• SMRAM 적재 및 디스패치: 생성자는 자기 자신을 보안 메모리 영역인 SMRAM으로 복사하며, 이후 그 내부에서 미니 디스패처처럼 동작하며 SMM 전용 드라이버들을 관리한다