요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
.. SPDX-License-Identifier: GPL-2.0
3
===========================
4
The Linux/x86 Boot Protocol
5
===========================
7
On the x86 platform, the Linux kernel uses a rather complicated boot
8
convention. This has evolved partially due to historical aspects, as
9
well as the desire in the early days to have the kernel itself be a
10
bootable image, the complicated PC memory model and due to changed
11
expectations in the PC industry caused by the effective demise of
12
real-mode DOS as a mainstream operating system.
14
Currently, the following versions of the Linux/x86 boot protocol exist.
16
============= ============================================================
17
Old kernels zImage/Image support only. Some very early kernels
18
may not even support a command line.
20
Protocol 2.00 (Kernel 1.3.73) Added bzImage and initrd support, as
21
well as a formalized way to communicate between the
22
boot loader and the kernel. setup.S made relocatable,
23
although the traditional setup area still assumed
24
writable.
26
Protocol 2.01 (Kernel 1.3.76) Added a heap overrun warning.
28
Protocol 2.02 (Kernel 2.4.0-test3-pre3) New command line protocol.
29
Lower the conventional memory ceiling. No overwrite
30
of the traditional setup area, thus making booting
31
safe for systems which use the EBDA from SMM or 32-bit
32
BIOS entry points. zImage deprecated but still
33
supported.
35
Protocol 2.03 (Kernel 2.4.18-pre1) Explicitly makes the highest possible
36
initrd address available to the bootloader.
38
Protocol 2.04 (Kernel 2.6.14) Extend the syssize field to four bytes.
40
Protocol 2.05 (Kernel 2.6.20) Make protected mode kernel relocatable.
41
Introduce relocatable_kernel and kernel_alignment fields.
43
Protocol 2.06 (Kernel 2.6.22) Added a field that contains the size of
44
the boot command line.
46
Protocol 2.07 (Kernel 2.6.24) Added paravirtualised boot protocol.
47
Introduced hardware_subarch and hardware_subarch_data
48
and KEEP_SEGMENTS flag in load_flags.
50
Protocol 2.08 (Kernel 2.6.26) Added crc32 checksum and ELF format
51
payload. Introduced payload_offset and payload_length
52
fields to aid in locating the payload.
54
Protocol 2.09 (Kernel 2.6.26) Added a field of 64-bit physical
55
pointer to single linked list of struct setup_data.
57
Protocol 2.10 (Kernel 2.6.31) Added a protocol for relaxed alignment
58
beyond the kernel_alignment added, new init_size and
59
pref_address fields. Added extended boot loader IDs.
61
Protocol 2.11 (Kernel 3.6) Added a field for offset of EFI handover
62
protocol entry point.
64
Protocol 2.12 (Kernel 3.8) Added the xloadflags field and extension fields
65
to struct boot_params for loading bzImage and ramdisk
66
above 4G in 64bit.
68
Protocol 2.13 (Kernel 3.14) Support 32- and 64-bit flags being set in
69
xloadflags to support booting a 64-bit kernel from 32-bit
70
EFI
72
Protocol 2.14 BURNT BY INCORRECT COMMIT
73
ae7e1238e68f2a472a125673ab506d49158c1889
74
("x86/boot: Add ACPI RSDP address to setup_header")
75
DO NOT USE!!! ASSUME SAME AS 2.13.
77
Protocol 2.15 (Kernel 5.5) Added the kernel_info and kernel_info.setup_type_max.
78
============= ============================================================
80
.. note::
81
The protocol version number should be changed only if the setup header
82
is changed. There is no need to update the version number if boot_params
83
or kernel_info are changed. Additionally, it is recommended to use
84
xloadflags (in this case the protocol version number should not be
85
updated either) or kernel_info to communicate supported Linux kernel
86
features to the boot loader. Due to very limited space available in
87
the original setup header every update to it should be considered
88
with great care. Starting from the protocol 2.15 the primary way to
89
communicate things to the boot loader is the kernel_info.
92
Memory Layout
93
=============
95
The traditional memory map for the kernel loader, used for Image or
96
zImage kernels, typically looks like::
98
| |
99
0A0000 +------------------------+
100
| Reserved for BIOS | Do not use. Reserved for BIOS EBDA.
101
09A000 +------------------------+
102
| Command line |
103
| Stack/heap | For use by the kernel real-mode code.
104
098000 +------------------------+
105
| Kernel setup | The kernel real-mode code.
106
090200 +------------------------+
107
| Kernel boot sector | The kernel legacy boot sector.
108
090000 +------------------------+
109
| Protected-mode kernel | The bulk of the kernel image.
110
010000 +------------------------+
111
| Boot loader | <- Boot sector entry point 0000:7C00
112
001000 +------------------------+
113
| Reserved for MBR/BIOS |
114
000800 +------------------------+
115
| Typically used by MBR |
116
000600 +------------------------+
117
| BIOS use only |
118
000000 +------------------------+
120
When using bzImage, the protected-mode kernel was relocated to
121
0x100000 ("high memory"), and the kernel real-mode block (boot sector,
122
setup, and stack/heap) was made relocatable to any address between
123
0x10000 and end of low memory. Unfortunately, in protocols 2.00 and
124
2.01 the 0x90000+ memory range is still used internally by the kernel;
125
the 2.02 protocol resolves that problem.
127
It is desirable to keep the "memory ceiling" -- the highest point in
128
low memory touched by the boot loader -- as low as possible, since
129
some newer BIOSes have begun to allocate some rather large amounts of
130
memory, called the Extended BIOS Data Area, near the top of low
131
memory. The boot loader should use the "INT 12h" BIOS call to verify
132
how much low memory is available.
134
Unfortunately, if INT 12h reports that the amount of memory is too
135
low, there is usually nothing the boot loader can do but to report an
136
error to the user. The boot loader should therefore be designed to
137
take up as little space in low memory as it reasonably can. For
138
zImage or old bzImage kernels, which need data written into the
139
0x90000 segment, the boot loader should make sure not to use memory
140
above the 0x9A000 point; too many BIOSes will break above that point.
142
For a modern bzImage kernel with boot protocol version >= 2.02, a
143
memory layout like the following is suggested::
145
~ ~
146
| Protected-mode kernel |
147
100000 +------------------------+
148
| I/O memory hole |
149
0A0000 +------------------------+
150
| Reserved for BIOS | Leave as much as possible unused
151
~ ~
152
| Command line | (Can also be below the X+10000 mark)
153
X+10000 +------------------------+
154
| Stack/heap | For use by the kernel real-mode code.
155
X+08000 +------------------------+
156
| Kernel setup | The kernel real-mode code.
157
| Kernel boot sector | The kernel legacy boot sector.
158
X +------------------------+
159
| Boot loader | <- Boot sector entry point 0000:7C00
160
001000 +------------------------+
161
| Reserved for MBR/BIOS |
162
000800 +------------------------+
163
| Typically used by MBR |
164
000600 +------------------------+
165
| BIOS use only |
166
000000 +------------------------+
168
... where the address X is as low as the design of the boot loader permits.
171
The Real-Mode Kernel Header
172
===========================
174
In the following text, and anywhere in the kernel boot sequence, "a
175
sector" refers to 512 bytes. It is independent of the actual sector
176
size of the underlying medium.
178
The first step in loading a Linux kernel should be to load the
179
real-mode code (boot sector and setup code) and then examine the
180
following header at offset 0x01f1. The real-mode code can total up to
181
32K, although the boot loader may choose to load only the first two
182
sectors (1K) and then examine the bootup sector size.
184
The header looks like:
186
=========== ======== ===================== ============================================
187
Offset/Size Proto Name Meaning
188
=========== ======== ===================== ============================================
189
01F1/1 ALL(1) setup_sects The size of the setup in sectors
190
01F2/2 ALL root_flags If set, the root is mounted readonly
191
01F4/4 2.04+(2) syssize The size of the 32-bit code in 16-byte paras
192
01F8/2 ALL ram_size DO NOT USE - for bootsect.S use only
193
01FA/2 ALL vid_mode Video mode control
194
01FC/2 ALL root_dev Default root device number
195
01FE/2 ALL boot_flag 0xAA55 magic number
196
0200/2 2.00+ jump Jump instruction
197
0202/4 2.00+ header Magic signature "HdrS"
198
0206/2 2.00+ version Boot protocol version supported
199
0208/4 2.00+ realmode_swtch Boot loader hook (see below)
200
020C/2 2.00+ start_sys_seg The load-low segment (0x1000) (obsolete)
201
020E/2 2.00+ kernel_version Pointer to kernel version string
202
0210/1 2.00+ type_of_loader Boot loader identifier
203
0211/1 2.00+ loadflags Boot protocol option flags
204
0212/2 2.00+ setup_move_size Move to high memory size (used with hooks)
205
0214/4 2.00+ code32_start Boot loader hook (see below)
206
0218/4 2.00+ ramdisk_image initrd load address (set by boot loader)
207
021C/4 2.00+ ramdisk_size initrd size (set by boot loader)
208
0220/4 2.00+ bootsect_kludge DO NOT USE - for bootsect.S use only
209
0224/2 2.01+ heap_end_ptr Free memory after setup end
210
0226/1 2.02+(3) ext_loader_ver Extended boot loader version
211
0227/1 2.02+(3) ext_loader_type Extended boot loader ID
212
0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line
213
022C/4 2.03+ initrd_addr_max Highest legal initrd address
214
0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel
215
0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not
216
0235/1 2.10+ min_alignment Minimum alignment, as a power of two
217
0236/2 2.12+ xloadflags Boot protocol option flags
218
0238/4 2.06+ cmdline_size Maximum size of the kernel command line
219
023C/4 2.07+ hardware_subarch Hardware subarchitecture
220
0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data
221
0248/4 2.08+ payload_offset Offset of kernel payload
222
024C/4 2.08+ payload_length Length of kernel payload
223
0250/8 2.09+ setup_data 64-bit physical pointer to linked list
224
of struct setup_data
225
0258/8 2.10+ pref_address Preferred loading address
226
0260/4 2.10+ init_size Linear memory required during initialization
227
0264/4 2.11+ handover_offset Offset of handover entry point
228
0268/4 2.15+ kernel_info_offset Offset of the kernel_info
229
=========== ======== ===================== ============================================
231
.. note::
232
(1) For backwards compatibility, if the setup_sects field contains 0,
233
the real value is 4.
235
(2) For boot protocol prior to 2.04, the upper two bytes of the syssize
236
field are unusable, which means the size of a bzImage kernel
237
cannot be determined.
239
(3) Ignored, but safe to set, for boot protocols 2.02-2.09.
241
If the "HdrS" (0x53726448) magic number is not found at offset 0x202,
242
the boot protocol version is "old". Loading an old kernel, the
243
following parameters should be assumed::
245
Image type = zImage
246
initrd not supported
247
Real-mode kernel must be located at 0x90000.
249
Otherwise, the "version" field contains the protocol version,
250
e.g. protocol version 2.01 will contain 0x0201 in this field. When
251
setting fields in the header, you must make sure only to set fields
252
supported by the protocol version in use.
255
Details of Header Fields
256
========================
258
For each field, some are information from the kernel to the bootloader
259
("read"), some are expected to be filled out by the bootloader
260
("write"), and some are expected to be read and modified by the
261
bootloader ("modify").
263
All general purpose boot loaders should write the fields marked
264
(obligatory). Boot loaders who want to load the kernel at a
265
nonstandard address should fill in the fields marked (reloc); other
266
boot loaders can ignore those fields.
268
The byte order of all fields is little endian (this is x86, after all.)
270
============ ===========
271
Field name: setup_sects
272
Type: read
273
Offset/size: 0x1f1/1
274
Protocol: ALL
275
============ ===========
277
The size of the setup code in 512-byte sectors. If this field is
278
0, the real value is 4. The real-mode code consists of the boot
279
sector (always one 512-byte sector) plus the setup code.
281
============ =================
282
Field name: root_flags
283
Type: modify (optional)
284
Offset/size: 0x1f2/2
285
Protocol: ALL
286
============ =================
288
If this field is nonzero, the root defaults to readonly. The use of
289
this field is deprecated; use the "ro" or "rw" options on the
290
command line instead.
292
============ ===============================================
293
Field name: syssize
294
Type: read
295
Offset/size: 0x1f4/4 (protocol 2.04+) 0x1f4/2 (protocol ALL)
296
Protocol: 2.04+
297
============ ===============================================
299
The size of the protected-mode code in units of 16-byte paragraphs.
300
For protocol versions older than 2.04 this field is only two bytes
301
wide, and therefore cannot be trusted for the size of a kernel if
302
the LOAD_HIGH flag is set.
304
============ ===============
305
Field name: ram_size
306
Type: kernel internal
307
Offset/size: 0x1f8/2
308
Protocol: ALL
309
============ ===============
311
This field is obsolete.
313
============ ===================
314
Field name: vid_mode
315
Type: modify (obligatory)
316
Offset/size: 0x1fa/2
317
============ ===================
319
Please see the section on SPECIAL COMMAND LINE OPTIONS.
321
============ =================
322
Field name: root_dev
323
Type: modify (optional)
324
Offset/size: 0x1fc/2
325
Protocol: ALL
326
============ =================
328
The default root device device number. The use of this field is
329
deprecated, use the "root=" option on the command line instead.
331
============ =========
332
Field name: boot_flag
333
Type: read
334
Offset/size: 0x1fe/2
335
Protocol: ALL
336
============ =========
338
Contains 0xAA55. This is the closest thing old Linux kernels have
339
to a magic number.
341
============ =======
342
Field name: jump
343
Type: read
344
Offset/size: 0x200/2
345
Protocol: 2.00+
346
============ =======
348
Contains an x86 jump instruction, 0xEB followed by a signed offset
349
relative to byte 0x202. This can be used to determine the size of
350
the header.
352
============ =======
353
Field name: header
354
Type: read
355
Offset/size: 0x202/4
356
Protocol: 2.00+
357
============ =======
359
Contains the magic number "HdrS" (0x53726448).
361
============ =======
362
Field name: version
363
Type: read
364
Offset/size: 0x206/2
365
Protocol: 2.00+
366
============ =======
368
Contains the boot protocol version, in (major << 8) + minor format,
369
e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version
370
10.17.
372
============ =================
373
Field name: realmode_swtch
374
Type: modify (optional)
375
Offset/size: 0x208/4
376
Protocol: 2.00+
377
============ =================
379
Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.)
381
============ =============
382
Field name: start_sys_seg
383
Type: read
384
Offset/size: 0x20c/2
385
Protocol: 2.00+
386
============ =============
388
The load low segment (0x1000). Obsolete.
390
============ ==============
391
Field name: kernel_version
392
Type: read
393
Offset/size: 0x20e/2
394
Protocol: 2.00+
395
============ ==============
397
If set to a nonzero value, contains a pointer to a NUL-terminated
398
human-readable kernel version number string, less 0x200. This can
399
be used to display the kernel version to the user. This value
400
should be less than (0x200 * setup_sects).
402
For example, if this value is set to 0x1c00, the kernel version
403
number string can be found at offset 0x1e00 in the kernel file.
404
This is a valid value if and only if the "setup_sects" field
405
contains the value 15 or higher, as::
407
0x1c00 < 15 * 0x200 (= 0x1e00) but
408
0x1c00 >= 14 * 0x200 (= 0x1c00)
410
0x1c00 >> 9 = 14, So the minimum value for setup_secs is 15.
412
============ ==================
413
Field name: type_of_loader
414
Type: write (obligatory)
415
Offset/size: 0x210/1
416
Protocol: 2.00+
417
============ ==================
419
If your boot loader has an assigned id (see table below), enter
420
0xTV here, where T is an identifier for the boot loader and V is
421
a version number. Otherwise, enter 0xFF here.
423
For boot loader IDs above T = 0xD, write T = 0xE to this field and
424
write the extended ID minus 0x10 to the ext_loader_type field.
425
Similarly, the ext_loader_ver field can be used to provide more than
426
four bits for the bootloader version.
428
For example, for T = 0x15, V = 0x234, write::
430
type_of_loader <- 0xE4
431
ext_loader_type <- 0x05
432
ext_loader_ver <- 0x23
434
Assigned boot loader ids (hexadecimal):
436
== =======================================
437
0 LILO
438
(0x00 reserved for pre-2.00 bootloader)
439
1 Loadlin
440
2 bootsect-loader
441
(0x20, all other values reserved)
442
3 Syslinux
443
4 Etherboot/gPXE/iPXE
444
5 ELILO
445
7 GRUB
446
8 U-Boot
447
9 Xen
448
A Gujin
449
B Qemu
450
C Arcturus Networks uCbootloader
451
D kexec-tools
452
E Extended (see ext_loader_type)
453
F Special (0xFF = undefined)
454
10 Reserved
455
11 Minimal Linux Bootloader
456
<http://sebastian-plotz.blogspot.de>
457
12 OVMF UEFI virtualization stack
458
13 barebox
459
== =======================================
461
Please contact <hpa@zytor.com> if you need a bootloader ID value assigned.
463
============ ===================
464
Field name: loadflags
465
Type: modify (obligatory)
466
Offset/size: 0x211/1
467
Protocol: 2.00+
468
============ ===================
470
This field is a bitmask.
472
Bit 0 (read): LOADED_HIGH
474
- If 0, the protected-mode code is loaded at 0x10000.
475
- If 1, the protected-mode code is loaded at 0x100000.
477
Bit 1 (kernel internal): KASLR_FLAG
479
- Used internally by the compressed kernel to communicate
480
KASLR status to kernel proper.
482
- If 1, KASLR enabled.
483
- If 0, KASLR disabled.
485
Bit 5 (write): QUIET_FLAG
487
- If 0, print early messages.
488
- If 1, suppress early messages.
490
This requests to the kernel (decompressor and early
491
kernel) to not write early messages that require
492
accessing the display hardware directly.
494
Bit 6 (obsolete): KEEP_SEGMENTS
496
Protocol: 2.07+
498
- This flag is obsolete.
500
Bit 7 (write): CAN_USE_HEAP
502
Set this bit to 1 to indicate that the value entered in the
503
heap_end_ptr is valid. If this field is clear, some setup code
504
functionality will be disabled.
507
============ ===================
508
Field name: setup_move_size
509
Type: modify (obligatory)
510
Offset/size: 0x212/2
511
Protocol: 2.00-2.01
512
============ ===================
514
When using protocol 2.00 or 2.01, if the real mode kernel is not
515
loaded at 0x90000, it gets moved there later in the loading
516
sequence. Fill in this field if you want additional data (such as
517
the kernel command line) moved in addition to the real-mode kernel
518
itself.
520
The unit is bytes starting with the beginning of the boot sector.
522
This field is can be ignored when the protocol is 2.02 or higher, or
523
if the real-mode code is loaded at 0x90000.
525
============ ========================
526
Field name: code32_start
527
Type: modify (optional, reloc)
528
Offset/size: 0x214/4
529
Protocol: 2.00+
530
============ ========================
532
The address to jump to in protected mode. This defaults to the load
533
address of the kernel, and can be used by the boot loader to
534
determine the proper load address.
536
This field can be modified for two purposes:
538
1. as a boot loader hook (see Advanced Boot Loader Hooks below.)
540
2. if a bootloader which does not install a hook loads a
541
relocatable kernel at a nonstandard address it will have to modify
542
this field to point to the load address.
544
============ ==================
545
Field name: ramdisk_image
546
Type: write (obligatory)
547
Offset/size: 0x218/4
548
Protocol: 2.00+
549
============ ==================
551
The 32-bit linear address of the initial ramdisk or ramfs. Leave at
552
zero if there is no initial ramdisk/ramfs.
554
============ ==================
555
Field name: ramdisk_size
556
Type: write (obligatory)
557
Offset/size: 0x21c/4
558
Protocol: 2.00+
559
============ ==================
561
Size of the initial ramdisk or ramfs. Leave at zero if there is no
562
initial ramdisk/ramfs.
564
============ ===============
565
Field name: bootsect_kludge
566
Type: kernel internal
567
Offset/size: 0x220/4
568
Protocol: 2.00+
569
============ ===============
571
This field is obsolete.
573
============ ==================
574
Field name: heap_end_ptr
575
Type: write (obligatory)
576
Offset/size: 0x224/2
577
Protocol: 2.01+
578
============ ==================
580
Set this field to the offset (from the beginning of the real-mode
581
code) of the end of the setup stack/heap, minus 0x0200.
583
============ ================
584
Field name: ext_loader_ver
585
Type: write (optional)
586
Offset/size: 0x226/1
587
Protocol: 2.02+
588
============ ================
590
This field is used as an extension of the version number in the
591
type_of_loader field. The total version number is considered to be
592
(type_of_loader & 0x0f) + (ext_loader_ver << 4).
594
The use of this field is boot loader specific. If not written, it
595
is zero.
597
Kernels prior to 2.6.31 did not recognize this field, but it is safe
598
to write for protocol version 2.02 or higher.
600
============ =====================================================
601
Field name: ext_loader_type
602
Type: write (obligatory if (type_of_loader & 0xf0) == 0xe0)
603
Offset/size: 0x227/1
604
Protocol: 2.02+
605
============ =====================================================
607
This field is used as an extension of the type number in
608
type_of_loader field. If the type in type_of_loader is 0xE, then
609
the actual type is (ext_loader_type + 0x10).
611
This field is ignored if the type in type_of_loader is not 0xE.
613
Kernels prior to 2.6.31 did not recognize this field, but it is safe
614
to write for protocol version 2.02 or higher.
616
============ ==================
617
Field name: cmd_line_ptr
618
Type: write (obligatory)
619
Offset/size: 0x228/4
620
Protocol: 2.02+
621
============ ==================
623
Set this field to the linear address of the kernel command line.
624
The kernel command line can be located anywhere between the end of
625
the setup heap and 0xA0000; it does not have to be located in the
626
same 64K segment as the real-mode code itself.
628
Fill in this field even if your boot loader does not support a
629
command line, in which case you can point this to an empty string
630
(or better yet, to the string "auto".) If this field is left at
631
zero, the kernel will assume that your boot loader does not support
632
the 2.02+ protocol.
634
============ ===============
635
Field name: initrd_addr_max
636
Type: read
637
Offset/size: 0x22c/4
638
Protocol: 2.03+
639
============ ===============
641
The maximum address that may be occupied by the initial
642
ramdisk/ramfs contents. For boot protocols 2.02 or earlier, this
643
field is not present, and the maximum address is 0x37FFFFFF. (This
644
address is defined as the address of the highest safe byte, so if
645
your ramdisk is exactly 131072 bytes long and this field is
646
0x37FFFFFF, you can start your ramdisk at 0x37FE0000.)
648
============ ============================
649
Field name: kernel_alignment
650
Type: read/modify (reloc)
651
Offset/size: 0x230/4
652
Protocol: 2.05+ (read), 2.10+ (modify)
653
============ ============================
655
Alignment unit required by the kernel (if relocatable_kernel is
656
true.) A relocatable kernel that is loaded at an alignment
657
incompatible with the value in this field will be realigned during
658
kernel initialization.
660
Starting with protocol version 2.10, this reflects the kernel
661
alignment preferred for optimal performance; it is possible for the
662
loader to modify this field to permit a lesser alignment. See the
663
min_alignment and pref_address field below.
665
============ ==================
666
Field name: relocatable_kernel
667
Type: read (reloc)
668
Offset/size: 0x234/1
669
Protocol: 2.05+
670
============ ==================
672
If this field is nonzero, the protected-mode part of the kernel can
673
be loaded at any address that satisfies the kernel_alignment field.
674
After loading, the boot loader must set the code32_start field to
675
point to the loaded code, or to a boot loader hook.
677
============ =============
678
Field name: min_alignment
679
Type: read (reloc)
680
Offset/size: 0x235/1
681
Protocol: 2.10+
682
============ =============
684
This field, if nonzero, indicates as a power of two the minimum
685
alignment required, as opposed to preferred, by the kernel to boot.
686
If a boot loader makes use of this field, it should update the
687
kernel_alignment field with the alignment unit desired; typically::
689
kernel_alignment = 1 << min_alignment;
691
There may be a considerable performance cost with an excessively
692
misaligned kernel. Therefore, a loader should typically try each
693
power-of-two alignment from kernel_alignment down to this alignment.
695
============ ==========
696
Field name: xloadflags
697
Type: read
698
Offset/size: 0x236/2
699
Protocol: 2.12+
700
============ ==========
702
This field is a bitmask.
704
Bit 0 (read): XLF_KERNEL_64
706
- If 1, this kernel has the legacy 64-bit entry point at 0x200.
708
Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G
710
- If 1, kernel/boot_params/cmdline/ramdisk can be above 4G.
712
Bit 2 (read): XLF_EFI_HANDOVER_32
714
- If 1, the kernel supports the 32-bit EFI handoff entry point
715
given at handover_offset.
717
Bit 3 (read): XLF_EFI_HANDOVER_64
719
- If 1, the kernel supports the 64-bit EFI handoff entry point
720
given at handover_offset + 0x200.
722
Bit 4 (read): XLF_EFI_KEXEC
724
- If 1, the kernel supports kexec EFI boot with EFI runtime support.
727
============ ============
728
Field name: cmdline_size
729
Type: read
730
Offset/size: 0x238/4
731
Protocol: 2.06+
732
============ ============
734
The maximum size of the command line without the terminating
735
zero. This means that the command line can contain at most
736
cmdline_size characters. With protocol version 2.05 and earlier, the
737
maximum size was 255.
739
============ ====================================
740
Field name: hardware_subarch
741
Type: write (optional, defaults to x86/PC)
742
Offset/size: 0x23c/4
743
Protocol: 2.07+
744
============ ====================================
746
In a paravirtualized environment the hardware low level architectural
747
pieces such as interrupt handling, page table handling, and
748
accessing process control registers needs to be done differently.
750
This field allows the bootloader to inform the kernel we are in one
751
one of those environments.
753
========== ==============================
754
0x00000000 The default x86/PC environment
755
0x00000001 lguest
756
0x00000002 Xen
757
0x00000003 Intel MID (Moorestown, CloverTrail, Merrifield, Moorefield)
758
0x00000004 CE4100 TV Platform
759
========== ==============================
761
============ =========================
762
Field name: hardware_subarch_data
763
Type: write (subarch-dependent)
764
Offset/size: 0x240/8
765
Protocol: 2.07+
766
============ =========================
768
A pointer to data that is specific to hardware subarch
769
This field is currently unused for the default x86/PC environment,
770
do not modify.
772
============ ==============
773
Field name: payload_offset
774
Type: read
775
Offset/size: 0x248/4
776
Protocol: 2.08+
777
============ ==============
779
If non-zero then this field contains the offset from the beginning
780
of the protected-mode code to the payload.
782
The payload may be compressed. The format of both the compressed and
783
uncompressed data should be determined using the standard magic
784
numbers. The currently supported compression formats are gzip
785
(magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
786
(magic number 5D 00), XZ (magic number FD 37), LZ4 (magic number
787
02 21) and ZSTD (magic number 28 B5). The uncompressed payload is
788
currently always ELF (magic number 7F 45 4C 46).
790
============ ==============
791
Field name: payload_length
792
Type: read
793
Offset/size: 0x24c/4
794
Protocol: 2.08+
795
============ ==============
797
The length of the payload.
799
============ ===============
800
Field name: setup_data
801
Type: write (special)
802
Offset/size: 0x250/8
803
Protocol: 2.09+
804
============ ===============
806
The 64-bit physical pointer to NULL terminated single linked list of
807
struct setup_data. This is used to define a more extensible boot
808
parameters passing mechanism. The definition of struct setup_data is
809
as follow::
811
struct setup_data {
812
__u64 next;
813
__u32 type;
814
__u32 len;
815
__u8 data[];
816
}
818
Where, the next is a 64-bit physical pointer to the next node of
819
linked list, the next field of the last node is 0; the type is used
820
to identify the contents of data; the len is the length of data
821
field; the data holds the real payload.
823
This list may be modified at a number of points during the bootup
824
process. Therefore, when modifying this list one should always make
825
sure to consider the case where the linked list already contains
826
entries.
828
The setup_data is a bit awkward to use for extremely large data objects,
829
both because the setup_data header has to be adjacent to the data object
830
and because it has a 32-bit length field. However, it is important that
831
intermediate stages of the boot process have a way to identify which
832
chunks of memory are occupied by kernel data.
834
Thus setup_indirect struct and SETUP_INDIRECT type were introduced in
835
protocol 2.15::
837
struct setup_indirect {
838
__u32 type;
839
__u32 reserved; /* Reserved, must be set to zero. */
840
__u64 len;
841
__u64 addr;
842
};
844
The type member is a SETUP_INDIRECT | SETUP_* type. However, it cannot be
845
SETUP_INDIRECT itself since making the setup_indirect a tree structure
846
could require a lot of stack space in something that needs to parse it
847
and stack space can be limited in boot contexts.
849
Let's give an example how to point to SETUP_E820_EXT data using setup_indirect.
850
In this case setup_data and setup_indirect will look like this::
852
struct setup_data {
853
.next = 0, /* or <addr_of_next_setup_data_struct> */
854
.type = SETUP_INDIRECT,
855
.len = sizeof(setup_indirect),
856
.data[sizeof(setup_indirect)] = (struct setup_indirect) {
857
.type = SETUP_INDIRECT | SETUP_E820_EXT,
858
.reserved = 0,
859
.len = <len_of_SETUP_E820_EXT_data>,
860
.addr = <addr_of_SETUP_E820_EXT_data>,
861
},
862
}
864
.. note::
865
SETUP_INDIRECT | SETUP_NONE objects cannot be properly distinguished
866
from SETUP_INDIRECT itself. So, this kind of objects cannot be provided
867
by the bootloaders.
869
============ ============
870
Field name: pref_address
871
Type: read (reloc)
872
Offset/size: 0x258/8
873
Protocol: 2.10+
874
============ ============
876
This field, if nonzero, represents a preferred load address for the
877
kernel. A relocating bootloader should attempt to load at this
878
address if possible.
880
A non-relocatable kernel will unconditionally move itself and to run
881
at this address. A relocatable kernel will move itself to this address if it
882
loaded below this address.
884
============ =======
885
Field name: init_size
886
Type: read
887
Offset/size: 0x260/4
888
============ =======
890
This field indicates the amount of linear contiguous memory starting
891
at the kernel runtime start address that the kernel needs before it
892
is capable of examining its memory map. This is not the same thing
893
as the total amount of memory the kernel needs to boot, but it can
894
be used by a relocating boot loader to help select a safe load
895
address for the kernel.
897
The kernel runtime start address is determined by the following algorithm::
899
if (relocatable_kernel) {
900
if (load_address < pref_address)
901
load_address = pref_address;
902
runtime_start = align_up(load_address, kernel_alignment);
903
} else {
904
runtime_start = pref_address;
905
}
907
Hence the necessary memory window location and size can be estimated by
908
a boot loader as::
910
memory_window_start = runtime_start;
911
memory_window_size = init_size;
913
============ ===============
914
Field name: handover_offset
915
Type: read
916
Offset/size: 0x264/4
917
============ ===============
919
This field is the offset from the beginning of the kernel image to
920
the EFI handover protocol entry point. Boot loaders using the EFI
921
handover protocol to boot the kernel should jump to this offset.
923
See EFI HANDOVER PROTOCOL below for more details.
925
============ ==================
926
Field name: kernel_info_offset
927
Type: read
928
Offset/size: 0x268/4
929
Protocol: 2.15+
930
============ ==================
932
This field is the offset from the beginning of the kernel image to the
933
kernel_info. The kernel_info structure is embedded in the Linux image
934
in the uncompressed protected mode region.
937
The kernel_info
938
===============
940
The relationships between the headers are analogous to the various data
941
sections::
943
setup_header = .data
944
boot_params/setup_data = .bss
946
What is missing from the above list? That's right::
948
kernel_info = .rodata
950
We have been (ab)using .data for things that could go into .rodata or .bss for
951
a long time, for lack of alternatives and -- especially early on -- inertia.
952
Also, the BIOS stub is responsible for creating boot_params, so it isn't
953
available to a BIOS-based loader (setup_data is, though).
955
setup_header is permanently limited to 144 bytes due to the reach of the
956
2-byte jump field, which doubles as a length field for the structure, combined
957
with the size of the "hole" in struct boot_params that a protected-mode loader
958
or the BIOS stub has to copy it into. It is currently 119 bytes long, which
959
leaves us with 25 very precious bytes. This isn't something that can be fixed
960
without revising the boot protocol entirely, breaking backwards compatibility.
962
boot_params proper is limited to 4096 bytes, but can be arbitrarily extended
963
by adding setup_data entries. It cannot be used to communicate properties of
964
the kernel image, because it is .bss and has no image-provided content.
966
kernel_info solves this by providing an extensible place for information about
967
the kernel image. It is readonly, because the kernel cannot rely on a
968
bootloader copying its contents anywhere, but that is OK; if it becomes
969
necessary it can still contain data items that an enabled bootloader would be
970
expected to copy into a setup_data chunk.
972
All kernel_info data should be part of this structure. Fixed size data have to
973
be put before kernel_info_var_len_data label. Variable size data have to be put
974
after kernel_info_var_len_data label. Each chunk of variable size data has to
975
be prefixed with header/magic and its size, e.g.::
977
kernel_info:
978
.ascii "LToP" /* Header, Linux top (structure). */
979
.long kernel_info_var_len_data - kernel_info
980
.long kernel_info_end - kernel_info
981
.long 0x01234567 /* Some fixed size data for the bootloaders. */
982
kernel_info_var_len_data:
983
example_struct: /* Some variable size data for the bootloaders. */
984
.ascii "0123" /* Header/Magic. */
985
.long example_struct_end - example_struct
986
.ascii "Struct"
987
.long 0x89012345
988
example_struct_end:
989
example_strings: /* Some variable size data for the bootloaders. */
990
.ascii "ABCD" /* Header/Magic. */
991
.long example_strings_end - example_strings
992
.asciz "String_0"
993
.asciz "String_1"
994
example_strings_end:
995
kernel_info_end:
997
This way the kernel_info is self-contained blob.
999
.. note::
1000
Each variable size data header/magic can be any 4-character string,
1001
without \0 at the end of the string, which does not collide with
1002
existing variable length data headers/magics.
1005
Details of the kernel_info Fields
1006
=================================
1008
============ ========
1009
Field name: header
1010
Offset/size: 0x0000/4
1011
============ ========
1013
Contains the magic number "LToP" (0x506f544c).
1015
============ ========
1016
Field name: size
1017
Offset/size: 0x0004/4
1018
============ ========
1020
This field contains the size of the kernel_info including kernel_info.header.
1021
It does not count kernel_info.kernel_info_var_len_data size. This field should be
1022
used by the bootloaders to detect supported fixed size fields in the kernel_info
1023
and beginning of kernel_info.kernel_info_var_len_data.
1025
============ ========
1026
Field name: size_total
1027
Offset/size: 0x0008/4
1028
============ ========
1030
This field contains the size of the kernel_info including kernel_info.header
1031
and kernel_info.kernel_info_var_len_data.
1033
============ ==============
1034
Field name: setup_type_max
1035
Offset/size: 0x000c/4
1036
============ ==============
1038
This field contains maximal allowed type for setup_data and setup_indirect structs.
1041
The Kernel Command Line
1042
=======================
1044
The kernel command line has become an important way for the boot
1045
loader to communicate with the kernel. Some of its options are also
1046
relevant to the boot loader itself, see "special command line options"
1047
below.
1049
The kernel command line is a null-terminated string. The maximum
1050
length can be retrieved from the field cmdline_size. Before protocol
1051
version 2.06, the maximum was 255 characters. A string that is too
1052
long will be automatically truncated by the kernel.
1054
If the boot protocol version is 2.02 or later, the address of the
1055
kernel command line is given by the header field cmd_line_ptr (see
1056
above.) This address can be anywhere between the end of the setup
1057
heap and 0xA0000.
1059
If the protocol version is *not* 2.02 or higher, the kernel
1060
command line is entered using the following protocol:
1062
- At offset 0x0020 (word), "cmd_line_magic", enter the magic
1063
number 0xA33F.
1065
- At offset 0x0022 (word), "cmd_line_offset", enter the offset
1066
of the kernel command line (relative to the start of the
1067
real-mode kernel).
1069
- The kernel command line *must* be within the memory region
1070
covered by setup_move_size, so you may need to adjust this
1071
field.
1074
Memory Layout of The Real-Mode Code
1075
===================================
1077
The real-mode code requires a stack/heap to be set up, as well as
1078
memory allocated for the kernel command line. This needs to be done
1079
in the real-mode accessible memory in bottom megabyte.
1081
It should be noted that modern machines often have a sizable Extended
1082
BIOS Data Area (EBDA). As a result, it is advisable to use as little
1083
of the low megabyte as possible.
1085
Unfortunately, under the following circumstances the 0x90000 memory
1086
segment has to be used:
1088
- When loading a zImage kernel ((loadflags & 0x01) == 0).
1089
- When loading a 2.01 or earlier boot protocol kernel.
1091
.. note::
1092
For the 2.00 and 2.01 boot protocols, the real-mode code
1093
can be loaded at another address, but it is internally
1094
relocated to 0x90000. For the "old" protocol, the
1095
real-mode code must be loaded at 0x90000.
1097
When loading at 0x90000, avoid using memory above 0x9a000.
1099
For boot protocol 2.02 or higher, the command line does not have to be
1100
located in the same 64K segment as the real-mode setup code; it is
1101
thus permitted to give the stack/heap the full 64K segment and locate
1102
the command line above it.
1104
The kernel command line should not be located below the real-mode
1105
code, nor should it be located in high memory.
1108
Sample Boot Configuration
1109
=========================
1111
As a sample configuration, assume the following layout of the real
1112
mode segment.
1114
When loading below 0x90000, use the entire segment:
1116
============= ===================
1117
0x0000-0x7fff Real mode kernel
1118
0x8000-0xdfff Stack and heap
1119
0xe000-0xffff Kernel command line
1120
============= ===================
1122
When loading at 0x90000 OR the protocol version is 2.01 or earlier:
1124
============= ===================
1125
0x0000-0x7fff Real mode kernel
1126
0x8000-0x97ff Stack and heap
1127
0x9800-0x9fff Kernel command line
1128
============= ===================
1130
Such a boot loader should enter the following fields in the header::
1132
unsigned long base_ptr; /* base address for real-mode segment */
1134
if (setup_sects == 0)
1135
setup_sects = 4;
1137
if (protocol >= 0x0200) {
1138
type_of_loader = <type code>;
1139
if (loading_initrd) {
1140
ramdisk_image = <initrd_address>;
1141
ramdisk_size = <initrd_size>;
1142
}
1144
if (protocol >= 0x0202 && loadflags & 0x01)
1145
heap_end = 0xe000;
1146
else
1147
heap_end = 0x9800;
1149
if (protocol >= 0x0201) {
1150
heap_end_ptr = heap_end - 0x200;
1151
loadflags |= 0x80; /* CAN_USE_HEAP */
1152
}
1154
if (protocol >= 0x0202) {
1155
cmd_line_ptr = base_ptr + heap_end;
1156
strcpy(cmd_line_ptr, cmdline);
1157
} else {
1158
cmd_line_magic = 0xA33F;
1159
cmd_line_offset = heap_end;
1160
setup_move_size = heap_end + strlen(cmdline) + 1;
1161
strcpy(base_ptr + cmd_line_offset, cmdline);
1162
}
1163
} else {
1164
/* Very old kernel */
1166
heap_end = 0x9800;
1168
cmd_line_magic = 0xA33F;
1169
cmd_line_offset = heap_end;
1171
/* A very old kernel MUST have its real-mode code loaded at 0x90000 */
1172
if (base_ptr != 0x90000) {
1173
/* Copy the real-mode kernel */
1174
memcpy(0x90000, base_ptr, (setup_sects + 1) * 512);
1175
base_ptr = 0x90000; /* Relocated */
1176
}
1178
strcpy(0x90000 + cmd_line_offset, cmdline);
1180
/* It is recommended to clear memory up to the 32K mark */
1181
memset(0x90000 + (setup_sects + 1) * 512, 0, (64 - (setup_sects + 1)) * 512);
1182
}
1185
Loading The Rest of The Kernel
1186
==============================
1188
The 32-bit (non-real-mode) kernel starts at offset (setup_sects + 1) * 512
1189
in the kernel file (again, if setup_sects == 0 the real value is 4.)
1190
It should be loaded at address 0x10000 for Image/zImage kernels and
1191
0x100000 for bzImage kernels.
1193
The kernel is a bzImage kernel if the protocol >= 2.00 and the 0x01
1194
bit (LOAD_HIGH) in the loadflags field is set::
1196
is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01);
1197
load_address = is_bzImage ? 0x100000 : 0x10000;
1199
.. note::
1200
Image/zImage kernels can be up to 512K in size, and thus use the entire
1201
0x10000-0x90000 range of memory. This means it is pretty much a
1202
requirement for these kernels to load the real-mode part at 0x90000.
1203
bzImage kernels allow much more flexibility.
1205
Special Command Line Options
1206
============================
1208
If the command line provided by the boot loader is entered by the
1209
user, the user may expect the following command line options to work.
1210
They should normally not be deleted from the kernel command line even
1211
though not all of them are actually meaningful to the kernel. Boot
1212
loader authors who need additional command line options for the boot
1213
loader itself should get them registered in
1214
Documentation/admin-guide/kernel-parameters.rst to make sure they will not
1215
conflict with actual kernel options now or in the future.
1217
vga=<mode>
1218
<mode> here is either an integer (in C notation, either
1219
decimal, octal, or hexadecimal) or one of the strings
1220
"normal" (meaning 0xFFFF), "ext" (meaning 0xFFFE) or "ask"
1221
(meaning 0xFFFD). This value should be entered into the
1222
vid_mode field, as it is used by the kernel before the command
1223
line is parsed.
1225
mem=<size>
1226
<size> is an integer in C notation optionally followed by
1227
(case insensitive) K, M, G, T, P or E (meaning << 10, << 20,
1228
<< 30, << 40, << 50 or << 60). This specifies the end of
1229
memory to the kernel. This affects the possible placement of
1230
an initrd, since an initrd should be placed near end of
1231
memory. Note that this is an option to *both* the kernel and
1232
the bootloader!
1234
initrd=<file>
1235
An initrd should be loaded. The meaning of <file> is
1236
obviously bootloader-dependent, and some boot loaders
1237
(e.g. LILO) do not have such a command.
1239
In addition, some boot loaders add the following options to the
1240
user-specified command line:
1242
BOOT_IMAGE=<file>
1243
The boot image which was loaded. Again, the meaning of <file>
1244
is obviously bootloader-dependent.
1246
auto
1247
The kernel was booted without explicit user intervention.
1249
If these options are added by the boot loader, it is highly
1250
recommended that they are located *first*, before the user-specified
1251
or configuration-specified command line. Otherwise, "init=/bin/sh"
1252
gets confused by the "auto" option.
1255
Running the Kernel
1256
==================
1258
The kernel is started by jumping to the kernel entry point, which is
1259
located at *segment* offset 0x20 from the start of the real mode
1260
kernel. This means that if you loaded your real-mode kernel code at
1261
0x90000, the kernel entry point is 9020:0000.
1263
At entry, ds = es = ss should point to the start of the real-mode
1264
kernel code (0x9000 if the code is loaded at 0x90000), sp should be
1265
set up properly, normally pointing to the top of the heap, and
1266
interrupts should be disabled. Furthermore, to guard against bugs in
1267
the kernel, it is recommended that the boot loader sets fs = gs = ds =
1268
es = ss.
1270
In our example from above, we would do::
1272
/*
1273
* Note: in the case of the "old" kernel protocol, base_ptr must
1274
* be == 0x90000 at this point; see the previous sample code.
1275
*/
1276
seg = base_ptr >> 4;
1278
cli(); /* Enter with interrupts disabled! */
1280
/* Set up the real-mode kernel stack */
1281
_SS = seg;
1282
_SP = heap_end;
1284
_DS = _ES = _FS = _GS = seg;
1285
jmp_far(seg + 0x20, 0); /* Run the kernel */
1287
If your boot sector accesses a floppy drive, it is recommended to
1288
switch off the floppy motor before running the kernel, since the
1289
kernel boot leaves interrupts off and thus the motor will not be
1290
switched off, especially if the loaded kernel has the floppy driver as
1291
a demand-loaded module!
1294
Advanced Boot Loader Hooks
1295
==========================
1297
If the boot loader runs in a particularly hostile environment (such as
1298
LOADLIN, which runs under DOS) it may be impossible to follow the
1299
standard memory location requirements. Such a boot loader may use the
1300
following hooks that, if set, are invoked by the kernel at the
1301
appropriate time. The use of these hooks should probably be
1302
considered an absolutely last resort!
1304
IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and
1305
%edi across invocation.
1307
realmode_swtch:
1308
A 16-bit real mode far subroutine invoked immediately before
1309
entering protected mode. The default routine disables NMI, so
1310
your routine should probably do so, too.
1312
code32_start:
1313
A 32-bit flat-mode routine *jumped* to immediately after the
1314
transition to protected mode, but before the kernel is
1315
uncompressed. No segments, except CS, are guaranteed to be
1316
set up (current kernels do, but older ones do not); you should
1317
set them up to BOOT_DS (0x18) yourself.
1319
After completing your hook, you should jump to the address
1320
that was in this field before your boot loader overwrote it
1321
(relocated, if appropriate.)
1324
32-bit Boot Protocol
1325
====================
1327
For machine with some new BIOS other than legacy BIOS, such as EFI,
1328
LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel
1329
based on legacy BIOS can not be used, so a 32-bit boot protocol needs
1330
to be defined.
1332
In 32-bit boot protocol, the first step in loading a Linux kernel
1333
should be to setup the boot parameters (struct boot_params,
1334
traditionally known as "zero page"). The memory for struct boot_params
1335
should be allocated and initialized to all zero. Then the setup header
1336
from offset 0x01f1 of kernel image on should be loaded into struct
1337
boot_params and examined. The end of setup header can be calculated as
1338
follow::
1340
0x0202 + byte value at offset 0x0201
1342
In addition to read/modify/write the setup header of the struct
1343
boot_params as that of 16-bit boot protocol, the boot loader should
1344
also fill the additional fields of the struct boot_params as
1345
described in chapter Documentation/arch/x86/zero-page.rst.
1347
After setting up the struct boot_params, the boot loader can load the
1348
32/64-bit kernel in the same way as that of 16-bit boot protocol.
1350
In 32-bit boot protocol, the kernel is started by jumping to the
1351
32-bit kernel entry point, which is the start address of loaded
1352
32/64-bit kernel.
1354
At entry, the CPU must be in 32-bit protected mode with paging
1355
disabled; a GDT must be loaded with the descriptors for selectors
1356
__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
1357
segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
1358
must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
1359
must be __BOOT_DS; interrupt must be disabled; %esi must hold the base
1360
address of the struct boot_params; %ebp, %edi and %ebx must be zero.
1362
64-bit Boot Protocol
1363
====================
1365
For machine with 64bit cpus and 64bit kernel, we could use 64bit bootloader
1366
and we need a 64-bit boot protocol.
1368
In 64-bit boot protocol, the first step in loading a Linux kernel
1369
should be to setup the boot parameters (struct boot_params,
1370
traditionally known as "zero page"). The memory for struct boot_params
1371
could be allocated anywhere (even above 4G) and initialized to all zero.
1372
Then, the setup header at offset 0x01f1 of kernel image on should be
1373
loaded into struct boot_params and examined. The end of setup header
1374
can be calculated as follows::
1376
0x0202 + byte value at offset 0x0201
1378
In addition to read/modify/write the setup header of the struct
1379
boot_params as that of 16-bit boot protocol, the boot loader should
1380
also fill the additional fields of the struct boot_params as described
1381
in chapter Documentation/arch/x86/zero-page.rst.
1383
After setting up the struct boot_params, the boot loader can load
1384
64-bit kernel in the same way as that of 16-bit boot protocol, but
1385
kernel could be loaded above 4G.
1387
In 64-bit boot protocol, the kernel is started by jumping to the
1388
64-bit kernel entry point, which is the start address of loaded
1389
64-bit kernel plus 0x200.
1391
At entry, the CPU must be in 64-bit mode with paging enabled.
1392
The range with setup_header.init_size from start address of loaded
1393
kernel and zero page and command line buffer get ident mapping;
1394
a GDT must be loaded with the descriptors for selectors
1395
__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
1396
segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
1397
must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
1398
must be __BOOT_DS; interrupt must be disabled; %rsi must hold the base
1399
address of the struct boot_params.
1401
EFI Handover Protocol (deprecated)
1402
==================================
1404
This protocol allows boot loaders to defer initialisation to the EFI
1405
boot stub. The boot loader is required to load the kernel/initrd(s)
1406
from the boot media and jump to the EFI handover protocol entry point
1407
which is hdr->handover_offset bytes from the beginning of
1408
startup_{32,64}.
1410
The boot loader MUST respect the kernel's PE/COFF metadata when it comes
1411
to section alignment, the memory footprint of the executable image beyond
1412
the size of the file itself, and any other aspect of the PE/COFF header
1413
that may affect correct operation of the image as a PE/COFF binary in the
1414
execution context provided by the EFI firmware.
1416
The function prototype for the handover entry point looks like this::
1418
void efi_stub_entry(void *handle, efi_system_table_t *table, struct boot_params *bp);
1420
'handle' is the EFI image handle passed to the boot loader by the EFI
1421
firmware, 'table' is the EFI system table - these are the first two
1422
arguments of the "handoff state" as described in section 2.3 of the
1423
UEFI specification. 'bp' is the boot loader-allocated boot params.
1425
The boot loader *must* fill out the following fields in bp::
1427
- hdr.cmd_line_ptr
1428
- hdr.ramdisk_image (if applicable)
1429
- hdr.ramdisk_size (if applicable)
1431
All other fields should be zero.
1433
.. note::
1434
The EFI Handover Protocol is deprecated in favour of the ordinary PE/COFF
1435
entry point, combined with the LINUX_EFI_INITRD_MEDIA_GUID based initrd
1436
loading protocol (refer to [0] for an example of the bootloader side of
1437
this), which removes the need for any knowledge on the part of the EFI
1438
bootloader regarding the internal representation of boot_params or any
1439
requirements/limitations regarding the placement of the command line
1440
and ramdisk in memory, or the placement of the kernel image itself.
1442
[0] https://github.com/u-boot/u-boot/commit/ec80b4735a593961fe701cc3a5d717d4739b0fd0
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Linux/x86 boot protocol의 역사와 버전
1-90이 `GPL-2.0` 문서는 Linux/x86 boot protocol을 정의합니다. x86 kernel의 boot convention이 복잡한 이유는 kernel image 자체를 boot 가능하게 만들려 했던 초기 설계, PC의 복잡한 memory model, 역사적 호환성, 그리고 real-mode DOS가 주류에서 사라지며 달라진 PC 업계의 기대가 함께 누적되었기 때문입니다.
| protocol | 도입 kernel | 핵심 변경 |
|---|---|---|
| Old kernels | - | `zImage`/`Image`만 지원하며 아주 초기 kernel은 command line도 지원하지 않을 수 있습니다. |
| 2.00 | 1.3.73 | `bzImage`, `initrd`, boot loader와 kernel 사이의 정식 통신 방식을 추가했습니다. `setup.S`는 relocatable이 되었지만 전통적 setup area는 여전히 writable이라고 전제했습니다. |
| 2.01 | 1.3.76 | heap overrun warning을 추가했습니다. |
| 2.02 | 2.4.0-test3-pre3 | 새 command-line protocol과 더 낮은 conventional-memory ceiling을 도입했습니다. 전통적 setup area를 덮어쓰지 않아 SMM의 EBDA나 32-bit BIOS entry point를 쓰는 system에서도 안전해졌습니다. `zImage`는 deprecated지만 계속 지원합니다. |
| 2.03 | 2.4.18-pre1 | boot loader가 사용할 수 있는 최대 `initrd` address를 명시했습니다. |
| 2.04 | 2.6.14 | `syssize` field를 4 byte로 확장했습니다. |
| 2.05 | 2.6.20 | protected-mode kernel을 relocatable로 만들고 `relocatable_kernel`, `kernel_alignment` field를 도입했습니다. |
| 2.06 | 2.6.22 | boot command line size field를 추가했습니다. |
| 2.07 | 2.6.24 | paravirtualized boot protocol, `hardware_subarch`, `hardware_subarch_data`, `load_flags`의 `KEEP_SEGMENTS` flag를 도입했습니다. |
| 2.08 | 2.6.26 | `crc32` checksum과 ELF payload format을 추가하고 payload 위치를 찾는 `payload_offset`, `payload_length`를 도입했습니다. |
| 2.09 | 2.6.26 | 단일 연결 목록 `struct setup_data`를 가리키는 64-bit physical pointer field를 추가했습니다. |
| 2.10 | 2.6.31 | `kernel_alignment`보다 완화된 alignment protocol과 `init_size`, `pref_address`, 확장 boot-loader ID를 추가했습니다. |
| 2.11 | 3.6 | EFI handover protocol entry-point offset field를 추가했습니다. |
| 2.12 | 3.8 | `xloadflags`와 `struct boot_params` extension field를 추가해 64-bit에서 `bzImage`와 ramdisk를 4 GiB 위에 load할 수 있게 했습니다. |
| 2.13 | 3.14 | `xloadflags`의 32-bit와 64-bit flag를 함께 설정해 32-bit EFI에서 64-bit kernel을 boot할 수 있게 했습니다. |
| 2.14 | - | 잘못된 commit `ae7e1238e68f2a472a125673ab506d49158c1889` 때문에 소진된 번호입니다. 사용하지 말고 2.13과 같다고 간주해야 합니다. |
| 2.15 | 5.5 | `kernel_info`와 `kernel_info.setup_type_max`를 추가했습니다. |
protocol version은 setup header가 바뀔 때만 변경합니다. `boot_params`나 `kernel_info` 변경에는 version을 올릴 필요가 없습니다. 지원 feature 전달에는 가능하면 `xloadflags` 또는 `kernel_info`를 사용합니다. 원래 setup header의 공간은 극히 제한되어 있으므로 수정은 신중해야 하며, protocol 2.15부터 boot loader와 통신하는 주된 수단은 `kernel_info`입니다.
전통적 memory map과 modern bzImage 배치
91-170`Image` 또는 `zImage`를 위한 전통적 loader layout에서는 protected-mode kernel을 `0x010000`부터, legacy boot sector를 `0x090000`, real-mode setup을 `0x090200`, stack/heap과 command line을 그 위에 놓았습니다. `0x09A000` 이상은 BIOS EBDA용이므로 사용하지 않아야 합니다.
address range / boundarycontent제약 또는 용도
`0x0A0000` 이상BIOS reservedBIOS EBDA용, 사용 금지
`0x098000`-`0x09A000`command line, stack/heapkernel real-mode code가 사용
`0x090200`-`0x098000`kernel setupkernel real-mode code
`0x090000`-`0x090200`kernel boot sectorlegacy boot sector
`0x010000`-`0x090000`protected-mode kernelkernel image의 대부분
`0x001000`-`0x010000`boot loaderboot-sector entry point `0000:7C00`
`0x000800`-`0x001000`MBR/BIOS reserved사용 금지
`0x000600`-`0x000800`typically MBR일반적으로 MBR이 사용
`0x000000`-`0x000600`BIOS onlyBIOS 전용
원문의 세로 ASCII memory map을 높은 address에서 낮은 address 순으로 구조화했습니다.
`bzImage`에서는 protected-mode kernel을 high memory의 `0x100000`으로 옮기고, boot sector·setup·stack/heap을 포함한 real-mode block은 `0x10000`부터 low memory 끝 사이에서 재배치할 수 있게 했습니다. 다만 protocol 2.00과 2.01은 kernel 내부에서 여전히 `0x90000` 이상을 사용하며, 이 문제는 2.02에서 해결되었습니다.
boot loader가 건드리는 low-memory 최고점인 memory ceiling은 가능한 낮게 유지해야 합니다. 최신 BIOS는 low memory 상단에 큰 EBDA를 배치할 수 있으므로 `INT 12h` BIOS call로 사용 가능한 low memory를 확인해야 합니다. 값이 부족하면 보통 오류를 알리는 것 외에는 해결책이 없으므로 loader 자체도 low memory를 적게 써야 합니다.
`0x90000` segment에 data를 써야 하는 `zImage` 또는 old `bzImage`에서는 `0x9A000` 위를 사용하지 마십시오. 그 경계 위에서 망가지는 BIOS가 많습니다.
address range / boundarycontent제약 또는 용도
`0x100000` 이상protected-mode kernelhigh memory
`0x0A0000`-`0x100000`I/O memory hole사용 금지
`X+0x10000`-`0x0A0000`BIOS reserved / command lineBIOS용 공간을 최대한 남깁니다. command line은 `X+0x10000` 아래일 수도 있습니다.
`X+0x08000`-`X+0x10000`stack/heapkernel real-mode code가 사용
`X`-`X+0x08000`kernel setup + boot sectorreal-mode code와 legacy boot sector
`0x001000`-`X`boot loaderboot-sector entry point `0000:7C00`
`0x000800`-`0x001000`MBR/BIOS reserved사용 금지
`0x000600`-`0x000800`typically MBR일반적으로 MBR이 사용
`0x000000`-`0x000600`BIOS onlyBIOS 전용
`X`는 boot loader 설계가 허용하는 한 낮은 real-mode block 시작 address입니다.
real-mode kernel header 형식
171-254이 문서와 kernel boot sequence에서 sector는 underlying medium의 실제 sector size와 무관하게 항상 512 byte를 뜻합니다. kernel load의 첫 단계는 real-mode code, 즉 boot sector와 setup code를 load한 뒤 offset `0x01f1`의 header를 검사하는 것입니다. real-mode code는 최대 32 KiB이지만 loader는 처음 두 sector(1 KiB)만 읽고 setup sector 수를 확인할 수도 있습니다.
| offset/size | protocol | name | 의미 |
|---|---|---|---|
| `01F1/1` | `ALL` | `setup_sects` | setup size, 512-byte sector 단위 |
| `01F2/2` | `ALL` | `root_flags` | 설정되면 root를 read-only로 mount |
| `01F4/4` | `2.04+` | `syssize` | 32-bit code size, 16-byte paragraph 단위 |
| `01F8/2` | `ALL` | `ram_size` | 사용 금지, `bootsect.S` 내부 전용 |
| `01FA/2` | `ALL` | `vid_mode` | video mode control |
| `01FC/2` | `ALL` | `root_dev` | default root device number |
| `01FE/2` | `ALL` | `boot_flag` | `0xAA55` magic |
| `0200/2` | `2.00+` | `jump` | jump instruction |
| `0202/4` | `2.00+` | `header` | `HdrS` magic signature |
| `0206/2` | `2.00+` | `version` | 지원 boot protocol version |
| `0208/4` | `2.00+` | `realmode_swtch` | boot-loader hook |
| `020C/2` | `2.00+` | `start_sys_seg` | obsolete load-low segment `0x1000` |
| `020E/2` | `2.00+` | `kernel_version` | kernel version string pointer |
| `0210/1` | `2.00+` | `type_of_loader` | boot-loader identifier |
| `0211/1` | `2.00+` | `loadflags` | boot-protocol option flags |
| `0212/2` | `2.00+` | `setup_move_size` | hook 사용 시 high-memory move size |
| `0214/4` | `2.00+` | `code32_start` | boot-loader hook / protected-mode entry |
| `0218/4` | `2.00+` | `ramdisk_image` | loader가 쓰는 initrd load address |
| `021C/4` | `2.00+` | `ramdisk_size` | loader가 쓰는 initrd size |
| `0220/4` | `2.00+` | `bootsect_kludge` | 사용 금지, `bootsect.S` 내부 전용 |
| `0224/2` | `2.01+` | `heap_end_ptr` | setup 뒤 free-memory 경계 |
| `0226/1` | `2.02+` | `ext_loader_ver` | 확장 boot-loader version |
| `0227/1` | `2.02+` | `ext_loader_type` | 확장 boot-loader ID |
| `0228/4` | `2.02+` | `cmd_line_ptr` | kernel command line의 32-bit pointer |
| `022C/4` | `2.03+` | `initrd_addr_max` | 허용되는 최고 initrd address |
| `0230/4` | `2.05+` | `kernel_alignment` | kernel physical-address alignment |
| `0234/1` | `2.05+` | `relocatable_kernel` | kernel relocation 가능 여부 |
| `0235/1` | `2.10+` | `min_alignment` | 최소 alignment의 power-of-two 지수 |
| `0236/2` | `2.12+` | `xloadflags` | 확장 boot-protocol option flags |
| `0238/4` | `2.06+` | `cmdline_size` | kernel command line 최대 size |
| `023C/4` | `2.07+` | `hardware_subarch` | hardware subarchitecture |
| `0240/8` | `2.07+` | `hardware_subarch_data` | subarchitecture-specific data |
| `0248/4` | `2.08+` | `payload_offset` | kernel payload offset |
| `024C/4` | `2.08+` | `payload_length` | kernel payload length |
| `0250/8` | `2.09+` | `setup_data` | `struct setup_data` list의 64-bit physical pointer |
| `0258/8` | `2.10+` | `pref_address` | preferred load address |
| `0260/4` | `2.10+` | `init_size` | 초기화 중 필요한 linear memory |
| `0264/4` | `2.11+` | `handover_offset` | handover entry-point offset |
| `0268/4` | `2.15+` | `kernel_info_offset` | `kernel_info` offset |
호환성을 위해 `setup_sects == 0`이면 실제 값은 4입니다. 2.04 이전에는 `syssize` 상위 2 byte를 쓸 수 없어 `bzImage` 전체 size를 계산할 수 없습니다. `ext_loader_ver`와 `ext_loader_type`은 protocol 2.02-2.09에서 무시되지만 설정해도 안전합니다.
offset `0x202`에서 `HdrS`(`0x53726448`)를 찾지 못하면 old protocol입니다. 이 경우 image type은 `zImage`, initrd는 미지원, real-mode kernel load address는 `0x90000`이라고 가정합니다. magic이 있으면 `version`이 protocol version을 담으며, 예를 들어 2.01은 `0x0201`입니다. header를 쓸 때는 사용 중인 protocol이 지원하는 field만 설정해야 합니다.
header field의 read/write 규칙
255-269각 field는 kernel이 boot loader에 제공하는 `read`, boot loader가 채우는 `write`, 또는 loader가 읽고 수정하는 `modify`로 분류됩니다. 범용 boot loader는 `(obligatory)` field를 모두 써야 합니다.
kernel을 비표준 address에 load하려는 loader는 `(reloc)` field도 채워야 하며, 그렇지 않은 loader는 이를 무시할 수 있습니다. 모든 field의 byte order는 x86답게 little endian입니다.
legacy header field와 kernel version
270-411| field | type | offset/size | protocol |
|---|---|---|---|
| `setup_sects` | read | `0x1f1/1` | `ALL` |
| `root_flags` | modify, optional | `0x1f2/2` | `ALL` |
| `syssize` | read | `0x1f4/4`(2.04+), `0x1f4/2`(ALL) | `2.04+` |
| `ram_size` | kernel internal | `0x1f8/2` | `ALL` |
| `vid_mode` | modify, obligatory | `0x1fa/2` | `ALL` |
| `root_dev` | modify, optional | `0x1fc/2` | `ALL` |
| `boot_flag` | read | `0x1fe/2` | `ALL` |
| `jump` | read | `0x200/2` | `2.00+` |
| `header` | read | `0x202/4` | `2.00+` |
| `version` | read | `0x206/2` | `2.00+` |
| `realmode_swtch` | modify, optional | `0x208/4` | `2.00+` |
| `start_sys_seg` | read | `0x20c/2` | `2.00+` |
| `kernel_version` | read | `0x20e/2` | `2.00+` |
`setup_sects`는 setup code의 512-byte sector 수입니다. 0이면 4로 해석하며 real-mode code는 1-sector boot sector와 setup code로 구성됩니다. `root_flags != 0`이면 root가 기본적으로 read-only지만 이 field는 deprecated이므로 command line의 `ro` 또는 `rw`를 사용합니다.
`syssize`는 protected-mode code size를 16-byte paragraph 단위로 나타냅니다. 2.04보다 오래된 protocol에서는 2 byte뿐이므로 `LOAD_HIGH`가 설정된 kernel size 계산에 신뢰할 수 없습니다. `ram_size`는 obsolete입니다. obligatory `vid_mode`는 Special Command Line Options 절을 따릅니다.
`root_dev`는 default root-device number지만 deprecated이며 `root=`를 사용합니다. `boot_flag`는 old Linux kernel에서 magic에 가장 가까운 `0xAA55`입니다. `jump`는 `0xEB`와 byte `0x202` 기준 signed offset으로 이루어진 x86 jump instruction이며 header size 계산에 사용할 수 있습니다.
`header`는 `HdrS`(`0x53726448`)이고 `version`은 `(major << 8) + minor` 형식입니다. 따라서 2.04는 `0x0204`, 가상의 10.17은 `0x0a11`입니다. `realmode_swtch`는 Advanced Boot Loader Hooks의 hook이며, `start_sys_seg`는 obsolete load-low segment `0x1000`입니다.
`kernel_version`이 0이 아니면 `0x200`을 뺀 값이 NUL-terminated human-readable version string pointer입니다. user에게 version을 표시할 수 있으며 값은 `(0x200 * setup_sects)`보다 작아야 합니다. 예를 들어 `0x1c00`이면 file offset `0x1e00`에 string이 있고 `setup_sects` 최소값은 15입니다.
0x1c00 < 15 * 0x200 (= 0x1e00) but
0x1c00 >= 14 * 0x200 (= 0x1c00)
0x1c00 >> 9 = 14, So the minimum value for setup_secs is 15.type_of_loader와 boot-loader ID
412-462obligatory `type_of_loader`는 offset `0x210/1`, protocol 2.00+ field입니다. 할당된 ID가 있으면 `0xTV`를 쓰며 `T`는 loader identifier, `V`는 version입니다. 할당 ID가 없으면 `0xFF`를 씁니다.
`T > 0xD`이면 `type_of_loader`에는 `T=0xE`를 쓰고 실제 확장 ID에서 `0x10`을 뺀 값을 `ext_loader_type`에 씁니다. `ext_loader_ver`를 사용하면 version을 4 bit보다 넓게 표현할 수 있습니다. 예를 들어 `T=0x15`, `V=0x234`는 다음과 같습니다.
type_of_loader <- 0xE4
ext_loader_type <- 0x05
ext_loader_ver <- 0x23| hex ID | boot loader |
|---|---|
| `0` | LILO; `0x00`은 pre-2.00 loader용으로 reserved |
| `1` | Loadlin |
| `2` | bootsect-loader; `0x20` 외의 값은 reserved |
| `3` | Syslinux |
| `4` | Etherboot/gPXE/iPXE |
| `5` | ELILO |
| `7` | GRUB |
| `8` | U-Boot |
| `9` | Xen |
| `A` | Gujin |
| `B` | Qemu |
| `C` | Arcturus Networks uCbootloader |
| `D` | kexec-tools |
| `E` | Extended, `ext_loader_type` 참조 |
| `F` | Special, `0xFF`는 undefined |
| `10` | Reserved |
| `11` | Minimal Linux Bootloader, `http://sebastian-plotz.blogspot.de` |
| `12` | OVMF UEFI virtualization stack |
| `13` | barebox |
새 boot-loader ID가 필요하면 `<hpa@zytor.com>`에 문의합니다.
loadflags bitmask
463-506obligatory modify field `loadflags`는 offset `0x211/1`, protocol 2.00+의 bitmask입니다.
| bit | name / access | 의미 |
|---|---|---|
| 0 | `LOADED_HIGH` / read | 0이면 protected-mode code가 `0x10000`, 1이면 `0x100000`에 load됩니다. |
| 1 | `KASLR_FLAG` / kernel internal | compressed kernel이 kernel proper에 KASLR 상태를 전달합니다. 1은 enabled, 0은 disabled입니다. |
| 5 | `QUIET_FLAG` / write | 0이면 early message를 출력하고, 1이면 display hardware 직접 접근이 필요한 decompressor 및 early-kernel message를 억제합니다. |
| 6 | `KEEP_SEGMENTS` / obsolete | protocol 2.07+에서 정의됐지만 현재 obsolete입니다. |
| 7 | `CAN_USE_HEAP` / write | 1이면 `heap_end_ptr`가 유효합니다. clear이면 setup code 기능 일부가 비활성화됩니다. |
setup 이동, protected-mode entry와 initrd
507-572| field | type | offset/size | protocol |
|---|---|---|---|
| `setup_move_size` | modify, obligatory | `0x212/2` | `2.00-2.01` |
| `code32_start` | modify, optional, reloc | `0x214/4` | `2.00+` |
| `ramdisk_image` | write, obligatory | `0x218/4` | `2.00+` |
| `ramdisk_size` | write, obligatory | `0x21c/4` | `2.00+` |
| `bootsect_kludge` | kernel internal | `0x220/4` | `2.00+` |
protocol 2.00 또는 2.01에서 real-mode kernel을 `0x90000`이 아닌 곳에 load하면 나중에 그 address로 이동합니다. real-mode kernel뿐 아니라 command line 같은 추가 data도 함께 옮기려면 `setup_move_size`를 채웁니다. 단위는 boot sector 시작부터의 byte입니다. protocol 2.02+이거나 real-mode code가 이미 `0x90000`이면 무시할 수 있습니다.
`code32_start`는 protected mode에서 jump할 address이며 기본값은 kernel load address입니다. loader는 이를 이용해 올바른 load address를 판단합니다. Advanced Boot Loader Hooks의 hook을 설치할 때, 또는 hook 없이 relocatable kernel을 비표준 address에 load할 때 실제 load address를 가리키도록 수정합니다.
`ramdisk_image`는 initial ramdisk/ramfs의 32-bit linear address이고 `ramdisk_size`는 그 size입니다. initrd/initramfs가 없으면 둘 다 0으로 둡니다. `bootsect_kludge`는 obsolete입니다.
heap_end_ptr와 확장 loader 식별자
573-615| field | type | offset/size | protocol |
|---|---|---|---|
| `heap_end_ptr` | write, obligatory | `0x224/2` | `2.01+` |
| `ext_loader_ver` | write, optional | `0x226/1` | `2.02+` |
| `ext_loader_type` | 조건부 obligatory | `0x227/1` | `2.02+` |
`heap_end_ptr`에는 real-mode code 시작 기준 setup stack/heap 끝 offset에서 `0x0200`을 뺀 값을 씁니다.
`ext_loader_ver`는 `type_of_loader` version nibble의 확장입니다. 전체 version은 `(type_of_loader & 0x0f) + (ext_loader_ver << 4)`이며 해석은 loader-specific입니다. 쓰지 않으면 0입니다.
`(type_of_loader & 0xf0) == 0xe0`이면 `ext_loader_type`이 obligatory이며 실제 type은 `ext_loader_type + 0x10`입니다. type nibble이 `0xE`가 아니면 이 field는 무시됩니다. 2.6.31 이전 kernel은 두 확장 field를 인식하지 않았지만 protocol 2.02+에 써도 안전합니다.
cmd_line_ptr와 initrd_addr_max
616-647| field | type | offset/size | protocol |
|---|---|---|---|
| `cmd_line_ptr` | write, obligatory | `0x228/4` | `2.02+` |
| `initrd_addr_max` | read | `0x22c/4` | `2.03+` |
`cmd_line_ptr`에는 kernel command line의 linear address를 씁니다. command line은 setup heap 끝과 `0xA0000` 사이 어디든 둘 수 있고 real-mode code와 같은 64 KiB segment일 필요가 없습니다.
command line을 지원하지 않는 loader도 이 field를 채워 empty string, 더 바람직하게는 `auto`를 가리켜야 합니다. 0이면 kernel은 loader가 2.02+ protocol을 지원하지 않는다고 판단합니다.
`initrd_addr_max`는 initial ramdisk/ramfs가 점유할 수 있는 최고 byte address입니다. 2.02 이하에는 이 field가 없고 기본 maximum은 `0x37FFFFFF`입니다. 예를 들어 ramdisk가 정확히 131072 byte이고 maximum이 `0x37FFFFFF`이면 시작 address로 `0x37FE0000`을 쓸 수 있습니다.
kernel_alignment, relocation과 min_alignment
648-694| field | type | offset/size | protocol |
|---|---|---|---|
| `kernel_alignment` | read/modify, reloc | `0x230/4` | `2.05+` read, `2.10+` modify |
| `relocatable_kernel` | read, reloc | `0x234/1` | `2.05+` |
| `min_alignment` | read, reloc | `0x235/1` | `2.10+` |
`relocatable_kernel`이 true일 때 `kernel_alignment`는 kernel이 요구하는 alignment unit입니다. 호환되지 않는 alignment에 load하면 kernel initialization 중 재정렬됩니다. protocol 2.10부터 이 값은 최적 performance를 위한 preferred alignment이며 loader는 더 작은 alignment를 허용하도록 수정할 수 있습니다.
`relocatable_kernel != 0`이면 protected-mode 부분을 `kernel_alignment`를 만족하는 어떤 address에도 load할 수 있습니다. load 뒤에는 `code32_start`가 load된 code 또는 boot-loader hook을 가리키게 해야 합니다.
`min_alignment != 0`이면 preferred가 아닌 boot 가능한 최소 alignment를 power-of-two 지수로 나타냅니다. 이를 사용하는 loader는 원하는 unit으로 `kernel_alignment`를 갱신하며 일반적인 계산은 다음과 같습니다.
kernel_alignment = 1 << min_alignment;지나치게 misaligned된 kernel에는 상당한 performance cost가 생길 수 있습니다. 따라서 loader는 보통 원래 `kernel_alignment`부터 최소값까지 power-of-two alignment를 차례로 시도합니다.
xloadflags capability bit
695-726read-only `xloadflags`는 offset `0x236/2`, protocol 2.12+의 bitmask입니다.
| bit | name | 의미 |
|---|---|---|
| 0 | `XLF_KERNEL_64` | kernel에 offset `0x200`의 legacy 64-bit entry point가 있습니다. |
| 1 | `XLF_CAN_BE_LOADED_ABOVE_4G` | kernel, `boot_params`, command line, ramdisk를 4 GiB 위에 둘 수 있습니다. |
| 2 | `XLF_EFI_HANDOVER_32` | `handover_offset`의 32-bit EFI handoff entry point를 지원합니다. |
| 3 | `XLF_EFI_HANDOVER_64` | `handover_offset + 0x200`의 64-bit EFI handoff entry point를 지원합니다. |
| 4 | `XLF_EFI_KEXEC` | EFI runtime support를 포함한 kexec EFI boot를 지원합니다. |
command-line 한도와 hardware subarchitecture
727-771| field | type | offset/size | protocol |
|---|---|---|---|
| `cmdline_size` | read | `0x238/4` | `2.06+` |
| `hardware_subarch` | write, optional, default x86/PC | `0x23c/4` | `2.07+` |
| `hardware_subarch_data` | write, subarch-dependent | `0x240/8` | `2.07+` |
`cmdline_size`는 terminating zero를 제외한 command line 최대 size이므로 최대 `cmdline_size` characters를 담습니다. protocol 2.05 이하의 maximum은 255였습니다.
paravirtualized environment에서는 interrupt, page table, process-control register 같은 low-level architecture를 다르게 다뤄야 하므로 `hardware_subarch`로 환경을 kernel에 알립니다.
| value | environment |
|---|---|
| `0x00000000` | default x86/PC |
| `0x00000001` | lguest |
| `0x00000002` | Xen |
| `0x00000003` | Intel MID (Moorestown, CloverTrail, Merrifield, Moorefield) |
| `0x00000004` | CE4100 TV Platform |
`hardware_subarch_data`는 해당 subarchitecture 전용 data pointer입니다. default x86/PC에서는 현재 사용하지 않으므로 수정하지 않습니다.
payload_offset과 압축 format
772-798| field | type | offset/size | protocol |
|---|---|---|---|
| `payload_offset` | read | `0x248/4` | `2.08+` |
| `payload_length` | read | `0x24c/4` | `2.08+` |
`payload_offset != 0`이면 protected-mode code 시작부터 payload까지의 offset입니다. payload는 compressed일 수 있으며 compressed/uncompressed format 모두 표준 magic number로 판별합니다.
| format | magic |
|---|---|
| gzip | `1F 8B` 또는 `1F 9E` |
| bzip2 | `42 5A` |
| LZMA | `5D 00` |
| XZ | `FD 37` |
| LZ4 | `02 21` |
| ZSTD | `28 B5` |
| uncompressed ELF | `7F 45 4C 46` |
`payload_length`는 payload의 byte length입니다.
setup_data와 setup_indirect 확장
799-868special write field `setup_data`는 offset `0x250/8`, protocol 2.09+이며 NUL-terminated singly linked `struct setup_data` list를 가리키는 64-bit physical pointer입니다. 확장 가능한 boot-parameter 전달 수단으로 쓰입니다.
struct setup_data {
__u64 next;
__u32 type;
__u32 len;
__u8 data[];
}`next`는 다음 node의 64-bit physical pointer이고 마지막 node에서는 0입니다. `type`은 `data` content를 식별하고 `len`은 `data` field length이며 flexible array `data[]`가 실제 payload를 담습니다.
boot 과정 여러 지점에서 이 list를 수정할 수 있습니다. 새 entry를 추가할 때는 기존 linked-list entry가 이미 존재하는 경우를 항상 처리해야 합니다.
아주 큰 object에는 header와 object가 adjacent해야 하고 length가 32 bit라는 제약 때문에 `setup_data`가 불편합니다. 그러나 중간 boot stage가 kernel data가 점유한 memory chunk를 식별할 수 있어야 하므로 protocol 2.15에서 `setup_indirect`와 `SETUP_INDIRECT` type을 도입했습니다.
struct setup_indirect {
__u32 type;
__u32 reserved; /* Reserved, must be set to zero. */
__u64 len;
__u64 addr;
};`setup_indirect.type`은 `SETUP_INDIRECT | SETUP_*`입니다. 단 `SETUP_INDIRECT` 자체일 수는 없습니다. indirect를 tree로 만들면 parser가 많은 stack을 요구할 수 있고 boot context의 stack은 제한적이기 때문입니다. `reserved`는 반드시 0으로 설정하고 64-bit `len`과 physical `addr`로 외부 object를 가리킵니다.
`SETUP_E820_EXT` data를 가리키는 예시는 다음과 같습니다.
struct setup_data {
.next = 0, /* or <addr_of_next_setup_data_struct> */
.type = SETUP_INDIRECT,
.len = sizeof(setup_indirect),
.data[sizeof(setup_indirect)] = (struct setup_indirect) {
.type = SETUP_INDIRECT | SETUP_E820_EXT,
.reserved = 0,
.len = <len_of_SETUP_E820_EXT_data>,
.addr = <addr_of_SETUP_E820_EXT_data>,
},
}`SETUP_INDIRECT | SETUP_NONE` object는 `SETUP_INDIRECT` 자체와 올바르게 구별할 수 없으므로 boot loader가 제공할 수 없습니다.
preferred address와 초기 memory window
869-912| field | type | offset/size | protocol |
|---|---|---|---|
| `pref_address` | read, reloc | `0x258/8` | `2.10+` |
| `init_size` | read | `0x260/4` | setup header field |
`pref_address != 0`이면 kernel의 preferred load address입니다. relocating loader는 가능하면 이 address를 선택합니다. non-relocatable kernel은 무조건 자신을 이 address로 옮겨 실행하고, relocatable kernel도 이 address보다 낮게 load되면 여기로 이동합니다.
`init_size`는 kernel이 memory map을 검사할 수 있게 되기 전까지 runtime start address부터 필요한 linear contiguous memory 양입니다. 전체 boot에 필요한 총 memory와는 다르지만 relocating loader가 안전한 load address를 고르는 데 사용할 수 있습니다.
runtime start와 필요한 memory window는 다음 algorithm으로 계산합니다.
The kernel runtime start address is determined by the following algorithm::
if (relocatable_kernel) {
if (load_address < pref_address)
load_address = pref_address;
runtime_start = align_up(load_address, kernel_alignment);
} else {
runtime_start = pref_address;
}
Hence the necessary memory window location and size can be estimated by
a boot loader as::
memory_window_start = runtime_start;
memory_window_size = init_size;handover_offset과 kernel_info_offset
913-936| field | type | offset/size | protocol |
|---|---|---|---|
| `handover_offset` | read | `0x264/4` | setup header field |
| `kernel_info_offset` | read | `0x268/4` | `2.15+` |
`handover_offset`은 kernel image 시작부터 EFI handover protocol entry point까지의 offset입니다. 이 protocol을 사용하는 loader는 해당 offset으로 jump합니다. 자세한 내용은 문서 끝의 deprecated EFI Handover Protocol 절에 있습니다.
`kernel_info_offset`은 kernel image 시작부터 `kernel_info`까지의 offset입니다. `kernel_info`는 Linux image의 uncompressed protected-mode region에 embed됩니다.
kernel_info의 목적과 확장 형식
937-1004header와 data section의 관계를 비유하면 `setup_header = .data`, `boot_params/setup_data = .bss`, `kernel_info = .rodata`입니다. 과거에는 대안과 관성 때문에 `.rodata`나 `.bss`에 둘 내용을 `.data`에 넣어 왔습니다. BIOS stub이 `boot_params`를 만들기 때문에 BIOS-based loader는 이를 미리 볼 수 없지만 `setup_data`는 사용할 수 있습니다.
`setup_header`는 2-byte `jump` field의 reach와 protected-mode loader 또는 BIOS stub이 복사해야 하는 `struct boot_params` 내부 hole 때문에 영구적으로 144 byte가 한계입니다. 현재 119 byte이므로 남은 공간은 25 byte뿐이며 backward compatibility를 깨는 protocol 전면 개정 없이는 해결할 수 없습니다.
`boot_params` 자체는 4096 byte 제한이 있지만 `setup_data` entry로 임의 확장할 수 있습니다. 다만 `.bss`라 image가 제공한 content가 없으므로 kernel image property 전달에는 쓸 수 없습니다.
`kernel_info`는 kernel image 정보를 위한 extensible read-only 공간입니다. loader가 content를 어디엔가 복사한다고 kernel이 가정할 수 없어 read-only이지만, 필요하면 enabled loader가 `setup_data` chunk로 복사해야 하는 data item을 담을 수 있습니다.
모든 `kernel_info` data는 이 structure 안에 둡니다. fixed-size data는 `kernel_info_var_len_data` label 앞에, variable-size data는 뒤에 둡니다. 각 variable chunk에는 header/magic과 size가 먼저 와야 하며 다음 assembly layout처럼 self-contained blob을 구성합니다.
kernel_info:
.ascii "LToP" /* Header, Linux top (structure). */
.long kernel_info_var_len_data - kernel_info
.long kernel_info_end - kernel_info
.long 0x01234567 /* Some fixed size data for the bootloaders. */
kernel_info_var_len_data:
example_struct: /* Some variable size data for the bootloaders. */
.ascii "0123" /* Header/Magic. */
.long example_struct_end - example_struct
.ascii "Struct"
.long 0x89012345
example_struct_end:
example_strings: /* Some variable size data for the bootloaders. */
.ascii "ABCD" /* Header/Magic. */
.long example_strings_end - example_strings
.asciz "String_0"
.asciz "String_1"
example_strings_end:
kernel_info_end:variable-size data의 header/magic은 기존 variable-length header/magic과 충돌하지 않는 임의의 4-character string일 수 있으며 끝에 `\0`을 붙이지 않습니다.
kernel_info fixed field
1005-1040| field | offset/size | 의미 |
|---|---|---|
| `header` | `0x0000/4` | `LToP` magic number `0x506f544c` |
| `size` | `0x0004/4` | `header`를 포함한 fixed-size `kernel_info` 크기. variable data는 제외합니다. |
| `size_total` | `0x0008/4` | `header`와 `kernel_info_var_len_data`를 모두 포함한 전체 크기 |
| `setup_type_max` | `0x000c/4` | `setup_data`와 `setup_indirect`가 허용하는 최대 type |
boot loader는 `size`로 지원되는 fixed-size field와 `kernel_info.kernel_info_var_len_data` 시작 위치를 판별합니다. `size_total`은 variable-length data까지 포함한 blob 전체 경계를 제공합니다.
kernel command line 전달 protocol
1041-1073kernel command line은 boot loader와 kernel 사이의 중요한 통신 수단이며 일부 option은 loader 자체에도 의미가 있습니다. NUL-terminated string이고 최대 length는 `cmdline_size`에서 읽습니다. protocol 2.06 이전에는 255 characters였으며 너무 긴 string은 kernel이 자동 truncate합니다.
protocol 2.02+에서는 `cmd_line_ptr`가 command-line address를 제공하며 setup heap 끝과 `0xA0000` 사이 어디든 둘 수 있습니다.
2.02보다 오래된 protocol에서는 다음 legacy 형식을 사용합니다.
- offset `0x0020`의 word `cmd_line_magic`에 magic `0xA33F`를 씁니다.
- offset `0x0022`의 word `cmd_line_offset`에 real-mode kernel 시작 기준 command-line offset을 씁니다.
- command line은 `setup_move_size`가 cover하는 memory region 안에 있어야 하므로 필요하면 그 field를 조정합니다.
real-mode code의 stack, heap과 command line
1074-1107real-mode code에는 stack/heap과 command-line memory가 필요하며 모두 bottom megabyte의 real-mode-accessible memory에 배치해야 합니다. modern machine은 EBDA가 클 수 있으므로 low megabyte 사용량을 최소화해야 합니다.
다음 조건에서는 `0x90000` memory segment를 반드시 사용합니다.
- `(loadflags & 0x01) == 0`인 `zImage` kernel을 load할 때
- boot protocol 2.01 이하 kernel을 load할 때
protocol 2.00과 2.01에서는 real-mode code를 다른 address에 load할 수 있지만 내부적으로 `0x90000`으로 relocation합니다. old protocol은 처음부터 `0x90000`에 load해야 합니다.
`0x90000`에 load할 때는 `0x9a000` 위를 사용하지 않습니다. protocol 2.02+에서는 command line을 real-mode setup과 같은 64 KiB segment에 둘 필요가 없으므로 stack/heap에 segment 전체를 주고 command line을 그 위에 둘 수 있습니다. command line은 real-mode code 아래나 high memory에 두지 않아야 합니다.
sample real-mode layout과 header 설정
1108-1184`0x90000` 아래에 load할 때는 real-mode segment 전체를 다음처럼 사용합니다.
| offset range | content |
|---|---|
| `0x0000-0x7fff` | real-mode kernel |
| `0x8000-0xdfff` | stack and heap |
| `0xe000-0xffff` | kernel command line |
`0x90000`에 load하거나 protocol 2.01 이하이면 공간을 다음처럼 줄입니다.
| offset range | content |
|---|---|
| `0x0000-0x7fff` | real-mode kernel |
| `0x8000-0x97ff` | stack and heap |
| `0x9800-0x9fff` | kernel command line |
다음 sample은 `setup_sects == 0`을 4로 보정하고, protocol 2.00+에서 loader type과 initrd를 기록합니다. 2.02+ high-load이면 heap 끝을 `0xe000`, 아니면 `0x9800`으로 정합니다. 2.01+에서는 `heap_end_ptr`와 `CAN_USE_HEAP`을 설정하고, 2.02+에서는 `cmd_line_ptr`를 사용합니다.
더 오래된 protocol은 `cmd_line_magic`, `cmd_line_offset`, `setup_move_size`를 사용합니다. very old kernel은 real-mode code를 반드시 `0x90000`으로 복사하고 command line도 그 segment에 둔 뒤 32 KiB mark까지 남은 memory를 clear하는 것이 권장됩니다.
unsigned long base_ptr; /* base address for real-mode segment */
if (setup_sects == 0)
setup_sects = 4;
if (protocol >= 0x0200) {
type_of_loader = <type code>;
if (loading_initrd) {
ramdisk_image = <initrd_address>;
ramdisk_size = <initrd_size>;
}
if (protocol >= 0x0202 && loadflags & 0x01)
heap_end = 0xe000;
else
heap_end = 0x9800;
if (protocol >= 0x0201) {
heap_end_ptr = heap_end - 0x200;
loadflags |= 0x80; /* CAN_USE_HEAP */
}
if (protocol >= 0x0202) {
cmd_line_ptr = base_ptr + heap_end;
strcpy(cmd_line_ptr, cmdline);
} else {
cmd_line_magic = 0xA33F;
cmd_line_offset = heap_end;
setup_move_size = heap_end + strlen(cmdline) + 1;
strcpy(base_ptr + cmd_line_offset, cmdline);
}
} else {
/* Very old kernel */
heap_end = 0x9800;
cmd_line_magic = 0xA33F;
cmd_line_offset = heap_end;
/* A very old kernel MUST have its real-mode code loaded at 0x90000 */
if (base_ptr != 0x90000) {
/* Copy the real-mode kernel */
memcpy(0x90000, base_ptr, (setup_sects + 1) * 512);
base_ptr = 0x90000; /* Relocated */
}
strcpy(0x90000 + cmd_line_offset, cmdline);
/* It is recommended to clear memory up to the 32K mark */
memset(0x90000 + (setup_sects + 1) * 512, 0, (64 - (setup_sects + 1)) * 512);
}protected-mode kernel load
1185-1204kernel file에서 32-bit non-real-mode kernel은 offset `(setup_sects + 1) * 512`에서 시작합니다. 여기서도 `setup_sects == 0`이면 실제 값은 4입니다. `Image`/`zImage`는 `0x10000`, `bzImage`는 `0x100000`에 load합니다.
protocol이 2.00 이상이고 `loadflags` bit `0x01`(`LOAD_HIGH`)이 설정됐으면 `bzImage`입니다.
is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01);
load_address = is_bzImage ? 0x100000 : 0x10000;`Image`/`zImage`는 최대 512 KiB이므로 `0x10000-0x90000` 전체를 사용할 수 있습니다. 따라서 real-mode 부분을 `0x90000`에 두는 것이 사실상 필수입니다. `bzImage`는 훨씬 유연합니다.
boot loader가 처리하는 command-line option
1205-1254사용자가 입력한 command line에서는 다음 option이 동작할 것으로 기대하므로 kernel 자체에 모두 의미가 없더라도 보통 삭제하지 않아야 합니다. loader 전용 option을 추가하려면 현재나 미래의 kernel option과 충돌하지 않도록 `Documentation/admin-guide/kernel-parameters.rst`에 등록해야 합니다.
| option | boot-loader 의미 |
|---|---|
| `vga=<mode>` | `<mode>`는 C 표기의 decimal/octal/hex integer 또는 `normal`=`0xFFFF`, `ext`=`0xFFFE`, `ask`=`0xFFFD`입니다. kernel이 command line을 parse하기 전에 사용하므로 값을 `vid_mode`에 씁니다. |
| `mem=<size>` | C 표기 integer 뒤에 case-insensitive `K/M/G/T/P/E`를 붙일 수 있으며 각각 `<<10/20/30/40/50/60`을 뜻합니다. kernel에 memory 끝을 지정하고, initrd는 memory 끝 부근에 두므로 placement에도 영향을 줍니다. kernel과 loader 양쪽의 option입니다. |
| `initrd=<file>` | initrd를 load합니다. `<file>`의 의미는 loader-dependent이며 LILO처럼 이 command가 없는 loader도 있습니다. |
| `BOOT_IMAGE=<file>` | load한 boot image를 나타내며 `<file>` 의미는 loader-dependent입니다. |
| `auto` | 명시적 user intervention 없이 boot했음을 나타냅니다. |
loader가 `BOOT_IMAGE=`나 `auto`를 추가한다면 user/configuration command line보다 앞에 배치할 것을 강하게 권장합니다. 뒤에 두면 `init=/bin/sh`가 `auto` option 때문에 혼동됩니다.
real-mode entry에서 kernel 실행
1255-1293kernel은 real-mode kernel 시작에서 segment offset `0x20`에 있는 entry point로 jump해 시작합니다. real-mode code를 `0x90000`에 load했다면 entry point는 `9020:0000`입니다.
진입 시 `ds = es = ss`는 real-mode kernel 시작을 가리켜야 하며 `0x90000` load에서는 `0x9000`입니다. `sp`는 보통 heap top을 가리키도록 올바르게 설정하고 interrupt는 disabled여야 합니다. kernel bug 방어를 위해 `fs = gs = ds = es = ss`로 맞추는 것이 권장됩니다.
/*
* Note: in the case of the "old" kernel protocol, base_ptr must
* be == 0x90000 at this point; see the previous sample code.
*/
seg = base_ptr >> 4;
cli(); /* Enter with interrupts disabled! */
/* Set up the real-mode kernel stack */
_SS = seg;
_SP = heap_end;
_DS = _ES = _FS = _GS = seg;
jmp_far(seg + 0x20, 0); /* Run the kernel */boot sector가 floppy drive에 접근했다면 kernel 실행 전에 motor를 끄는 것이 좋습니다. kernel boot는 interrupt를 끈 상태를 유지하므로, 특히 floppy driver가 demand-loaded module이면 motor가 자동으로 꺼지지 않을 수 있습니다.
hostile environment용 advanced hook
1294-1323DOS 아래서 실행되는 LOADLIN처럼 hostile environment에서는 표준 memory-location requirement를 지키기 어려울 수 있습니다. 이때 kernel이 적절한 시점에 호출하는 hook을 사용할 수 있지만 절대적인 최후 수단으로 간주해야 합니다.
모든 hook은 호출 전후에 `%esp`, `%ebp`, `%esi`, `%edi`를 보존해야 합니다.
| hook | 동작과 요구 사항 |
|---|---|
| `realmode_swtch` | protected mode 진입 직전에 호출되는 16-bit real-mode far subroutine입니다. default routine은 NMI를 disable하므로 custom routine도 그렇게 하는 것이 좋습니다. |
| `code32_start` | protected-mode transition 직후이자 kernel decompression 전에 jump하는 32-bit flat-mode routine입니다. CS 외 segment는 setup이 보장되지 않으므로 직접 `BOOT_DS`(`0x18`)로 설정합니다. 끝나면 loader가 field를 덮어쓰기 전 원래 address로, 필요하면 relocated address로 jump합니다. |
32-bit boot protocol
1324-1361EFI, LinuxBIOS 같은 non-legacy BIOS 또는 kexec에서는 legacy BIOS 기반 16-bit real-mode setup code를 사용할 수 없어 32-bit boot protocol이 필요합니다.
먼저 전통적으로 zero page라 부르는 `struct boot_params`용 memory를 allocate하고 모두 0으로 초기화합니다. kernel image offset `0x01f1`부터 setup header를 `boot_params`에 load해 검사하며 header 끝은 다음과 같습니다.
0x0202 + byte value at offset 0x020116-bit protocol과 동일하게 setup header를 read/modify/write하는 것 외에 `Documentation/arch/x86/zero-page.rst`의 추가 `struct boot_params` field도 채웁니다. 그 뒤 16-bit protocol과 같은 방식으로 32/64-bit kernel을 load하고, load된 kernel 시작 address인 32-bit entry point로 jump합니다.
entry에서 CPU는 paging이 disabled된 32-bit protected mode여야 합니다. GDT에는 selector `__BOOT_CS`(`0x10`)와 `__BOOT_DS`(`0x18`) descriptor가 있어야 하고 둘 다 4 GiB flat segment여야 합니다. `__BOOT_CS`에는 execute/read, `__BOOT_DS`에는 read/write permission이 필요합니다.
`CS=__BOOT_CS`, `DS=ES=SS=__BOOT_DS`로 설정하고 interrupt를 disable합니다. `%esi`는 `struct boot_params` base address를 담고 `%ebp`, `%edi`, `%ebx`는 0이어야 합니다.
64-bit boot protocol
1362-140064-bit CPU와 64-bit kernel에서는 64-bit boot loader와 64-bit boot protocol을 사용할 수 있습니다. 먼저 `struct boot_params` memory를 4 GiB 위를 포함한 임의의 address에 allocate하고 모두 0으로 초기화합니다.
kernel image offset `0x01f1`부터 setup header를 `boot_params`에 load해 검사합니다. header 끝 계산식은 32-bit protocol과 같습니다.
0x0202 + byte value at offset 0x020116-bit protocol처럼 setup header를 read/modify/write하고 `Documentation/arch/x86/zero-page.rst`의 추가 field도 채웁니다. 64-bit kernel load 방식도 16-bit protocol과 같지만 kernel을 4 GiB 위에 둘 수 있습니다. entry point는 load된 64-bit kernel 시작 address에 `0x200`을 더한 곳입니다.
entry에서 CPU는 paging이 enabled된 64-bit mode여야 합니다. load된 kernel 시작부터 `setup_header.init_size` 범위, zero page, command-line buffer를 identity map합니다. GDT에는 4 GiB flat `__BOOT_CS`(`0x10`, execute/read)와 `__BOOT_DS`(`0x18`, read/write`) descriptor를 load합니다.
`CS=__BOOT_CS`, `DS=ES=SS=__BOOT_DS`로 설정하고 interrupt를 disable합니다. `%rsi`는 `struct boot_params` base address를 담아야 합니다.
deprecated EFI Handover Protocol
1401-1442이 deprecated protocol은 initialization을 EFI boot stub에 넘깁니다. boot loader는 boot media에서 kernel과 initrd를 load하고 `startup_{32,64}` 시작으로부터 `hdr->handover_offset` byte인 EFI handover entry point로 jump합니다.
loader는 section alignment, file size를 넘어서는 executable-image memory footprint, 그리고 EFI firmware가 제공한 execution context에서 PE/COFF binary의 올바른 동작에 영향을 주는 모든 metadata를 포함해 kernel PE/COFF header를 반드시 준수해야 합니다.
handover entry point prototype은 다음과 같습니다.
void efi_stub_entry(void *handle, efi_system_table_t *table, struct boot_params *bp);`handle`은 EFI firmware가 loader에 전달한 EFI image handle이고 `table`은 EFI system table입니다. 둘은 UEFI specification section 2.3의 handoff state 첫 두 argument입니다. `bp`는 loader가 allocate한 boot params입니다.
loader는 `bp`에서 다음 field를 반드시 채우고 나머지는 모두 0으로 둡니다.
- `hdr.cmd_line_ptr`
- `hdr.ramdisk_image` (해당하는 경우)
- `hdr.ramdisk_size` (해당하는 경우)
EFI Handover Protocol 대신 일반 PE/COFF entry point와 `LINUX_EFI_INITRD_MEDIA_GUID` 기반 initrd load protocol을 사용해야 합니다. 이 방식은 EFI loader가 `boot_params` 내부 표현이나 command line·ramdisk·kernel image placement requirement를 알 필요를 없앱니다.
boot-loader 측 예시는 `https://github.com/u-boot/u-boot/commit/ec80b4735a593961fe701cc3a5d717d4739b0fd0`에서 확인할 수 있습니다.
요약과 해설
boot.rst:1-1442이 문서는 old `zImage`부터 modern `bzImage`, protocol 2.15의 `kernel_info`까지 이어지는 x86 boot ABI를 규정합니다. 핵심은 kernel image의 setup header를 version에 맞게 해석하고, low-memory EBDA를 침범하지 않으며, command line·initrd·`boot_params`·kernel image를 각 protocol의 address와 alignment 제약에 맞춰 배치하는 것입니다.
setup header field는 kernel에서 읽는 값, loader가 쓰는 값, 읽고 수정하는 값으로 나뉩니다. 범용 loader는 obligatory field를 채우고 relocation을 지원하면 `kernel_alignment`, `min_alignment`, `pref_address`, `init_size`를 함께 고려해야 합니다. 확장 data는 `setup_data`/`setup_indirect`, image capability는 `kernel_info`로 전달합니다.
kernel entry 조건은 boot mode마다 다릅니다. real mode에서는 segment register와 stack을 준비해 offset `0x20`으로 jump하고, 32-bit protocol은 paging-off protected mode와 `%esi=boot_params`, 64-bit protocol은 paging-on long mode, identity mapping과 `%rsi=boot_params`를 요구합니다. deprecated EFI handover 대신 일반 PE/COFF entry와 GUID 기반 initrd protocol이 권장됩니다.