← Documents Documentation/admin-guide/efi-stub.rst GitHub 원문 ↗

Linux 6.18.37 · Administration / Boot

Linux EFI boot stub

EFI boot stub의 아키텍처별 구현, ESP 설치, 커널 인자와 initrd 및 device tree 전달 방법을 설명합니다.

Source pathDocumentation/admin-guide/efi-stub.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

EFI 실행 이미지와 부트 로더 역할

efi-stub.rst:1-28

x86, ARM, arm64 커널 이미지를 EFI 펌웨어가 직접 실행할 수 있게 만드는 stub의 코드 위치와 역할을 정리합니다.

ESP 설치와 명령줄

efi-stub.rst:29-82

커널 이미지를 ESP에 배치하고 EFI shell에서 커널 인자와 절대 EFI 형식 `initrd=` 경로를 전달하는 방법을 설명합니다.

device tree 대체

efi-stub.rst:83-100

`dtb=`로 펌웨어 device tree를 덮어쓸 때 런타임 정보가 사라지는 위험과 사용 조건을 다룹니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 =================
2 The EFI Boot Stub
3 =================
4
5 On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade
6 as a PE/COFF image, thereby convincing EFI firmware loaders to load
7 it as an EFI executable. The code that modifies the bzImage header,
8 along with the EFI-specific entry point that the firmware loader
9 jumps to are collectively known as the "EFI boot stub", and live in
10 arch/x86/boot/header.S and drivers/firmware/efi/libstub/x86-stub.c,
11 respectively. For ARM the EFI stub is implemented in
12 arch/arm/boot/compressed/efi-header.S and
13 drivers/firmware/efi/libstub/arm32-stub.c. EFI stub code that is shared
14 between architectures is in drivers/firmware/efi/libstub.
15
16 For arm64, there is no compressed kernel support, so the Image itself
17 masquerades as a PE/COFF image and the EFI stub is linked into the
18 kernel. The arm64 EFI stub lives in drivers/firmware/efi/libstub/arm64.c
19 and drivers/firmware/efi/libstub/arm64-stub.c.
20
21 By using the EFI boot stub it's possible to boot a Linux kernel
22 without the use of a conventional EFI boot loader, such as grub or
23 elilo. Since the EFI boot stub performs the jobs of a boot loader, in
24 a certain sense it *IS* the boot loader.
25
26 The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option.
27
28
29 How to install bzImage.efi
30 --------------------------
31
32 The bzImage located in arch/x86/boot/bzImage must be copied to the EFI
33 System Partition (ESP) and renamed with the extension ".efi". Without
34 the extension the EFI firmware loader will refuse to execute it. It's
35 not possible to execute bzImage.efi from the usual Linux file systems
36 because EFI firmware doesn't have support for them. For ARM the
37 arch/arm/boot/zImage should be copied to the system partition, and it
38 may not need to be renamed. Similarly for arm64, arch/arm64/boot/Image
39 should be copied but not necessarily renamed.
40
41
42 Passing kernel parameters from the EFI shell
43 --------------------------------------------
44
45 Arguments to the kernel can be passed after bzImage.efi, e.g.::
46
47 fs0:> bzImage.efi console=ttyS0 root=/dev/sda4
48
49
50 The "initrd=" option
51 --------------------
52
53 Like most boot loaders, the EFI stub allows the user to specify
54 multiple initrd files using the "initrd=" option. This is the only EFI
55 stub-specific command line parameter, everything else is passed to the
56 kernel when it boots.
57
58 The path to the initrd file must be an absolute path from the
59 beginning of the ESP, relative path names do not work. Also, the path
60 is an EFI-style path and directory elements must be separated with
61 backslashes (\). For example, given the following directory layout::
62
63 fs0:>
64 Kernels\
65 bzImage.efi
66 initrd-large.img
67
68 Ramdisks\
69 initrd-small.img
70 initrd-medium.img
71
72 to boot with the initrd-large.img file if the current working
73 directory is fs0:\Kernels, the following command must be used::
74
75 fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img
76
77 Notice how bzImage.efi can be specified with a relative path. That's
78 because the image we're executing is interpreted by the EFI shell,
79 which understands relative paths, whereas the rest of the command line
80 is passed to bzImage.efi.
81
82
83 The "dtb=" option
84 -----------------
85
86 For the ARM and arm64 architectures, a device tree must be provided to
87 the kernel. Normally firmware shall supply the device tree via the
88 EFI CONFIGURATION TABLE. However, the "dtb=" command line option can
89 be used to override the firmware supplied device tree, or to supply
90 one when firmware is unable to.
91
92 Please note: Firmware adds runtime configuration information to the
93 device tree before booting the kernel. If dtb= is used to override
94 the device tree, then any runtime data provided by firmware will be
95 lost. The dtb= option should only be used either as a debug tool, or
96 as a last resort when a device tree is not provided in the EFI
97 CONFIGURATION TABLE.
98
99 "dtb=" is processed in the same manner as the "initrd=" option that is
100 described above.
101

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

EFI boot stub의 구조

1-20

x86과 ARM 플랫폼의 커널 `zImage`/`bzImage`는 PE/COFF 이미지처럼 보이게 만들 수 있습니다. 그러면 EFI 펌웨어 로더가 이를 EFI 실행 파일로 인식해 로드합니다.

x86에서 bzImage 헤더를 수정하는 코드와 펌웨어 로더가 점프하는 EFI 전용 진입점을 통틀어 EFI boot stub이라 부릅니다. 각각 `arch/x86/boot/header.S`와 `drivers/firmware/efi/libstub/x86-stub.c`에 있습니다.

ARM의 EFI stub은 `arch/arm/boot/compressed/efi-header.S`와 `drivers/firmware/efi/libstub/arm32-stub.c`에 구현되어 있습니다. 아키텍처 사이에서 공유하는 EFI stub 코드는 `drivers/firmware/efi/libstub`에 있습니다.

arm64는 압축 커널을 지원하지 않으므로 `Image` 자체가 PE/COFF 이미지처럼 동작하고 EFI stub이 커널에 링크됩니다. arm64 구현은 `drivers/firmware/efi/libstub/arm64.c`와 `drivers/firmware/efi/libstub/arm64-stub.c`에 있습니다.

부트 로더 역할과 설정

21-28

EFI boot stub을 사용하면 grub이나 elilo 같은 전통적인 EFI 부트 로더 없이 Linux 커널을 부팅할 수 있습니다. EFI boot stub이 부트 로더의 작업을 수행하므로 어떤 의미에서는 stub 자체가 부트 로더입니다.

EFI boot stub은 커널 옵션 `CONFIG_EFI_STUB`으로 활성화합니다.

bzImage.efi 설치

29-41

`arch/x86/boot/bzImage`의 bzImage를 EFI System Partition(ESP)에 복사하고 `.efi` 확장자로 이름을 바꿔야 합니다. 확장자가 없으면 EFI 펌웨어 로더가 실행을 거부합니다.

EFI 펌웨어는 일반 Linux 파일시스템을 지원하지 않으므로 그곳에서 `bzImage.efi`를 실행할 수 없습니다. ARM은 `arch/arm/boot/zImage`를 시스템 파티션에 복사하며 이름 변경이 필요하지 않을 수 있습니다. arm64도 `arch/arm64/boot/Image`를 복사하되 반드시 이름을 바꿀 필요는 없습니다.

EFI shell에서 커널 매개변수 전달

42-49

커널 인자는 다음처럼 `bzImage.efi` 뒤에 전달할 수 있습니다.

fs0:> bzImage.efi console=ttyS0 root=/dev/sda4

initrd= 옵션

50-82

대부분의 부트 로더와 마찬가지로 EFI stub은 `initrd=` 옵션으로 여러 initrd 파일을 지정할 수 있습니다. 이것만 EFI stub 전용 명령줄 매개변수이며, 나머지 인자는 부팅할 때 커널에 그대로 전달됩니다.

initrd 경로는 ESP 시작점을 기준으로 한 절대 경로여야 하며 상대 경로는 동작하지 않습니다. 또한 EFI 형식 경로이므로 디렉터리 요소를 역슬래시(`\`)로 구분해야 합니다. 다음 디렉터리 배치를 예로 듭니다.

fs0:>
  Kernels\
          bzImage.efi
          initrd-large.img

  Ramdisks\
          initrd-small.img
          initrd-medium.img

현재 작업 디렉터리가 `fs0:\Kernels`일 때 `initrd-large.img`로 부팅하려면 다음 명령을 사용해야 합니다.

fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img

`bzImage.efi` 자체는 상대 경로로 지정할 수 있습니다. 실행할 이미지는 상대 경로를 이해하는 EFI shell이 해석하지만, 명령줄의 나머지 부분은 `bzImage.efi`에 전달되기 때문입니다.

dtb= 옵션

83-100

ARM과 arm64 아키텍처에서는 커널에 device tree를 제공해야 합니다. 일반적으로 펌웨어가 EFI CONFIGURATION TABLE을 통해 device tree를 제공하지만, `dtb=` 명령줄 옵션으로 펌웨어가 제공한 트리를 덮어쓰거나 펌웨어가 제공하지 못할 때 별도 트리를 전달할 수 있습니다.

펌웨어는 커널을 부팅하기 전에 런타임 구성 정보를 device tree에 추가합니다. `dtb=`로 트리를 덮어쓰면 펌웨어가 제공한 모든 런타임 데이터가 사라집니다. 따라서 `dtb=`는 디버깅 도구로 사용하거나 EFI CONFIGURATION TABLE에 device tree가 없을 때 마지막 수단으로만 사용해야 합니다.

`dtb=`는 앞에서 설명한 `initrd=` 옵션과 같은 방식으로 처리됩니다.