UEFI와 부팅 프로세스

2025년 2월 14일

ref #

펌웨어의 비밀을 통한 여행 1편
UEFI Spec Document
시난 - BIOS 부팅 구조
시난 - UEFI 부팅 구조

펌웨어 vs 커널 #

개발을 하다보면서 펌웨어와 커널의 경계가 어떤 것인지, 왜 역할이 비슷해 보이는지 궁금해서 정리하게 됐다.
컴퓨터가 실행되기 위해서는 아주 많은 과정을 거친다.

BIOS의 부팅과정에서 설명하겠지만, 전원을 넣으면 코드 실행에 필요한 하드웨어를 초기화하고 바이오스 펌웨어코드가 실행되며 메인보드의 여러 장치를 초기화한 뒤 부트로더와 커널을 실행시키는 과정이 진행된다.

실행되는 프로그램의 순서 #

프로그램 없이도 초기 동작을 보장하기 위한 하드와이어된 메인보드의 회로
- SRAM과 CPU를 초기화 해야한다.
- 하드와이어된 CPU 소켓의 초기화 회로
- 보조프로세서 + 보조프로세서의 펌웨어 로직 (이 경우엔 보조프로세서의 초기화는 하드와이어된 메인보드 회로가 담당)
초기화가 완료된 CPU는 정해진 동작을 수행한다.
- 특정 ROM의 주소에서 fetch, decode, execute 를 시도한다.
- CPU의 명령어 fetch 시작은 BootROM, Reset Vector 등으로 불리는 곳에서 시작한다.
메인보드 ROM의 프로그램 (+드라이버)
- 부팅을 위한 메인보드의 장치 컨트롤러 초기화
- 아주 기본적인건 펌웨어와 함께 ROM에 포함되어 있고, USB나 HDD 등에 있는 부트매니저를 실행시켜야 하기도 하고, 다른 드라이버가 포함되어 있을 수 있다.
운영체제 부트매니저
- 운영체제를 메모리에 로드하고 CPU에게 실행시킴
운영체제
- 하드웨어를 최적으로 사용할 수 있도록 동작하는 코드들 실행
- 여기에서 각 하드웨어를 다시 초기화함 (운영체제에 설치하는 드라이버)
- 사용자의 편의를 위한 응용프로그램 코드를 실행

펌웨어와 커널의 목적 #

결국 UEFI 펌웨어의 목적은 부팅이 가능하도록 만드는 것이고, 커널(운영체제)의 목적은 각 하드웨어를 잘 사용하도록 하는 것이다.

펌웨어와 커널 모두 동일한 방법으로 하드웨어를 조작하지만???? 동일한 방법이 맞나? 그것도 말이안될지도 모름. 펌웨어가 어떻게 IPORT를 바로 사용할 수 있나? 우머나우머나우먼ㅇ

, 로드되는 드라이버들의 목적도 다르기 때문에
펌웨어에서 로드되는 GOP 드라이버는 부팅과정에서 콘솔을 출력하기 위한 드라이버이고, 운영체제에서 로드되는 GPU 드라이버는 CUDA 등 최적의 하드웨어를 사용하기 위한 초기화이다.

TODO

펌웨어의 초기화에서는 메인보드에 연결된 컨트롤러마다 다른 방법으로 하드웨어를 조작하게 될텐데, 운영체제 개발자는 하드웨어의 직접적인 조작 방법을 알 수 없기 때문에 아주 기본적인 하드웨어의 조작방법을 통일시키는 목적도 있다. 그러니까 IOPort로 매핑시키는 역할은 펌웨어의 역할 그걸 사용해서

펌웨어와 커널의 연결 #

펌웨어를 개발하는 회사는, BootROM에 저장되어 하드웨어를 초기화하고, EFI 시스템 파티션의 정해진 경로에서 부트 매니저를 찾아 메모리에 적재한 뒤 실행하는 UEFI 펌웨어를 구현한다.

운영체제를 개발하는 회사는, 커널을 메모리에 올리고 실행하는 부트 매니저(=UEFI 앱)부터 책임진다.

이 둘은 서로 다른 주체가 개발하지만, 펌웨어가 UEFI 표준을 따른다면 부트 매니저는 아래와 같은 표준화된 진입점 시그니처를 구현하기만 하면 어떤 펌웨어에서도 동작할 수 있다.
그것이 BIOS와 UEFI의 가장 큰 차이이다.

1EFI_STATUS EFIAPI efi_main(IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable);

BIOS(Basic Input/Output System) #

ad1ed4a2-caf6-494d-b784-88429960a729

BIOS는 메인보드의 롬에 저장되어 PC가 전원을 켰을때 가장 먼저 실행되며 하드웨어 검사, 초기화 작업과 부팅 장치를 찾고 부트로더를 실행시켜 커널을 로드하는 작업을 수행한다.

MBR 방식의 디스크 구조와 함께 사용하며 텍스트 기반의 화면으로 16bit 실행 환경으로 동작한다.

어셈블리로 작성하기 때문에 코드가 제조사마다 제각각인 부분이 있었다.

MBR 구조 #

f52b5b80-dd8a-4c46-acdb-266ffa7642f4

헤더(LBA 0)는 446byte의 boot code와 파티션 정보가 담긴 partition table(64byte)로 구성되어 있다. partition 의 정보가 16byte 씩 총 4개를 저장할 수 있기 때문에 기본적으로 파티션은 총 4개까지 저장할 수 있다.
물론 파티션을 확장파티션으로 사용하면 그 파티션 내에 논리파티션을 넣을 수 있다.

23963758-e72b-4384-be1a-20239f81fd14

BootBlock : 디스크가 부팅 가능한 파티션일때 운영체제를 로딩하기 위한 코드가 담긴 영역이다. BIOS에서는 PBR(Partition Boot Record) 이라고 부르며 소속된 파티션에 대한 부트 코드가 담겨있다.
Volumn Control Block : 슈퍼블록이나 파일시스템 메타데이터로 불리며 논리파티션이나 파일시스템 단위의 블록 관련 정보를 저장한다.
File Control Block : 각각의 파일의 메타데이터(inode)를 저장하는 블록이다.
Root Directory : 루트디렉터리에서 부터 하위 디렉토리에 대한 정보가 담겨있다. 디렉터리마다 i-node 번호를 남겨 어떤 파일이 담겨있는지도 표시한다.
Free Space Management : 비트맵 등으로 어떤 블록이 사용중인지 체크하는 빈공간 관리자이다. 새로운 파일을 만들때나 확장할때 이 공간의 비트맵(연결리스트,트리 등)을 보고 사용가능한 블록을 찾는다.

부팅과정 (전원입력부터) #

전원입력부터 #

PC는 처음에는 연결되지 않은 회로였다가 power 버튼이 메인보드의 특정 회로를 연결시켜최소한의 전류가 공급된다. 회로가 연결되면 메인보드가 PSU(Power Supply Unit)에 신호를 보낸다.
PSU는 3.3V, 5V, 12V 등 여러 전압 레일을 생성해 메인보드로 공급하기 시작해서 몇ms 이후 전압이 안정적이게 되면 “PowerGood” 신호를 메인보드로 보내게된다.
메인보드는 “PowerGood” 신호를 받으면 메인보드와 연결된 부품을 순차적으로 활성화하기 시작한다.

보조프로세서 #

intel ME, AMD PSP 라는 보조프로세서가 있는데, CPU에 전원을 인가하기 전에 보조프로세서의 온칩 ROM 에서 ME/PSP 펌웨어를 찾아서 실행시킨다.
보조프로세서 펌웨어에서는 초기 하드웨어 설정과 일부 초기화를 담당한다.
- AMD Zen의 경우 보조프로세서 펌웨어가 DRAM 초기화까지 담당하고 메인보드의 BOOTROM 에서 BIOS(UEFI) 코드를 가져와 DRAM 초기 코드 실행위치에 올린다.

메인프로세서 (CPU) #

CPU는 아직 리셋 상태이며 계속 초기화되면서 실행을 멈춘 상태를 말한다. 보조프로세서가 펌웨어를 실행하고 나면 리셋 핀에서 전압을 해제하며 CPU의 실행이 시작된다.
DRAM이 아직 초기화된 상태가 아니기 때문에 CPU는 XIP+CAR 방식으로 BIOS의 코드를 실행시킨다. 이때 CPU는 16bit realmode로 시작한다.
- XIP : 메인보드의 BOOTROM 코드에서 직접 fetch 해서 한줄한줄 실행시키는 방법이다.
- CAR : 캐시메모리를 RAM 처럼 사용해서 stack 이나 전역변수 등을 사용하는 방법이다.
- AMD Zen 계열에서는 DRAM이 초기화 되고, BIOS를 올려주기 까지 했기 때문에 XIP, CAR 없이 DRAM에서 BIOS를 실행한다.

BIOS #

BIOS는 DRAM 혹은 ROM+SRAM(cache) 으로 실행되며 POST(Power On Self Test) 과정으로 하드웨어 초기화와 점검을 진행한다.
- RAM, CPU, 키보드, 그래픽카드 등 필수 하드웨어 점검
BIOS의 설정에 따라 부트 순서(ex. 하드디스크, CD-ROM, USB 순서 등)와 파티션 테이블, 부트 시그니쳐를 검사해서 부팅할 대상을 확인한다.
- 부트코드나 시그니쳐(0x55AA)가 없는 경우 데이터 저장용 MBR 디스크임을 알 수 있다.
부팅 대상(ex. 하드디스크)을 찾으면 해당 디바이스의 0번섹터(LBA 0 = 512byte = bootcode)를 DRAM의 특정 위치에 로드 후 bootcode를 실행시킨다.

MBR (bootcode) #

bootcode의 첫 명령어는 boot program으로 점프하는 코드이다.
bootprogram은 파티션 테이블을 분석해서 Active 플래그가 설정된 부팅 파티션을 찾고 그 파티션의 PBR(부트섹터)을 메모리로 로드한 후 실행한다.
- 하나의 디스크에선 여러 파티션이 있지만 단 하나만 Active 플래그를 설정해서 부팅 파티션으로 만들 수 있다.
PBR(얘도 512byte)은 파일시스템 타입(FAT, NTFS, ext 등)에 맞춰 파싱하고 OS 부트로더(Windows의 bootmgr, Linux의 GRUB) 파일을 찾아주는 작은 부트코드이며, OS의 부트로더를 찾아서 메모리에 로드하고 실행시킨다.
- OS의 부트로더는 수백 KB 단위이다. (/boot/grub/, c:\bootmgr)
- PBR도 512byte로 너무 작기 때문에 멀티부팅은 PBR이 찾아서 실행시켜주는 OS의 부트로더(bootmgr, GRUB, etc)에서 설정하고 관리된다.
OS의 부트로더가 OS 커널을 메모리에 로드하고 실행시키며 OS가 동작되게 된다. (윈도우는 커널로더가 따로 있다.)
- C:\bootmgr → C:\Windows\System32\winload.exe → ntoskrnl.exe → Windows OS
- /boot/grub → /boot/vmlinuz(커널) → Linux OS (initrd, systemd ...)

UEFI(Unified Extensible Firmware Interface) #

130c73c5-27b4-4aa0-98bc-83fc0c52deef

옛날부터 BIOS를 사용했지만 제조사별로 제각각이였던 것, 16bit 모드로 실행되는 것이나 MBR의 한계 등으로 인해 새로운 방식으로 펌웨어를 작성해야 했고, Intel이 주도해서 만든 UEFI가 표준화되어 자리잡게 되었다.

부팅프로세스 #

SEC(CPU초기화) -> PEI(메모리컨트롤러초기화) -> DXE(주변장치 드라이버초기화)

PEI에서 메모리 컨트롤러가 초기화되며 DXE Core를 DRAM에 로드하고 DXE 단계로 넘어간다.

UEFI 개발 #

UEFI는 개발킷을 사용해서 개발하게 되며, 오픈소스 UEFI 개발킷인 TianoCore EDK2 가 이 프로젝트에 사용된다.

코드는 c 형태로 구현하여 UEFI 애플리케이션, UEFI 드라이버, UEFI 펌웨어를 만들 수 있으며, .efi 파일로 빌드된다.

 1typedef unsigned short CHAR16;
 2typedef unsigned long long EFI_STATUS;
 3typedef void *EFI_HANDLE;
 4
 5struct _EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL;
 6typedef EFI_STATUS (*EFI_TEXT_STRING)(
 7  struct _EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL  *This,
 8  CHAR16                                   *String);
 9
10typedef struct _EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL {
11  void             *dummy;
12  EFI_TEXT_STRING  OutputString;
13} EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL;
14
15typedef struct {
16  char                             dummy[52];
17  EFI_HANDLE                       ConsoleOutHandle;
18  EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL  *ConOut;
19} EFI_SYSTEM_TABLE;
20
21EFI_STATUS EfiMain(EFI_HANDLE        ImageHandle,
22                   EFI_SYSTEM_TABLE  *SystemTable) {
23  SystemTable->ConOut->OutputString(SystemTable->ConOut, L"Hello, world!\n");
24  while (1);
25  return 0;
26}

빌드는 clang으로 COFF 형식의 obejct 파일을 만들고, lld-link 로 efi 용 PE 실행파일로 링킹한다.

1$ clang -target x86_64-pc-win32-coff -mno-red-zone -fno-stack-protector -fshort-wchar -Wall -c hello.c
2$ lld-link /subsystem:efi_application /entry:EfiMain /out:hello.efi hello.o

UEFI 펌웨어 #

BIOS에 대응하는 UEFI 펌웨어는 메인보드의 BOOTROM 에 저장되며 보조프로세서 펌웨어 초기화 이후 CPU가 메인보드의 UEFI 펌웨어를 로드시키고 실행시킨다. (또는 XPI+CAR 방식사용)

운영체제가 제공하는 UEFI 플래싱 유틸리티나 하드웨어 SPI 플래셔(CH341A)를 통해서 메인보드의 BOOTROM에 플래시 해야하고 여러 하드웨어를 초기화 후 OS의 bootloader를 실행시켜주는 역할을 한다.

ASUS 메인보드를 날려먹은 경험을 했을때 사용했던 asus ez flash 를 사용하거나 flashback 기능을 사용해서 플래시 하는게 UEFI 펌웨어인 것이다.

cebf4252-7b08-429a-ac45-5ff5cd6d723e

내부적으로 UEFI 드라이버가 포함되어 PE 파일을 포함시키지만, Firmware Volumn에 압축되어 있어서 UEFITool 같은 도구를 사용해야 확인할 수 있다.

d48610a3-708e-46be-bd53-e9275c01b748

많은 FV들로 모듈이 나뉘어 저장되고 각각의 FV에 압축된 바이너리들은 필요할때마다 해제/로딩 해서 사용한다.
SEC+PIE FVs, DXE FVs, BDS FVs, Recovery FVs, NVRAM 등 많은 종류의 데이터들이 많은 FV에 의해 나뉘어 저장된다.

OVMF는 TianoCore EDK2 기반의 가상머신(QEMU, KVM, VirtualBOX 등)에서 동작하는 UEFI 펌웨어 오픈소스 구현체이며, 메인보드 UEFI 펌웨어와 비슷한 기능을 제공한다. (실제로는 조금 부족하지만)

실질적인 메인보드 칩셋에 해당하는 UEFI 펌웨어는 제조사 외에 개발자가 구현하기 어렵지만, OVMF 펌웨어는 EDK2로도 빌드할 수 있다.

UEFI 드라이버 (DXE Driver) #

UEFI 펌웨어가 실행되며 수행하는 주변장치 초기화 과정은 DXE(Driver eXecution Environment) 라고 불리며, PEI 단계 이후 DRAM이 초기화되면 DXE Core와 DXE Driver를 실행하면서 시작되는데, 이때 실행되는 DXE Driver를 아래 같은 코드로 구현할 수 있다.

1EFI_STATUS EFIAPI DriverEntryPoint(
2    IN EFI_HANDLE ImageHandle,
3    IN EFI_SYSTEM_TABLE *SystemTable
4) {
5    // 장치 초기화코드..
6    Print(L"UEFI DXE Driver Loaded\n");
7    return EFI_SUCCESS;
8}

이 드라이버는 UEFI 펌웨어에 포함되어 실행되거나 UEFI Shell에서 load 명령으로 실행할 수 있다.

부팅 과정에서 로드할 드라이버를 빌드 후 빌드 시스템에 등록하고 UEFI 펌웨어를 빌드하면 포함된다.
드라이버라는건 해당 장치를 사용하기 위해 dll 처럼 메모리에 로드하면서 초기화 코드를 동작시키고 장치를 사용할 수 있는 API를 외부로 노출시킨 바이너리 파일인 것이다.

UEFI Shell #

3e4d1ffe-002b-4e12-b9e0-29da45078f02

UEFI 환경에서 제공되는 CLI 인터페이스이며 기본적으로 여러가지 명령어도 제공하고 있고, EFI 어플리케이션 실행, 파일관리, 드라이버로드 등의 기능을 수행할 수 있다.

메인보드에 설치된 기본 UEFI 펌웨어에서 UEFI Shell 옵션 제공
USB에 UEFI Shell (Shell.efi) 을 넣어서 부팅
QEMU 에서 OVMF를 사용해서 UEFI Shell 모드로 실행가능
```
1qemu-system-x86_64 -bios OVMF.fd -net none
```

UEFI 어플리케이션 #

b05f2cc1-2861-45a4-b05a-366b65303565

운영체제 없이 독립 실행이 가능한 PE/COFF 포맷의 .efi 확장자 파일이며, 디스크 파티션에 저장되고 UEFI Shell 환경에서 실행할 수 있다.

운영체제 종속성은 없지만, 구조는 Windows의 PE구조를 사용하고 UEFI API를 호출한다.

OS의 부트로더도 디스크에 저장된 EFI 어플리케이션 중 하나이며, bootx64.efi 이름으로 작성해서 파티션의 \EFI\BOOT\bootx64.efi 에 저장해두면 UEFI 펌웨어 실행 이후 자동으로 실행시켜준다.

GPT 구조 #

MBR과 달리 GPT는 GUID 기반으로 각 파티션의 종류를 구분하며, 파티션 정보가 담긴 엔트리는 128byte의 크기를 갖고 총 16KB로 최대 128개의 파티션까지 저장할 수 있다.

7a911a60-fee1-4562-8b2c-51a89715bcc7

LBA 0 (512byte) : MBR 기반 시스템에서도 인식할 수 있도록 하위호환을 위한 영역이다. BIOS에서는 MBR만 지원하여 이 영역을 읽어 부팅하며 수정하기도 하는데 UEFI 파티션에서 이 영역을 보호 영역으로 둬서 BIOS의 부팅을 실패하도록 하며 UEFI 파티션을 보호한다.
LBA 1 (512byte) : GPT Header. 디스크의 GPT 구조를 정의한다.
LBA 2~33 (16kb) : Partition Entry Table 역할을 하며 하나의 블록(LBA)당 4개씩 최대 128개의 파티션 엔트리가 저장된다.
LBA 34 ~ (n-34) : 실제 파티션이 저장되는 영역이다.
LBA (n-33) ~ (n-1) : Backup용 Partition Entry Table
LBA 마지막 : Secondary GPT Header (백업용 헤더)

GPT Header #

GPT 디스크에 대한 정보가 기록되는 영역이며, GPT 시그니쳐, 파티션 엔트리 테이블의 위치, 파티션 시작과 끝위치, 헤더와 파티션테이블의 CRC 체크섬 등이 저장된다.

111c726d-2229-4c7c-9da6-0546ff3bce01

Partition Entry #

파티션 엔트리의 구조를 나타내며, 파티션의 GUID, 이 파티션의 시작과 끝 LBA 위치, 속성이나 파티션 이름도 저장된다.

254fb009-66df-4eec-8246-03881a4d44a9

Paritition Attribute

부팅 과정 (UEFI 과정만) #

BIOS 처럼 보조프로세서가 CPU의 리셋을 해제해주면서 CPU가 XIP+CAR 방식으로 UEFI를 실행하는 것 까지는 동일하다.

ebe32e5a-2d4e-498f-9557-b76f38a28725

1. SEC (Security) #

보조프로세서에 의해 CPU의 리셋이 해제되며 SPI Flash에 있는 UEFI 코드를 XIP+CAR 방식으로 실행시킬 수 있도록 CPU를 준비하고 PIE 단계의 함수에게 제어권을 넘긴다.

2. PEI (Pre-EFI Initialization) #

아직까지는 XIP+CAR 방식으로 펌웨어 코드가 실행되고, 여기에서 메모리 컨트롤러가 초기화되며, DRAM을 사용할 수 있게 된다.

다음 단계인 DXE를 위해 HOB(Hand-Off Block)을 생성하고, DXE Core 코드와 DXE Driver를 DRAM에 로드한다.

HOB : PEI 가 초기화한 메모리맵 정보와 부트모드 정보, CPU 초기화 상태 외에도 DXE 드라이버가 필요로 하는 설정값 들을 저장해서 DXECore에 전달해준다.
PEI에서 BuildMemoryAllocationHob() 로 저장하고, DXE에서 GetFirstGuidHob() 로 값을 가져온다.

3. DXE(Driver eXecution Environment) #

DXE Core + DXE Driver 도 UEFI 펌웨어의 특정 FV(펌웨어 볼륨) 안에 존재하며, 해당되는 볼륨을 PEI에서 DRAM에 올려준다.

PE 포맷의 DXE Driver를 로드해서 주변장치들을 초기화하고, 하드웨어를 제어할 수 있도록 API를 제공하는 역할을 한다.

이때 파일시스템 드라이버도 로드되어 디스크를 인식 및 접근하고 GPT 파티션 테이블을 읽을 수 있게 되는데, 이후 BDS의 FV를 DRAM에 로드해서 실행시켜 BDS 단계로 넘어간다.

4. BDS(Boot Device Selection) #

부트매니저는 UEFI 펌웨어 FV중 하나인 NVRAM(가상머신에선 OVMF_VARS.fd)에 저장된 부트 변수를 확인하게 되고, 부팅 우선순위를 확인하게 된다.

396ad911-ce3b-49fa-bfa1-6fc79c368b07

우선순위에 따라 가장 먼저 실행되어야 하는 bootloader efi 파일을 EFI System Partition(ESP) 파티션에서 찾고 로드해서 실행시킨다.
그리고 bootloader에 해당하는 운영체제의 커널이 메모리에 로드되며 커널에게 제어를 넘기게 된다.

만약 NVRAM에 BootOrder에 아무런 데이터가 없거나 어떤 OS bootloader도 찾지 못한 경우 기본 부트로더로 \EFI\BOOT\bootx64.efi 를 사용하게 된다.

\EFI\Microsoft\Boot\bootmgfw.efi → C:\Windows\System32\Winload.efi → ntoskrnl.exe → Windows OS
\EFI\ubuntu\shimx64.efi → /boot/vmlinuz → Linux OS

BIOS vs UEFI #

부팅프로세스 #

BIOS
- PowerOn → 보조프로세서의 펌웨어 → 메인보드 ROM BIOS →
- MBR의 bootcode → 부팅 파티션의 PBR 부트섹터 →
- OS 설치 파티션 내 부트로더(=부트매니저) →
- (OS 파티션의 커널로더 →) OS Kernel
UEFI
- PowerOn → 보조프로세서의 펌웨어 → 메인보드 ROM UEFI →
- BDS 과정에서 ESP 파티션의 OS 부트로더(=부트매니저) →
- (OS 파티션의 커널로더 →) OS Kernel

Superfloppy #

MikanOS 에서는 파티션 테이블이 없는 슈퍼플로피 형태로 qemu의 부트 이미지를 제작하게 된다.

UEFI 사양 역시 이런 슈퍼플로피 이미지 형태에서도 부팅이미지를 찾을 수 있도록 정의되어 있고, OVMF가 가상 시스템을 타겟으로 만들어진 EDK2의 UEFI 펌웨어 구현체이기 때문에 이 사양을 준수하고 있다.

위에 작성한 UEFI의 부팅 방식은 UEFI + GPT 인 경우에 해당하는 방식이고, BIOS 부팅 메뉴에서 GPT 형식의 파티션 테이블 디스크 구조 말고도 파티션 없이 디스크 전체를 단일 볼륨으로 사용하는 슈퍼플로피 방식이 있는데, 이 방식 역시 UEFI 펌웨어(OVMF)로 부팅할 수 있는 디스크가 된다.

간단하게 부팅만을 위한 removable disk(usb)나 예제 등에서는 이런 슈퍼플로피 방식을 주로 사용한다.

사용 조건 #

디스크 전체를 하나의 UEFI 호환 시스템 파티션(주로 FAT)으로 포맷
루트 디렉터리에 \EFI\BOOT\BOOT{machine type short name}.EFI 경로로 부트로더를 저장하고 있어야함