@@ -68,8 +68,25 @@ Protocol 2.12 (Kernel 3.8) Added the xloadflags field and extension fields
68
68
Protocol 2.13 (Kernel 3.14) Support 32- and 64-bit flags being set in
69
69
xloadflags to support booting a 64-bit kernel from 32-bit
70
70
EFI
71
+
72
+ Protocol 2.14: BURNT BY INCORRECT COMMIT ae7e1238e68f2a472a125673ab506d49158c1889
73
+ (x86/boot: Add ACPI RSDP address to setup_header)
74
+ DO NOT USE!!! ASSUME SAME AS 2.13.
75
+
76
+ Protocol 2.15: (Kernel 5.5) Added the kernel_info and kernel_info.setup_type_max.
71
77
============= ============================================================
72
78
79
+ .. note ::
80
+ The protocol version number should be changed only if the setup header
81
+ is changed. There is no need to update the version number if boot_params
82
+ or kernel_info are changed. Additionally, it is recommended to use
83
+ xloadflags (in this case the protocol version number should not be
84
+ updated either) or kernel_info to communicate supported Linux kernel
85
+ features to the boot loader. Due to very limited space available in
86
+ the original setup header every update to it should be considered
87
+ with great care. Starting from the protocol 2.15 the primary way to
88
+ communicate things to the boot loader is the kernel_info.
89
+
73
90
74
91
Memory Layout
75
92
=============
@@ -207,6 +224,7 @@ Offset/Size Proto Name Meaning
207
224
0258/8 2.10+ pref_address Preferred loading address
208
225
0260/4 2.10+ init_size Linear memory required during initialization
209
226
0264/4 2.11+ handover_offset Offset of handover entry point
227
+ 0268/4 2.15+ kernel_info_offset Offset of the kernel_info
210
228
=========== ======== ===================== ============================================
211
229
212
230
.. note ::
@@ -809,6 +827,47 @@ Protocol: 2.09+
809
827
sure to consider the case where the linked list already contains
810
828
entries.
811
829
830
+ The setup_data is a bit awkward to use for extremely large data objects,
831
+ both because the setup_data header has to be adjacent to the data object
832
+ and because it has a 32-bit length field. However, it is important that
833
+ intermediate stages of the boot process have a way to identify which
834
+ chunks of memory are occupied by kernel data.
835
+
836
+ Thus setup_indirect struct and SETUP_INDIRECT type were introduced in
837
+ protocol 2.15.
838
+
839
+ struct setup_indirect {
840
+ __u32 type;
841
+ __u32 reserved; /* Reserved, must be set to zero. */
842
+ __u64 len;
843
+ __u64 addr;
844
+ };
845
+
846
+ The type member is a SETUP_INDIRECT | SETUP_* type. However, it cannot be
847
+ SETUP_INDIRECT itself since making the setup_indirect a tree structure
848
+ could require a lot of stack space in something that needs to parse it
849
+ and stack space can be limited in boot contexts.
850
+
851
+ Let's give an example how to point to SETUP_E820_EXT data using setup_indirect.
852
+ In this case setup_data and setup_indirect will look like this:
853
+
854
+ struct setup_data {
855
+ __u64 next = 0 or <addr_of_next_setup_data_struct>;
856
+ __u32 type = SETUP_INDIRECT;
857
+ __u32 len = sizeof(setup_data);
858
+ __u8 data[sizeof(setup_indirect)] = struct setup_indirect {
859
+ __u32 type = SETUP_INDIRECT | SETUP_E820_EXT;
860
+ __u32 reserved = 0;
861
+ __u64 len = <len_of_SETUP_E820_EXT_data>;
862
+ __u64 addr = <addr_of_SETUP_E820_EXT_data>;
863
+ }
864
+ }
865
+
866
+ .. note ::
867
+ SETUP_INDIRECT | SETUP_NONE objects cannot be properly distinguished
868
+ from SETUP_INDIRECT itself. So, this kind of objects cannot be provided
869
+ by the bootloaders.
870
+
812
871
============ ============
813
872
Field name: pref_address
814
873
Type: read (reloc)
@@ -855,6 +914,121 @@ Offset/size: 0x264/4
855
914
856
915
See EFI HANDOVER PROTOCOL below for more details.
857
916
917
+ ============ ==================
918
+ Field name: kernel_info_offset
919
+ Type: read
920
+ Offset/size: 0x268/4
921
+ Protocol: 2.15+
922
+ ============ ==================
923
+
924
+ This field is the offset from the beginning of the kernel image to the
925
+ kernel_info. The kernel_info structure is embedded in the Linux image
926
+ in the uncompressed protected mode region.
927
+
928
+
929
+ The kernel_info
930
+ ===============
931
+
932
+ The relationships between the headers are analogous to the various data
933
+ sections:
934
+
935
+ setup_header = .data
936
+ boot_params/setup_data = .bss
937
+
938
+ What is missing from the above list? That's right:
939
+
940
+ kernel_info = .rodata
941
+
942
+ We have been (ab)using .data for things that could go into .rodata or .bss for
943
+ a long time, for lack of alternatives and -- especially early on -- inertia.
944
+ Also, the BIOS stub is responsible for creating boot_params, so it isn't
945
+ available to a BIOS-based loader (setup_data is, though).
946
+
947
+ setup_header is permanently limited to 144 bytes due to the reach of the
948
+ 2-byte jump field, which doubles as a length field for the structure, combined
949
+ with the size of the "hole" in struct boot_params that a protected-mode loader
950
+ or the BIOS stub has to copy it into. It is currently 119 bytes long, which
951
+ leaves us with 25 very precious bytes. This isn't something that can be fixed
952
+ without revising the boot protocol entirely, breaking backwards compatibility.
953
+
954
+ boot_params proper is limited to 4096 bytes, but can be arbitrarily extended
955
+ by adding setup_data entries. It cannot be used to communicate properties of
956
+ the kernel image, because it is .bss and has no image-provided content.
957
+
958
+ kernel_info solves this by providing an extensible place for information about
959
+ the kernel image. It is readonly, because the kernel cannot rely on a
960
+ bootloader copying its contents anywhere, but that is OK; if it becomes
961
+ necessary it can still contain data items that an enabled bootloader would be
962
+ expected to copy into a setup_data chunk.
963
+
964
+ All kernel_info data should be part of this structure. Fixed size data have to
965
+ be put before kernel_info_var_len_data label. Variable size data have to be put
966
+ after kernel_info_var_len_data label. Each chunk of variable size data has to
967
+ be prefixed with header/magic and its size, e.g.:
968
+
969
+ kernel_info:
970
+ .ascii "LToP" /* Header, Linux top (structure). */
971
+ .long kernel_info_var_len_data - kernel_info
972
+ .long kernel_info_end - kernel_info
973
+ .long 0x01234567 / * Some fixed size data for the bootloaders. */
974
+ kernel_info_var_len_data:
975
+ example_struct: / * Some variable size data for the bootloaders. */
976
+ .ascii "0123" / * Header/Magic. */
977
+ .long example_struct_end - example_struct
978
+ .ascii "Struct"
979
+ .long 0x89012345
980
+ example_struct_end:
981
+ example_strings: / * Some variable size data for the bootloaders. */
982
+ .ascii "ABCD" / * Header/Magic. */
983
+ .long example_strings_end - example_strings
984
+ .asciz "String_0"
985
+ .asciz "String_1"
986
+ example_strings_end:
987
+ kernel_info_end:
988
+
989
+ This way the kernel_info is self-contained blob.
990
+
991
+ .. note ::
992
+ Each variable size data header/magic can be any 4-character string,
993
+ without \0 at the end of the string, which does not collide with
994
+ existing variable length data headers/magics.
995
+
996
+
997
+ Details of the kernel_info Fields
998
+ =================================
999
+
1000
+ ============ ========
1001
+ Field name: header
1002
+ Offset/size: 0x0000/4
1003
+ ============ ========
1004
+
1005
+ Contains the magic number "LToP" (0x506f544c).
1006
+
1007
+ ============ ========
1008
+ Field name: size
1009
+ Offset/size: 0x0004/4
1010
+ ============ ========
1011
+
1012
+ This field contains the size of the kernel_info including kernel_info.header.
1013
+ It does not count kernel_info.kernel_info_var_len_data size. This field should be
1014
+ used by the bootloaders to detect supported fixed size fields in the kernel_info
1015
+ and beginning of kernel_info.kernel_info_var_len_data.
1016
+
1017
+ ============ ========
1018
+ Field name: size_total
1019
+ Offset/size: 0x0008/4
1020
+ ============ ========
1021
+
1022
+ This field contains the size of the kernel_info including kernel_info.header
1023
+ and kernel_info.kernel_info_var_len_data.
1024
+
1025
+ ============ ==============
1026
+ Field name: setup_type_max
1027
+ Offset/size: 0x000c/4
1028
+ ============ ==============
1029
+
1030
+ This field contains maximal allowed type for setup_data and setup_indirect structs.
1031
+
858
1032
859
1033
The Image Checksum
860
1034
==================
0 commit comments