linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/3] x86/boot: Introduce the kernel_info et consortes
@ 2019-07-04 16:36 Daniel Kiper
  2019-07-04 16:36 ` [PATCH v2 1/3] x86/boot: Introduce the kernel_info Daniel Kiper
                   ` (3 more replies)
  0 siblings, 4 replies; 14+ messages in thread
From: Daniel Kiper @ 2019-07-04 16:36 UTC (permalink / raw)
  To: linux-doc, linux-kernel, x86
  Cc: bp, corbet, dpsmith, eric.snowberg, hpa, kanth.ghatraju,
	konrad.wilk, mingo, ross.philipson, tglx

Hi,

Due to very limited space in the setup_header this patch series introduces new
kernel_info struct which will be used to convey information from the kernel to
the bootloader. This way the boot protocol can be extended regardless of the
setup_header limitations. Additionally, the patch series introduces some
convenience features like the setup_indirect struct and the
kernel_info.setup_type_max field.

Daniel

 Documentation/x86/boot.rst             | 133 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 arch/x86/boot/Makefile                 |   2 +-
 arch/x86/boot/compressed/Makefile      |   4 +--
 arch/x86/boot/compressed/kernel_info.S |  16 ++++++++++
 arch/x86/boot/header.S                 |   3 +-
 arch/x86/boot/tools/build.c            |   5 +++
 arch/x86/include/uapi/asm/bootparam.h  |  15 ++++++++-
 7 files changed, 173 insertions(+), 5 deletions(-)

Daniel Kiper (3):
      x86/boot: Introduce the kernel_info
      x86/boot: Introduce the setup_indirect
      x86/boot: Introduce the kernel_info.setup_type_max


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH v2 1/3] x86/boot: Introduce the kernel_info
  2019-07-04 16:36 [PATCH v2 0/3] x86/boot: Introduce the kernel_info et consortes Daniel Kiper
@ 2019-07-04 16:36 ` Daniel Kiper
  2019-07-12 16:04   ` hpa
  2019-07-04 16:36 ` [PATCH v2 2/3] x86/boot: Introduce the setup_indirect Daniel Kiper
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 14+ messages in thread
From: Daniel Kiper @ 2019-07-04 16:36 UTC (permalink / raw)
  To: linux-doc, linux-kernel, x86
  Cc: bp, corbet, dpsmith, eric.snowberg, hpa, kanth.ghatraju,
	konrad.wilk, mingo, ross.philipson, tglx

The relationships between the headers are analogous to the various data
sections:

  setup_header = .data
  boot_params/setup_data = .bss

What is missing from the above list? That's right:

  kernel_info = .rodata

We have been (ab)using .data for things that could go into .rodata or .bss for
a long time, for lack of alternatives and -- especially early on -- inertia.
Also, the BIOS stub is responsible for creating boot_params, so it isn't
available to a BIOS-based loader (setup_data is, though).

setup_header is permanently limited to 144 bytes due to the reach of the
2-byte jump field, which doubles as a length field for the structure, combined
with the size of the "hole" in struct boot_params that a protected-mode loader
or the BIOS stub has to copy it into. It is currently 119 bytes long, which
leaves us with 25 very precious bytes. This isn't something that can be fixed
without revising the boot protocol entirely, breaking backwards compatibility.

boot_params proper is limited to 4096 bytes, but can be arbitrarily extended
by adding setup_data entries. It cannot be used to communicate properties of
the kernel image, because it is .bss and has no image-provided content.

kernel_info solves this by providing an extensible place for information about
the kernel image. It is readonly, because the kernel cannot rely on a
bootloader copying its contents anywhere, but that is OK; if it becomes
necessary it can still contain data items that an enabled bootloader would be
expected to copy into a setup_data chunk.

This patch does not bump setup_header version in arch/x86/boot/header.S
because it will be followed by additional changes coming into the
Linux/x86 boot protocol.

Suggested-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
---
v2 - suggestions/fixes:
   - rename setup_header2 to kernel_info,
     (suggested by H. Peter Anvin),
   - change kernel_info.header value to "InfO" (0x4f666e49),
   - new kernel_info description in Documentation/x86/boot.rst,
     (suggested by H. Peter Anvin),
   - drop kernel_info_offset_update() as an overkill and
     update kernel_info offset directly from main(),
     (suggested by Eric Snowberg),
   - new commit message
     (suggested by H. Peter Anvin),
   - fix some commit message misspellings
     (suggested by Eric Snowberg).
---
 Documentation/x86/boot.rst             | 89 ++++++++++++++++++++++++++++++++++
 arch/x86/boot/Makefile                 |  2 +-
 arch/x86/boot/compressed/Makefile      |  4 +-
 arch/x86/boot/compressed/kernel_info.S | 12 +++++
 arch/x86/boot/header.S                 |  1 +
 arch/x86/boot/tools/build.c            |  5 ++
 arch/x86/include/uapi/asm/bootparam.h  |  1 +
 7 files changed, 111 insertions(+), 3 deletions(-)
 create mode 100644 arch/x86/boot/compressed/kernel_info.S

diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index 08a2f100c0e6..a934a56f0516 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -68,8 +68,25 @@ Protocol 2.12	(Kernel 3.8) Added the xloadflags field and extension fields
 Protocol 2.13	(Kernel 3.14) Support 32- and 64-bit flags being set in
 		xloadflags to support booting a 64-bit kernel from 32-bit
 		EFI
+
+Protocol 2.14:	BURNT BY INCORRECT COMMIT ae7e1238e68f2a472a125673ab506d49158c1889
+		(x86/boot: Add ACPI RSDP address to setup_header)
+		DO NOT USE!!! ASSUME SAME AS 2.13.
+
+Protocol 2.15:	(Kernel 5.3) Added the kernel_info.
 =============	============================================================
 
+.. note::
+     The protocol version number should be changed only if the setup header
+     is changed. There is no need to update the version number if boot_params
+     or kernel_info are changed. Additionally, it is recommended to use
+     xloadflags (in this case the protocol version number should not be
+     updated either) or kernel_info to communicate supported Linux kernel
+     features to the boot loader. Due to very limited space available in
+     the original setup header every update to it should be considered
+     with great care. Starting from the protocol 2.15 the primary way to
+     communicate things to the boot loader is the kernel_info.
+
 
 Memory Layout
 =============
@@ -207,6 +224,7 @@ Offset/Size	Proto		Name			Meaning
 0258/8		2.10+		pref_address		Preferred loading address
 0260/4		2.10+		init_size		Linear memory required during initialization
 0264/4		2.11+		handover_offset		Offset of handover entry point
+0268/4		2.15+		kernel_info_offset	Offset of the kernel_info
 ===========	========	=====================	============================================
 
 .. note::
@@ -855,6 +873,77 @@ Offset/size:	0x264/4
 
   See EFI HANDOVER PROTOCOL below for more details.
 
+============	==================
+Field name:	kernel_info_offset
+Type:		read
+Offset/size:	0x268/4
+Protocol:	2.15+
+============	==================
+
+  This field is the offset from the beginning of the kernel image to the
+  kernel_info. It is embedded in the Linux image in the uncompressed
+  protected mode region.
+
+
+The kernel_info
+===============
+
+The relationships between the headers are analogous to the various data
+sections:
+
+  setup_header = .data
+  boot_params/setup_data = .bss
+
+What is missing from the above list? That's right:
+
+  kernel_info = .rodata
+
+We have been (ab)using .data for things that could go into .rodata or .bss for
+a long time, for lack of alternatives and -- especially early on -- inertia.
+Also, the BIOS stub is responsible for creating boot_params, so it isn't
+available to a BIOS-based loader (setup_data is, though).
+
+setup_header is permanently limited to 144 bytes due to the reach of the
+2-byte jump field, which doubles as a length field for the structure, combined
+with the size of the "hole" in struct boot_params that a protected-mode loader
+or the BIOS stub has to copy it into. It is currently 119 bytes long, which
+leaves us with 25 very precious bytes. This isn't something that can be fixed
+without revising the boot protocol entirely, breaking backwards compatibility.
+
+boot_params proper is limited to 4096 bytes, but can be arbitrarily extended
+by adding setup_data entries. It cannot be used to communicate properties of
+the kernel image, because it is .bss and has no image-provided content.
+
+kernel_info solves this by providing an extensible place for information about
+the kernel image. It is readonly, because the kernel cannot rely on a
+bootloader copying its contents anywhere, but that is OK; if it becomes
+necessary it can still contain data items that an enabled bootloader would be
+expected to copy into a setup_data chunk.
+
+It is recommended to not store large data chunks, e.g. strings, directly in the
+kernel_info struct. Such data should be placed outside of it and pointed from
+the kernel_info structure using offsets from the beginning of the structure,
+the kernel_info.header field.
+
+
+Details of the kernel_info Fields
+=================================
+
+============	========
+Field name:	header
+Offset/size:	0x0000/4
+============	========
+
+  Contains the magic number "InfO" (0x4f666e49).
+
+============	========
+Field name:	size
+Offset/size:	0x0004/4
+============	========
+
+  This field contains the size of the kernel_info including kernel_info.header.
+  It should be used by the boot loader to detect supported fields in the kernel_info.
+
 
 The Image Checksum
 ==================
diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index e2839b5c246c..c30a9b642a86 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -87,7 +87,7 @@ $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE
 
 SETUP_OBJS = $(addprefix $(obj)/,$(setup-y))
 
-sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW] \(startup_32\|startup_64\|efi32_stub_entry\|efi64_stub_entry\|efi_pe_entry\|input_data\|_end\|_ehead\|_text\|z_.*\)$$/\#define ZO_\2 0x\1/p'
+sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW] \(startup_32\|startup_64\|efi32_stub_entry\|efi64_stub_entry\|efi_pe_entry\|input_data\|kernel_info\|_end\|_ehead\|_text\|z_.*\)$$/\#define ZO_\2 0x\1/p'
 
 quiet_cmd_zoffset = ZOFFSET $@
       cmd_zoffset = $(NM) $< | sed -n $(sed-zoffset) > $@
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index 6b84afdd7538..fad3b18e2cc3 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -72,8 +72,8 @@ $(obj)/../voffset.h: vmlinux FORCE
 
 $(obj)/misc.o: $(obj)/../voffset.h
 
-vmlinux-objs-y := $(obj)/vmlinux.lds $(obj)/head_$(BITS).o $(obj)/misc.o \
-	$(obj)/string.o $(obj)/cmdline.o $(obj)/error.o \
+vmlinux-objs-y := $(obj)/vmlinux.lds $(obj)/kernel_info.o $(obj)/head_$(BITS).o \
+	$(obj)/misc.o $(obj)/string.o $(obj)/cmdline.o $(obj)/error.o \
 	$(obj)/piggy.o $(obj)/cpuflags.o
 
 vmlinux-objs-$(CONFIG_EARLY_PRINTK) += $(obj)/early_serial_console.o
diff --git a/arch/x86/boot/compressed/kernel_info.S b/arch/x86/boot/compressed/kernel_info.S
new file mode 100644
index 000000000000..3f1cb301b9ff
--- /dev/null
+++ b/arch/x86/boot/compressed/kernel_info.S
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+	.section ".rodata.kernel_info", "a"
+
+	.global kernel_info
+
+kernel_info:
+        /* Header. */
+	.ascii	"InfO"
+        /* Size. */
+	.long	kernel_info_end - kernel_info
+kernel_info_end:
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 850b8762e889..ec6a25a43148 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -557,6 +557,7 @@ pref_address:		.quad LOAD_PHYSICAL_ADDR	# preferred load addr
 
 init_size:		.long INIT_SIZE		# kernel initialization size
 handover_offset:	.long 0			# Filled in by build.c
+kernel_info_offset:	.long 0			# Filled in by build.c
 
 # End of setup header #####################################################
 
diff --git a/arch/x86/boot/tools/build.c b/arch/x86/boot/tools/build.c
index a93d44e58f9c..55e669d29e54 100644
--- a/arch/x86/boot/tools/build.c
+++ b/arch/x86/boot/tools/build.c
@@ -56,6 +56,7 @@ u8 buf[SETUP_SECT_MAX*512];
 unsigned long efi32_stub_entry;
 unsigned long efi64_stub_entry;
 unsigned long efi_pe_entry;
+unsigned long kernel_info;
 unsigned long startup_64;
 
 /*----------------------------------------------------------------------*/
@@ -321,6 +322,7 @@ static void parse_zoffset(char *fname)
 		PARSE_ZOFS(p, efi32_stub_entry);
 		PARSE_ZOFS(p, efi64_stub_entry);
 		PARSE_ZOFS(p, efi_pe_entry);
+		PARSE_ZOFS(p, kernel_info);
 		PARSE_ZOFS(p, startup_64);
 
 		p = strchr(p, '\n');
@@ -410,6 +412,9 @@ int main(int argc, char ** argv)
 
 	efi_stub_entry_update();
 
+	/* Update kernel_info offset. */
+	put_unaligned_le32(kernel_info, &buf[0x268]);
+
 	crc = partial_crc32(buf, i, crc);
 	if (fwrite(buf, 1, i, dest) != i)
 		die("Writing setup failed");
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 60733f137e9a..b05318112452 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -86,6 +86,7 @@ struct setup_header {
 	__u64	pref_address;
 	__u32	init_size;
 	__u32	handover_offset;
+	__u32	kernel_info_offset;
 } __attribute__((packed));
 
 struct sys_desc_table {
-- 
2.11.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH v2 2/3] x86/boot: Introduce the setup_indirect
  2019-07-04 16:36 [PATCH v2 0/3] x86/boot: Introduce the kernel_info et consortes Daniel Kiper
  2019-07-04 16:36 ` [PATCH v2 1/3] x86/boot: Introduce the kernel_info Daniel Kiper
@ 2019-07-04 16:36 ` Daniel Kiper
  2019-07-12 15:56   ` hpa
  2019-07-04 16:36 ` [PATCH v2 3/3] x86/boot: Introduce the kernel_info.setup_type_max Daniel Kiper
  2019-07-12 11:58 ` [PATCH v2 0/3] x86/boot: Introduce the kernel_info et consortes Daniel Kiper
  3 siblings, 1 reply; 14+ messages in thread
From: Daniel Kiper @ 2019-07-04 16:36 UTC (permalink / raw)
  To: linux-doc, linux-kernel, x86
  Cc: bp, corbet, dpsmith, eric.snowberg, hpa, kanth.ghatraju,
	konrad.wilk, mingo, ross.philipson, tglx

The setup_data is a bit awkward to use for extremely large data objects,
both because the setup_data header has to be adjacent to the data object
and because it has a 32-bit length field. However, it is important that
intermediate stages of the boot process have a way to identify which
chunks of memory are occupied by kernel data.

Thus we introduce a uniform way to specify such indirect data as
setup_indirect struct and SETUP_INDIRECT type.

This patch does not bump setup_header version in arch/x86/boot/header.S
because it will be followed by additional changes coming into the
Linux/x86 boot protocol.

Suggested-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
---
v2 - suggestions/fixes:
   - add setup_indirect usage example
     (suggested by Eric Snowberg and Ross Philipson).
---
 Documentation/x86/boot.rst            | 38 ++++++++++++++++++++++++++++++++++-
 arch/x86/include/uapi/asm/bootparam.h | 11 +++++++++-
 2 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index a934a56f0516..23d3726d54fc 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -73,7 +73,7 @@ Protocol 2.14:	BURNT BY INCORRECT COMMIT ae7e1238e68f2a472a125673ab506d49158c188
 		(x86/boot: Add ACPI RSDP address to setup_header)
 		DO NOT USE!!! ASSUME SAME AS 2.13.
 
-Protocol 2.15:	(Kernel 5.3) Added the kernel_info.
+Protocol 2.15:	(Kernel 5.3) Added the kernel_info and setup_indirect.
 =============	============================================================
 
 .. note::
@@ -827,6 +827,42 @@ Protocol:	2.09+
   sure to consider the case where the linked list already contains
   entries.
 
+  The setup_data is a bit awkward to use for extremely large data objects,
+  both because the setup_data header has to be adjacent to the data object
+  and because it has a 32-bit length field. However, it is important that
+  intermediate stages of the boot process have a way to identify which
+  chunks of memory are occupied by kernel data.
+
+  Thus setup_indirect struct and SETUP_INDIRECT type were introduced in
+  protocol 2.15.
+  
+  struct setup_indirect {
+    __u32 type;
+    __u32 reserved;  /* Reserved, must be set to zero. */
+    __u64 len;
+    __u64 addr;
+  };
+
+  The type member is itself simply a SETUP_* type. However, it cannot be
+  SETUP_INDIRECT since making the setup_indirect a tree structure could
+  require a lot of stack space in something that needs to parse it and
+  stack space can be limited in boot contexts.
+
+  Let's give an example how to point to SETUP_E820_EXT data using setup_indirect.
+  In this case setup_data and setup_indirect will look like this:
+
+  struct setup_data {
+    __u64 next = 0 or <addr_of_next_setup_data_struct>;
+    __u32 type = SETUP_INDIRECT;
+    __u32 len = sizeof(setup_data);
+    __u8 data[sizeof(setup_indirect)] = struct setup_indirect {
+      __u32 type = SETUP_E820_EXT;
+      __u32 reserved = 0;
+      __u64 len = <len_of_SETUP_E820_EXT_data>;
+      __u64 addr = <addr_of_SETUP_E820_EXT_data>;
+    }
+  }
+
 ============	============
 Field name:	pref_address
 Type:		read (reloc)
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index b05318112452..aaaa17fa6ad6 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_BOOTPARAM_H
 #define _ASM_X86_BOOTPARAM_H
 
-/* setup_data types */
+/* setup_data/setup_indirect types */
 #define SETUP_NONE			0
 #define SETUP_E820_EXT			1
 #define SETUP_DTB			2
@@ -10,6 +10,7 @@
 #define SETUP_EFI			4
 #define SETUP_APPLE_PROPERTIES		5
 #define SETUP_JAILHOUSE			6
+#define SETUP_INDIRECT			7
 
 /* ram_size flags */
 #define RAMDISK_IMAGE_START_MASK	0x07FF
@@ -47,6 +48,14 @@ struct setup_data {
 	__u8 data[0];
 };
 
+/* extensible setup indirect data node */
+struct setup_indirect {
+	__u32 type;
+	__u32 reserved;  /* Reserved, must be set to zero. */
+	__u64 len;
+	__u64 addr;
+};
+
 struct setup_header {
 	__u8	setup_sects;
 	__u16	root_flags;
-- 
2.11.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH v2 3/3] x86/boot: Introduce the kernel_info.setup_type_max
  2019-07-04 16:36 [PATCH v2 0/3] x86/boot: Introduce the kernel_info et consortes Daniel Kiper
  2019-07-04 16:36 ` [PATCH v2 1/3] x86/boot: Introduce the kernel_info Daniel Kiper
  2019-07-04 16:36 ` [PATCH v2 2/3] x86/boot: Introduce the setup_indirect Daniel Kiper
@ 2019-07-04 16:36 ` Daniel Kiper
  2019-07-12 15:59   ` hpa
  2019-07-12 11:58 ` [PATCH v2 0/3] x86/boot: Introduce the kernel_info et consortes Daniel Kiper
  3 siblings, 1 reply; 14+ messages in thread
From: Daniel Kiper @ 2019-07-04 16:36 UTC (permalink / raw)
  To: linux-doc, linux-kernel, x86
  Cc: bp, corbet, dpsmith, eric.snowberg, hpa, kanth.ghatraju,
	konrad.wilk, mingo, ross.philipson, tglx

This field contains maximal allowed type for setup_data and
setup_indirect structs.

And finally bump setup_header version in arch/x86/boot/header.S.

Suggested-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 Documentation/x86/boot.rst             | 10 +++++++++-
 arch/x86/boot/compressed/kernel_info.S |  4 ++++
 arch/x86/boot/header.S                 |  2 +-
 arch/x86/include/uapi/asm/bootparam.h  |  3 +++
 4 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index 23d3726d54fc..63609fd0517f 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -73,7 +73,8 @@ Protocol 2.14:	BURNT BY INCORRECT COMMIT ae7e1238e68f2a472a125673ab506d49158c188
 		(x86/boot: Add ACPI RSDP address to setup_header)
 		DO NOT USE!!! ASSUME SAME AS 2.13.
 
-Protocol 2.15:	(Kernel 5.3) Added the kernel_info and setup_indirect.
+Protocol 2.15:	(Kernel 5.3) Added the kernel_info, kernel_info.setup_type_max
+		and setup_indirect.
 =============	============================================================
 
 .. note::
@@ -980,6 +981,13 @@ Offset/size:	0x0004/4
   This field contains the size of the kernel_info including kernel_info.header.
   It should be used by the boot loader to detect supported fields in the kernel_info.
 
+============	==============
+Field name:	setup_type_max
+Offset/size:	0x0008/4
+============	==============
+
+  This field contains maximal allowed type for setup_data and setup_indirect structs.
+
 
 The Image Checksum
 ==================
diff --git a/arch/x86/boot/compressed/kernel_info.S b/arch/x86/boot/compressed/kernel_info.S
index 3f1cb301b9ff..2f28aabf6558 100644
--- a/arch/x86/boot/compressed/kernel_info.S
+++ b/arch/x86/boot/compressed/kernel_info.S
@@ -1,5 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 
+#include <asm/bootparam.h>
+
 	.section ".rodata.kernel_info", "a"
 
 	.global kernel_info
@@ -9,4 +11,6 @@ kernel_info:
 	.ascii	"InfO"
         /* Size. */
 	.long	kernel_info_end - kernel_info
+        /* Maximal allowed type for setup_data and setup_indirect structs. */
+	.long	SETUP_TYPE_MAX
 kernel_info_end:
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index ec6a25a43148..893a456663ab 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -300,7 +300,7 @@ _start:
 	# Part 2 of the header, from the old setup.S
 
 		.ascii	"HdrS"		# header signature
-		.word	0x020d		# header version number (>= 0x0105)
+		.word	0x020f		# header version number (>= 0x0105)
 					# or else old loadlin-1.5 will fail)
 		.globl realmode_swtch
 realmode_swtch:	.word	0, 0		# default_switch, SETUPSEG
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index aaaa17fa6ad6..2ba870dae6f3 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -12,6 +12,9 @@
 #define SETUP_JAILHOUSE			6
 #define SETUP_INDIRECT			7
 
+/* max(SETUP_*) */
+#define SETUP_TYPE_MAX			SETUP_INDIRECT
+
 /* ram_size flags */
 #define RAMDISK_IMAGE_START_MASK	0x07FF
 #define RAMDISK_PROMPT_FLAG		0x8000
-- 
2.11.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 0/3] x86/boot: Introduce the kernel_info et consortes
  2019-07-04 16:36 [PATCH v2 0/3] x86/boot: Introduce the kernel_info et consortes Daniel Kiper
                   ` (2 preceding siblings ...)
  2019-07-04 16:36 ` [PATCH v2 3/3] x86/boot: Introduce the kernel_info.setup_type_max Daniel Kiper
@ 2019-07-12 11:58 ` Daniel Kiper
  3 siblings, 0 replies; 14+ messages in thread
From: Daniel Kiper @ 2019-07-12 11:58 UTC (permalink / raw)
  To: linux-doc, linux-kernel, x86
  Cc: bp, corbet, dpsmith, eric.snowberg, hpa, kanth.ghatraju,
	konrad.wilk, mingo, ross.philipson, tglx

On Thu, Jul 04, 2019 at 06:36:09PM +0200, Daniel Kiper wrote:
> Hi,
>
> Due to very limited space in the setup_header this patch series introduces new
> kernel_info struct which will be used to convey information from the kernel to
> the bootloader. This way the boot protocol can be extended regardless of the
> setup_header limitations. Additionally, the patch series introduces some
> convenience features like the setup_indirect struct and the
> kernel_info.setup_type_max field.

Ping?

Daniel

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 2/3] x86/boot: Introduce the setup_indirect
  2019-07-04 16:36 ` [PATCH v2 2/3] x86/boot: Introduce the setup_indirect Daniel Kiper
@ 2019-07-12 15:56   ` hpa
  2019-10-01 14:47     ` Daniel Kiper
  0 siblings, 1 reply; 14+ messages in thread
From: hpa @ 2019-07-12 15:56 UTC (permalink / raw)
  To: Daniel Kiper, linux-doc, linux-kernel, x86
  Cc: bp, corbet, dpsmith, eric.snowberg, kanth.ghatraju, konrad.wilk,
	mingo, ross.philipson, tglx

On July 4, 2019 9:36:11 AM PDT, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>The setup_data is a bit awkward to use for extremely large data
>objects,
>both because the setup_data header has to be adjacent to the data
>object
>and because it has a 32-bit length field. However, it is important that
>intermediate stages of the boot process have a way to identify which
>chunks of memory are occupied by kernel data.
>
>Thus we introduce a uniform way to specify such indirect data as
>setup_indirect struct and SETUP_INDIRECT type.
>
>This patch does not bump setup_header version in arch/x86/boot/header.S
>because it will be followed by additional changes coming into the
>Linux/x86 boot protocol.
>
>Suggested-by: H. Peter Anvin <hpa@zytor.com>
>Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com>
>Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
>---
>v2 - suggestions/fixes:
>   - add setup_indirect usage example
>     (suggested by Eric Snowberg and Ross Philipson).
>---
>Documentation/x86/boot.rst            | 38
>++++++++++++++++++++++++++++++++++-
> arch/x86/include/uapi/asm/bootparam.h | 11 +++++++++-
> 2 files changed, 47 insertions(+), 2 deletions(-)
>
>diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
>index a934a56f0516..23d3726d54fc 100644
>--- a/Documentation/x86/boot.rst
>+++ b/Documentation/x86/boot.rst
>@@ -73,7 +73,7 @@ Protocol 2.14:	BURNT BY INCORRECT COMMIT
>ae7e1238e68f2a472a125673ab506d49158c188
> 		(x86/boot: Add ACPI RSDP address to setup_header)
> 		DO NOT USE!!! ASSUME SAME AS 2.13.
> 
>-Protocol 2.15:	(Kernel 5.3) Added the kernel_info.
>+Protocol 2.15:	(Kernel 5.3) Added the kernel_info and setup_indirect.
>=============	============================================================
> 
> .. note::
>@@ -827,6 +827,42 @@ Protocol:	2.09+
>   sure to consider the case where the linked list already contains
>   entries.
> 
>+  The setup_data is a bit awkward to use for extremely large data
>objects,
>+  both because the setup_data header has to be adjacent to the data
>object
>+  and because it has a 32-bit length field. However, it is important
>that
>+  intermediate stages of the boot process have a way to identify which
>+  chunks of memory are occupied by kernel data.
>+
>+  Thus setup_indirect struct and SETUP_INDIRECT type were introduced
>in
>+  protocol 2.15.
>+  
>+  struct setup_indirect {
>+    __u32 type;
>+    __u32 reserved;  /* Reserved, must be set to zero. */
>+    __u64 len;
>+    __u64 addr;
>+  };
>+
>+  The type member is itself simply a SETUP_* type. However, it cannot
>be
>+  SETUP_INDIRECT since making the setup_indirect a tree structure
>could
>+  require a lot of stack space in something that needs to parse it and
>+  stack space can be limited in boot contexts.
>+
>+  Let's give an example how to point to SETUP_E820_EXT data using
>setup_indirect.
>+  In this case setup_data and setup_indirect will look like this:
>+
>+  struct setup_data {
>+    __u64 next = 0 or <addr_of_next_setup_data_struct>;
>+    __u32 type = SETUP_INDIRECT;
>+    __u32 len = sizeof(setup_data);
>+    __u8 data[sizeof(setup_indirect)] = struct setup_indirect {
>+      __u32 type = SETUP_E820_EXT;
>+      __u32 reserved = 0;
>+      __u64 len = <len_of_SETUP_E820_EXT_data>;
>+      __u64 addr = <addr_of_SETUP_E820_EXT_data>;
>+    }
>+  }
>+
> ============	============
> Field name:	pref_address
> Type:		read (reloc)
>diff --git a/arch/x86/include/uapi/asm/bootparam.h
>b/arch/x86/include/uapi/asm/bootparam.h
>index b05318112452..aaaa17fa6ad6 100644
>--- a/arch/x86/include/uapi/asm/bootparam.h
>+++ b/arch/x86/include/uapi/asm/bootparam.h
>@@ -2,7 +2,7 @@
> #ifndef _ASM_X86_BOOTPARAM_H
> #define _ASM_X86_BOOTPARAM_H
> 
>-/* setup_data types */
>+/* setup_data/setup_indirect types */
> #define SETUP_NONE			0
> #define SETUP_E820_EXT			1
> #define SETUP_DTB			2
>@@ -10,6 +10,7 @@
> #define SETUP_EFI			4
> #define SETUP_APPLE_PROPERTIES		5
> #define SETUP_JAILHOUSE			6
>+#define SETUP_INDIRECT			7
> 
> /* ram_size flags */
> #define RAMDISK_IMAGE_START_MASK	0x07FF
>@@ -47,6 +48,14 @@ struct setup_data {
> 	__u8 data[0];
> };
> 
>+/* extensible setup indirect data node */
>+struct setup_indirect {
>+	__u32 type;
>+	__u32 reserved;  /* Reserved, must be set to zero. */
>+	__u64 len;
>+	__u64 addr;
>+};
>+
> struct setup_header {
> 	__u8	setup_sects;
> 	__u16	root_flags;

This needs actual implementation; we can't advertise it until the kernel knows how to consume the data! It probably should be moved to after the 3/3 patch.

Implementing this has two parts:

1. The kernel needs to be augmented so it can find current objects via indirection.

2. And this is the main reason for this in the first place: the early code needs to walk the list and map out the memory areas which are occupied so it doesn't clobber anything; this allows this code to be generic as opposed to having to know what is a pointer and what size it might point to.

(The decompressor didn't need this until kaslr entered the picture, but now it does, sadly.)

Optional/future enhancements that might be nice:

3. Add some kind of description (e.g. foo=u64 ; bar=str ; baz=blob) to make it possible to write a bootloader that can load these kinds of objects without specific enabling.

4. Add support for mapping initramfs fragments  this way.

5. Add support for passingload-on-boot kernel modules.

6. ... ?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 3/3] x86/boot: Introduce the kernel_info.setup_type_max
  2019-07-04 16:36 ` [PATCH v2 3/3] x86/boot: Introduce the kernel_info.setup_type_max Daniel Kiper
@ 2019-07-12 15:59   ` hpa
  0 siblings, 0 replies; 14+ messages in thread
From: hpa @ 2019-07-12 15:59 UTC (permalink / raw)
  To: Daniel Kiper, linux-doc, linux-kernel, x86
  Cc: bp, corbet, dpsmith, eric.snowberg, kanth.ghatraju, konrad.wilk,
	mingo, ross.philipson, tglx

On July 4, 2019 9:36:12 AM PDT, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>This field contains maximal allowed type for setup_data and
>setup_indirect structs.
>
>And finally bump setup_header version in arch/x86/boot/header.S.
>
>Suggested-by: H. Peter Anvin <hpa@zytor.com>
>Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
>Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com>
>---
> Documentation/x86/boot.rst             | 10 +++++++++-
> arch/x86/boot/compressed/kernel_info.S |  4 ++++
> arch/x86/boot/header.S                 |  2 +-
> arch/x86/include/uapi/asm/bootparam.h  |  3 +++
> 4 files changed, 17 insertions(+), 2 deletions(-)
>
>diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
>index 23d3726d54fc..63609fd0517f 100644
>--- a/Documentation/x86/boot.rst
>+++ b/Documentation/x86/boot.rst
>@@ -73,7 +73,8 @@ Protocol 2.14:	BURNT BY INCORRECT COMMIT
>ae7e1238e68f2a472a125673ab506d49158c188
> 		(x86/boot: Add ACPI RSDP address to setup_header)
> 		DO NOT USE!!! ASSUME SAME AS 2.13.
> 
>-Protocol 2.15:	(Kernel 5.3) Added the kernel_info and setup_indirect.
>+Protocol 2.15:	(Kernel 5.3) Added the kernel_info,
>kernel_info.setup_type_max
>+		and setup_indirect.
>=============	============================================================
> 
> .. note::
>@@ -980,6 +981,13 @@ Offset/size:	0x0004/4
>This field contains the size of the kernel_info including
>kernel_info.header.
>It should be used by the boot loader to detect supported fields in the
>kernel_info.
> 
>+============	==============
>+Field name:	setup_type_max
>+Offset/size:	0x0008/4
>+============	==============
>+
>+  This field contains maximal allowed type for setup_data and
>setup_indirect structs.
>+
> 
> The Image Checksum
> ==================
>diff --git a/arch/x86/boot/compressed/kernel_info.S
>b/arch/x86/boot/compressed/kernel_info.S
>index 3f1cb301b9ff..2f28aabf6558 100644
>--- a/arch/x86/boot/compressed/kernel_info.S
>+++ b/arch/x86/boot/compressed/kernel_info.S
>@@ -1,5 +1,7 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> 
>+#include <asm/bootparam.h>
>+
> 	.section ".rodata.kernel_info", "a"
> 
> 	.global kernel_info
>@@ -9,4 +11,6 @@ kernel_info:
> 	.ascii	"InfO"
>         /* Size. */
> 	.long	kernel_info_end - kernel_info
>+        /* Maximal allowed type for setup_data and setup_indirect
>structs. */
>+	.long	SETUP_TYPE_MAX
> kernel_info_end:
>diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
>index ec6a25a43148..893a456663ab 100644
>--- a/arch/x86/boot/header.S
>+++ b/arch/x86/boot/header.S
>@@ -300,7 +300,7 @@ _start:
> 	# Part 2 of the header, from the old setup.S
> 
> 		.ascii	"HdrS"		# header signature
>-		.word	0x020d		# header version number (>= 0x0105)
>+		.word	0x020f		# header version number (>= 0x0105)
> 					# or else old loadlin-1.5 will fail)
> 		.globl realmode_swtch
> realmode_swtch:	.word	0, 0		# default_switch, SETUPSEG
>diff --git a/arch/x86/include/uapi/asm/bootparam.h
>b/arch/x86/include/uapi/asm/bootparam.h
>index aaaa17fa6ad6..2ba870dae6f3 100644
>--- a/arch/x86/include/uapi/asm/bootparam.h
>+++ b/arch/x86/include/uapi/asm/bootparam.h
>@@ -12,6 +12,9 @@
> #define SETUP_JAILHOUSE			6
> #define SETUP_INDIRECT			7
> 
>+/* max(SETUP_*) */
>+#define SETUP_TYPE_MAX			SETUP_INDIRECT
>+
> /* ram_size flags */
> #define RAMDISK_IMAGE_START_MASK	0x07FF
> #define RAMDISK_PROMPT_FLAG		0x8000

Bump the version number and add setup_max before adding the indirect stuff. That will nicely double as at the very least a first-order validity check.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 1/3] x86/boot: Introduce the kernel_info
  2019-07-04 16:36 ` [PATCH v2 1/3] x86/boot: Introduce the kernel_info Daniel Kiper
@ 2019-07-12 16:04   ` hpa
  2019-09-30 15:01     ` Daniel Kiper
  0 siblings, 1 reply; 14+ messages in thread
From: hpa @ 2019-07-12 16:04 UTC (permalink / raw)
  To: Daniel Kiper, linux-doc, linux-kernel, x86
  Cc: bp, corbet, dpsmith, eric.snowberg, kanth.ghatraju, konrad.wilk,
	mingo, ross.philipson, tglx

On July 4, 2019 9:36:10 AM PDT, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>The relationships between the headers are analogous to the various data
>sections:
>
>  setup_header = .data
>  boot_params/setup_data = .bss
>
>What is missing from the above list? That's right:
>
>  kernel_info = .rodata
>
>We have been (ab)using .data for things that could go into .rodata or
>.bss for
>a long time, for lack of alternatives and -- especially early on --
>inertia.
>Also, the BIOS stub is responsible for creating boot_params, so it
>isn't
>available to a BIOS-based loader (setup_data is, though).
>
>setup_header is permanently limited to 144 bytes due to the reach of
>the
>2-byte jump field, which doubles as a length field for the structure,
>combined
>with the size of the "hole" in struct boot_params that a protected-mode
>loader
>or the BIOS stub has to copy it into. It is currently 119 bytes long,
>which
>leaves us with 25 very precious bytes. This isn't something that can be
>fixed
>without revising the boot protocol entirely, breaking backwards
>compatibility.
>
>boot_params proper is limited to 4096 bytes, but can be arbitrarily
>extended
>by adding setup_data entries. It cannot be used to communicate
>properties of
>the kernel image, because it is .bss and has no image-provided content.
>
>kernel_info solves this by providing an extensible place for
>information about
>the kernel image. It is readonly, because the kernel cannot rely on a
>bootloader copying its contents anywhere, but that is OK; if it becomes
>necessary it can still contain data items that an enabled bootloader
>would be
>expected to copy into a setup_data chunk.
>
>This patch does not bump setup_header version in arch/x86/boot/header.S
>because it will be followed by additional changes coming into the
>Linux/x86 boot protocol.
>
>Suggested-by: H. Peter Anvin <hpa@zytor.com>
>Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com>
>Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
>---
>v2 - suggestions/fixes:
>   - rename setup_header2 to kernel_info,
>     (suggested by H. Peter Anvin),
>   - change kernel_info.header value to "InfO" (0x4f666e49),
>   - new kernel_info description in Documentation/x86/boot.rst,
>     (suggested by H. Peter Anvin),
>   - drop kernel_info_offset_update() as an overkill and
>     update kernel_info offset directly from main(),
>     (suggested by Eric Snowberg),
>   - new commit message
>     (suggested by H. Peter Anvin),
>   - fix some commit message misspellings
>     (suggested by Eric Snowberg).
>---
>Documentation/x86/boot.rst             | 89
>++++++++++++++++++++++++++++++++++
> arch/x86/boot/Makefile                 |  2 +-
> arch/x86/boot/compressed/Makefile      |  4 +-
> arch/x86/boot/compressed/kernel_info.S | 12 +++++
> arch/x86/boot/header.S                 |  1 +
> arch/x86/boot/tools/build.c            |  5 ++
> arch/x86/include/uapi/asm/bootparam.h  |  1 +
> 7 files changed, 111 insertions(+), 3 deletions(-)
> create mode 100644 arch/x86/boot/compressed/kernel_info.S
>
>diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
>index 08a2f100c0e6..a934a56f0516 100644
>--- a/Documentation/x86/boot.rst
>+++ b/Documentation/x86/boot.rst
>@@ -68,8 +68,25 @@ Protocol 2.12	(Kernel 3.8) Added the xloadflags
>field and extension fields
> Protocol 2.13	(Kernel 3.14) Support 32- and 64-bit flags being set in
> 		xloadflags to support booting a 64-bit kernel from 32-bit
> 		EFI
>+
>+Protocol 2.14:	BURNT BY INCORRECT COMMIT
>ae7e1238e68f2a472a125673ab506d49158c1889
>+		(x86/boot: Add ACPI RSDP address to setup_header)
>+		DO NOT USE!!! ASSUME SAME AS 2.13.
>+
>+Protocol 2.15:	(Kernel 5.3) Added the kernel_info.
>=============	============================================================
> 
>+.. note::
>+     The protocol version number should be changed only if the setup
>header
>+     is changed. There is no need to update the version number if
>boot_params
>+     or kernel_info are changed. Additionally, it is recommended to
>use
>+     xloadflags (in this case the protocol version number should not
>be
>+     updated either) or kernel_info to communicate supported Linux
>kernel
>+     features to the boot loader. Due to very limited space available
>in
>+     the original setup header every update to it should be considered
>+     with great care. Starting from the protocol 2.15 the primary way
>to
>+     communicate things to the boot loader is the kernel_info.
>+
> 
> Memory Layout
> =============
>@@ -207,6 +224,7 @@ Offset/Size	Proto		Name			Meaning
> 0258/8		2.10+		pref_address		Preferred loading address
> 0260/4		2.10+		init_size		Linear memory required during initialization
> 0264/4		2.11+		handover_offset		Offset of handover entry point
>+0268/4		2.15+		kernel_info_offset	Offset of the kernel_info
>===========	========	=====================	============================================
> 
> .. note::
>@@ -855,6 +873,77 @@ Offset/size:	0x264/4
> 
>   See EFI HANDOVER PROTOCOL below for more details.
> 
>+============	==================
>+Field name:	kernel_info_offset
>+Type:		read
>+Offset/size:	0x268/4
>+Protocol:	2.15+
>+============	==================
>+
>+  This field is the offset from the beginning of the kernel image to
>the
>+  kernel_info. It is embedded in the Linux image in the uncompressed
>+  protected mode region.
>+
>+
>+The kernel_info
>+===============
>+
>+The relationships between the headers are analogous to the various
>data
>+sections:
>+
>+  setup_header = .data
>+  boot_params/setup_data = .bss
>+
>+What is missing from the above list? That's right:
>+
>+  kernel_info = .rodata
>+
>+We have been (ab)using .data for things that could go into .rodata or
>.bss for
>+a long time, for lack of alternatives and -- especially early on --
>inertia.
>+Also, the BIOS stub is responsible for creating boot_params, so it
>isn't
>+available to a BIOS-based loader (setup_data is, though).
>+
>+setup_header is permanently limited to 144 bytes due to the reach of
>the
>+2-byte jump field, which doubles as a length field for the structure,
>combined
>+with the size of the "hole" in struct boot_params that a
>protected-mode loader
>+or the BIOS stub has to copy it into. It is currently 119 bytes long,
>which
>+leaves us with 25 very precious bytes. This isn't something that can
>be fixed
>+without revising the boot protocol entirely, breaking backwards
>compatibility.
>+
>+boot_params proper is limited to 4096 bytes, but can be arbitrarily
>extended
>+by adding setup_data entries. It cannot be used to communicate
>properties of
>+the kernel image, because it is .bss and has no image-provided
>content.
>+
>+kernel_info solves this by providing an extensible place for
>information about
>+the kernel image. It is readonly, because the kernel cannot rely on a
>+bootloader copying its contents anywhere, but that is OK; if it
>becomes
>+necessary it can still contain data items that an enabled bootloader
>would be
>+expected to copy into a setup_data chunk.
>+
>+It is recommended to not store large data chunks, e.g. strings,
>directly in the
>+kernel_info struct. Such data should be placed outside of it and
>pointed from
>+the kernel_info structure using offsets from the beginning of the
>structure,
>+the kernel_info.header field.
>+
>+
>+Details of the kernel_info Fields
>+=================================
>+
>+============	========
>+Field name:	header
>+Offset/size:	0x0000/4
>+============	========
>+
>+  Contains the magic number "InfO" (0x4f666e49).
>+
>+============	========
>+Field name:	size
>+Offset/size:	0x0004/4
>+============	========
>+
>+  This field contains the size of the kernel_info including
>kernel_info.header.
>+  It should be used by the boot loader to detect supported fields in
>the kernel_info.
>+
> 
> The Image Checksum
> ==================
>diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
>index e2839b5c246c..c30a9b642a86 100644
>--- a/arch/x86/boot/Makefile
>+++ b/arch/x86/boot/Makefile
>@@ -87,7 +87,7 @@ $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE
> 
> SETUP_OBJS = $(addprefix $(obj)/,$(setup-y))
> 
>-sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW]
>\(startup_32\|startup_64\|efi32_stub_entry\|efi64_stub_entry\|efi_pe_entry\|input_data\|_end\|_ehead\|_text\|z_.*\)$$/\#define
>ZO_\2 0x\1/p'
>+sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW]
>\(startup_32\|startup_64\|efi32_stub_entry\|efi64_stub_entry\|efi_pe_entry\|input_data\|kernel_info\|_end\|_ehead\|_text\|z_.*\)$$/\#define
>ZO_\2 0x\1/p'
> 
> quiet_cmd_zoffset = ZOFFSET $@
>       cmd_zoffset = $(NM) $< | sed -n $(sed-zoffset) > $@
>diff --git a/arch/x86/boot/compressed/Makefile
>b/arch/x86/boot/compressed/Makefile
>index 6b84afdd7538..fad3b18e2cc3 100644
>--- a/arch/x86/boot/compressed/Makefile
>+++ b/arch/x86/boot/compressed/Makefile
>@@ -72,8 +72,8 @@ $(obj)/../voffset.h: vmlinux FORCE
> 
> $(obj)/misc.o: $(obj)/../voffset.h
> 
>-vmlinux-objs-y := $(obj)/vmlinux.lds $(obj)/head_$(BITS).o
>$(obj)/misc.o \
>-	$(obj)/string.o $(obj)/cmdline.o $(obj)/error.o \
>+vmlinux-objs-y := $(obj)/vmlinux.lds $(obj)/kernel_info.o
>$(obj)/head_$(BITS).o \
>+	$(obj)/misc.o $(obj)/string.o $(obj)/cmdline.o $(obj)/error.o \
> 	$(obj)/piggy.o $(obj)/cpuflags.o
> 
> vmlinux-objs-$(CONFIG_EARLY_PRINTK) += $(obj)/early_serial_console.o
>diff --git a/arch/x86/boot/compressed/kernel_info.S
>b/arch/x86/boot/compressed/kernel_info.S
>new file mode 100644
>index 000000000000..3f1cb301b9ff
>--- /dev/null
>+++ b/arch/x86/boot/compressed/kernel_info.S
>@@ -0,0 +1,12 @@
>+/* SPDX-License-Identifier: GPL-2.0 */
>+
>+	.section ".rodata.kernel_info", "a"
>+
>+	.global kernel_info
>+
>+kernel_info:
>+        /* Header. */
>+	.ascii	"InfO"
>+        /* Size. */
>+	.long	kernel_info_end - kernel_info
>+kernel_info_end:
>diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
>index 850b8762e889..ec6a25a43148 100644
>--- a/arch/x86/boot/header.S
>+++ b/arch/x86/boot/header.S
>@@ -557,6 +557,7 @@ pref_address:		.quad LOAD_PHYSICAL_ADDR	# preferred
>load addr
> 
> init_size:		.long INIT_SIZE		# kernel initialization size
> handover_offset:	.long 0			# Filled in by build.c
>+kernel_info_offset:	.long 0			# Filled in by build.c
> 
># End of setup header
>#####################################################
> 
>diff --git a/arch/x86/boot/tools/build.c b/arch/x86/boot/tools/build.c
>index a93d44e58f9c..55e669d29e54 100644
>--- a/arch/x86/boot/tools/build.c
>+++ b/arch/x86/boot/tools/build.c
>@@ -56,6 +56,7 @@ u8 buf[SETUP_SECT_MAX*512];
> unsigned long efi32_stub_entry;
> unsigned long efi64_stub_entry;
> unsigned long efi_pe_entry;
>+unsigned long kernel_info;
> unsigned long startup_64;
> 
>/*----------------------------------------------------------------------*/
>@@ -321,6 +322,7 @@ static void parse_zoffset(char *fname)
> 		PARSE_ZOFS(p, efi32_stub_entry);
> 		PARSE_ZOFS(p, efi64_stub_entry);
> 		PARSE_ZOFS(p, efi_pe_entry);
>+		PARSE_ZOFS(p, kernel_info);
> 		PARSE_ZOFS(p, startup_64);
> 
> 		p = strchr(p, '\n');
>@@ -410,6 +412,9 @@ int main(int argc, char ** argv)
> 
> 	efi_stub_entry_update();
> 
>+	/* Update kernel_info offset. */
>+	put_unaligned_le32(kernel_info, &buf[0x268]);
>+
> 	crc = partial_crc32(buf, i, crc);
> 	if (fwrite(buf, 1, i, dest) != i)
> 		die("Writing setup failed");
>diff --git a/arch/x86/include/uapi/asm/bootparam.h
>b/arch/x86/include/uapi/asm/bootparam.h
>index 60733f137e9a..b05318112452 100644
>--- a/arch/x86/include/uapi/asm/bootparam.h
>+++ b/arch/x86/include/uapi/asm/bootparam.h
>@@ -86,6 +86,7 @@ struct setup_header {
> 	__u64	pref_address;
> 	__u32	init_size;
> 	__u32	handover_offset;
>+	__u32	kernel_info_offset;
> } __attribute__((packed));
> 
> struct sys_desc_table {

I should like to make make things a bit more stringent: additional data should be made offsets from the kernel_info structure *and they should live in the .rodata.kernel_info section*. We should add a size field for the entire .kernel_info section, thus ensuring it is a single self-contained blob.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 1/3] x86/boot: Introduce the kernel_info
  2019-07-12 16:04   ` hpa
@ 2019-09-30 15:01     ` Daniel Kiper
  2019-09-30 17:18       ` H. Peter Anvin
  0 siblings, 1 reply; 14+ messages in thread
From: Daniel Kiper @ 2019-09-30 15:01 UTC (permalink / raw)
  To: hpa
  Cc: linux-doc, linux-kernel, x86, bp, corbet, dpsmith, eric.snowberg,
	kanth.ghatraju, konrad.wilk, mingo, ross.philipson, tglx

On Fri, Jul 12, 2019 at 09:04:23AM -0700, hpa@zytor.com wrote:
> On July 4, 2019 9:36:10 AM PDT, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> >The relationships between the headers are analogous to the various data
> >sections:
> >
> >  setup_header = .data
> >  boot_params/setup_data = .bss
> >
> >What is missing from the above list? That's right:
> >
> >  kernel_info = .rodata
> >
> >We have been (ab)using .data for things that could go into .rodata or
> >.bss for
> >a long time, for lack of alternatives and -- especially early on --
> >inertia.
> >Also, the BIOS stub is responsible for creating boot_params, so it
> >isn't
> >available to a BIOS-based loader (setup_data is, though).
> >
> >setup_header is permanently limited to 144 bytes due to the reach of
> >the
> >2-byte jump field, which doubles as a length field for the structure,
> >combined
> >with the size of the "hole" in struct boot_params that a protected-mode
> >loader
> >or the BIOS stub has to copy it into. It is currently 119 bytes long,
> >which
> >leaves us with 25 very precious bytes. This isn't something that can be
> >fixed
> >without revising the boot protocol entirely, breaking backwards
> >compatibility.
> >
> >boot_params proper is limited to 4096 bytes, but can be arbitrarily
> >extended
> >by adding setup_data entries. It cannot be used to communicate
> >properties of
> >the kernel image, because it is .bss and has no image-provided content.
> >
> >kernel_info solves this by providing an extensible place for
> >information about
> >the kernel image. It is readonly, because the kernel cannot rely on a
> >bootloader copying its contents anywhere, but that is OK; if it becomes
> >necessary it can still contain data items that an enabled bootloader
> >would be
> >expected to copy into a setup_data chunk.
> >
> >This patch does not bump setup_header version in arch/x86/boot/header.S
> >because it will be followed by additional changes coming into the
> >Linux/x86 boot protocol.
> >
> >Suggested-by: H. Peter Anvin <hpa@zytor.com>
> >Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> >Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com>
> >Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
> >---
> >v2 - suggestions/fixes:
> >   - rename setup_header2 to kernel_info,
> >     (suggested by H. Peter Anvin),
> >   - change kernel_info.header value to "InfO" (0x4f666e49),
> >   - new kernel_info description in Documentation/x86/boot.rst,
> >     (suggested by H. Peter Anvin),
> >   - drop kernel_info_offset_update() as an overkill and
> >     update kernel_info offset directly from main(),
> >     (suggested by Eric Snowberg),
> >   - new commit message
> >     (suggested by H. Peter Anvin),
> >   - fix some commit message misspellings
> >     (suggested by Eric Snowberg).
> >---
> >Documentation/x86/boot.rst             | 89
> >++++++++++++++++++++++++++++++++++
> > arch/x86/boot/Makefile                 |  2 +-
> > arch/x86/boot/compressed/Makefile      |  4 +-
> > arch/x86/boot/compressed/kernel_info.S | 12 +++++
> > arch/x86/boot/header.S                 |  1 +
> > arch/x86/boot/tools/build.c            |  5 ++
> > arch/x86/include/uapi/asm/bootparam.h  |  1 +
> > 7 files changed, 111 insertions(+), 3 deletions(-)
> > create mode 100644 arch/x86/boot/compressed/kernel_info.S
> >
> >diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
> >index 08a2f100c0e6..a934a56f0516 100644
> >--- a/Documentation/x86/boot.rst
> >+++ b/Documentation/x86/boot.rst
> >@@ -68,8 +68,25 @@ Protocol 2.12	(Kernel 3.8) Added the xloadflags
> >field and extension fields
> > Protocol 2.13	(Kernel 3.14) Support 32- and 64-bit flags being set in
> > 		xloadflags to support booting a 64-bit kernel from 32-bit
> > 		EFI
> >+
> >+Protocol 2.14:	BURNT BY INCORRECT COMMIT
> >ae7e1238e68f2a472a125673ab506d49158c1889
> >+		(x86/boot: Add ACPI RSDP address to setup_header)
> >+		DO NOT USE!!! ASSUME SAME AS 2.13.
> >+
> >+Protocol 2.15:	(Kernel 5.3) Added the kernel_info.
> >=============	============================================================
> >
> >+.. note::
> >+     The protocol version number should be changed only if the setup
> >header
> >+     is changed. There is no need to update the version number if
> >boot_params
> >+     or kernel_info are changed. Additionally, it is recommended to
> >use
> >+     xloadflags (in this case the protocol version number should not
> >be
> >+     updated either) or kernel_info to communicate supported Linux
> >kernel
> >+     features to the boot loader. Due to very limited space available
> >in
> >+     the original setup header every update to it should be considered
> >+     with great care. Starting from the protocol 2.15 the primary way
> >to
> >+     communicate things to the boot loader is the kernel_info.
> >+
> >
> > Memory Layout
> > =============
> >@@ -207,6 +224,7 @@ Offset/Size	Proto		Name			Meaning
> > 0258/8		2.10+		pref_address		Preferred loading address
> > 0260/4		2.10+		init_size		Linear memory required during initialization
> > 0264/4		2.11+		handover_offset		Offset of handover entry point
> >+0268/4		2.15+		kernel_info_offset	Offset of the kernel_info
> >===========	========	=====================	============================================
> >
> > .. note::
> >@@ -855,6 +873,77 @@ Offset/size:	0x264/4
> >
> >   See EFI HANDOVER PROTOCOL below for more details.
> >
> >+============	==================
> >+Field name:	kernel_info_offset
> >+Type:		read
> >+Offset/size:	0x268/4
> >+Protocol:	2.15+
> >+============	==================
> >+
> >+  This field is the offset from the beginning of the kernel image to
> >the
> >+  kernel_info. It is embedded in the Linux image in the uncompressed
> >+  protected mode region.
> >+
> >+
> >+The kernel_info
> >+===============
> >+
> >+The relationships between the headers are analogous to the various
> >data
> >+sections:
> >+
> >+  setup_header = .data
> >+  boot_params/setup_data = .bss
> >+
> >+What is missing from the above list? That's right:
> >+
> >+  kernel_info = .rodata
> >+
> >+We have been (ab)using .data for things that could go into .rodata or
> >.bss for
> >+a long time, for lack of alternatives and -- especially early on --
> >inertia.
> >+Also, the BIOS stub is responsible for creating boot_params, so it
> >isn't
> >+available to a BIOS-based loader (setup_data is, though).
> >+
> >+setup_header is permanently limited to 144 bytes due to the reach of
> >the
> >+2-byte jump field, which doubles as a length field for the structure,
> >combined
> >+with the size of the "hole" in struct boot_params that a
> >protected-mode loader
> >+or the BIOS stub has to copy it into. It is currently 119 bytes long,
> >which
> >+leaves us with 25 very precious bytes. This isn't something that can
> >be fixed
> >+without revising the boot protocol entirely, breaking backwards
> >compatibility.
> >+
> >+boot_params proper is limited to 4096 bytes, but can be arbitrarily
> >extended
> >+by adding setup_data entries. It cannot be used to communicate
> >properties of
> >+the kernel image, because it is .bss and has no image-provided
> >content.
> >+
> >+kernel_info solves this by providing an extensible place for
> >information about
> >+the kernel image. It is readonly, because the kernel cannot rely on a
> >+bootloader copying its contents anywhere, but that is OK; if it
> >becomes
> >+necessary it can still contain data items that an enabled bootloader
> >would be
> >+expected to copy into a setup_data chunk.
> >+
> >+It is recommended to not store large data chunks, e.g. strings,
> >directly in the
> >+kernel_info struct. Such data should be placed outside of it and
> >pointed from
> >+the kernel_info structure using offsets from the beginning of the
> >structure,
> >+the kernel_info.header field.
> >+
> >+
> >+Details of the kernel_info Fields
> >+=================================
> >+
> >+============	========
> >+Field name:	header
> >+Offset/size:	0x0000/4
> >+============	========
> >+
> >+  Contains the magic number "InfO" (0x4f666e49).
> >+
> >+============	========
> >+Field name:	size
> >+Offset/size:	0x0004/4
> >+============	========
> >+
> >+  This field contains the size of the kernel_info including
> >kernel_info.header.
> >+  It should be used by the boot loader to detect supported fields in
> >the kernel_info.
> >+
> >
> > The Image Checksum
> > ==================
> >diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
> >index e2839b5c246c..c30a9b642a86 100644
> >--- a/arch/x86/boot/Makefile
> >+++ b/arch/x86/boot/Makefile
> >@@ -87,7 +87,7 @@ $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE
> >
> > SETUP_OBJS = $(addprefix $(obj)/,$(setup-y))
> >
> >-sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW]
> >\(startup_32\|startup_64\|efi32_stub_entry\|efi64_stub_entry\|efi_pe_entry\|input_data\|_end\|_ehead\|_text\|z_.*\)$$/\#define
> >ZO_\2 0x\1/p'
> >+sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW]
> >\(startup_32\|startup_64\|efi32_stub_entry\|efi64_stub_entry\|efi_pe_entry\|input_data\|kernel_info\|_end\|_ehead\|_text\|z_.*\)$$/\#define
> >ZO_\2 0x\1/p'
> >
> > quiet_cmd_zoffset = ZOFFSET $@
> >       cmd_zoffset = $(NM) $< | sed -n $(sed-zoffset) > $@
> >diff --git a/arch/x86/boot/compressed/Makefile
> >b/arch/x86/boot/compressed/Makefile
> >index 6b84afdd7538..fad3b18e2cc3 100644
> >--- a/arch/x86/boot/compressed/Makefile
> >+++ b/arch/x86/boot/compressed/Makefile
> >@@ -72,8 +72,8 @@ $(obj)/../voffset.h: vmlinux FORCE
> >
> > $(obj)/misc.o: $(obj)/../voffset.h
> >
> >-vmlinux-objs-y := $(obj)/vmlinux.lds $(obj)/head_$(BITS).o
> >$(obj)/misc.o \
> >-	$(obj)/string.o $(obj)/cmdline.o $(obj)/error.o \
> >+vmlinux-objs-y := $(obj)/vmlinux.lds $(obj)/kernel_info.o
> >$(obj)/head_$(BITS).o \
> >+	$(obj)/misc.o $(obj)/string.o $(obj)/cmdline.o $(obj)/error.o \
> > 	$(obj)/piggy.o $(obj)/cpuflags.o
> >
> > vmlinux-objs-$(CONFIG_EARLY_PRINTK) += $(obj)/early_serial_console.o
> >diff --git a/arch/x86/boot/compressed/kernel_info.S
> >b/arch/x86/boot/compressed/kernel_info.S
> >new file mode 100644
> >index 000000000000..3f1cb301b9ff
> >--- /dev/null
> >+++ b/arch/x86/boot/compressed/kernel_info.S
> >@@ -0,0 +1,12 @@
> >+/* SPDX-License-Identifier: GPL-2.0 */
> >+
> >+	.section ".rodata.kernel_info", "a"
> >+
> >+	.global kernel_info
> >+
> >+kernel_info:
> >+        /* Header. */
> >+	.ascii	"InfO"
> >+        /* Size. */
> >+	.long	kernel_info_end - kernel_info
> >+kernel_info_end:
> >diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> >index 850b8762e889..ec6a25a43148 100644
> >--- a/arch/x86/boot/header.S
> >+++ b/arch/x86/boot/header.S
> >@@ -557,6 +557,7 @@ pref_address:		.quad LOAD_PHYSICAL_ADDR	# preferred
> >load addr
> >
> > init_size:		.long INIT_SIZE		# kernel initialization size
> > handover_offset:	.long 0			# Filled in by build.c
> >+kernel_info_offset:	.long 0			# Filled in by build.c
> >
> ># End of setup header
> >#####################################################
> >
> >diff --git a/arch/x86/boot/tools/build.c b/arch/x86/boot/tools/build.c
> >index a93d44e58f9c..55e669d29e54 100644
> >--- a/arch/x86/boot/tools/build.c
> >+++ b/arch/x86/boot/tools/build.c
> >@@ -56,6 +56,7 @@ u8 buf[SETUP_SECT_MAX*512];
> > unsigned long efi32_stub_entry;
> > unsigned long efi64_stub_entry;
> > unsigned long efi_pe_entry;
> >+unsigned long kernel_info;
> > unsigned long startup_64;
> >
> >/*----------------------------------------------------------------------*/
> >@@ -321,6 +322,7 @@ static void parse_zoffset(char *fname)
> > 		PARSE_ZOFS(p, efi32_stub_entry);
> > 		PARSE_ZOFS(p, efi64_stub_entry);
> > 		PARSE_ZOFS(p, efi_pe_entry);
> >+		PARSE_ZOFS(p, kernel_info);
> > 		PARSE_ZOFS(p, startup_64);
> >
> > 		p = strchr(p, '\n');
> >@@ -410,6 +412,9 @@ int main(int argc, char ** argv)
> >
> > 	efi_stub_entry_update();
> >
> >+	/* Update kernel_info offset. */
> >+	put_unaligned_le32(kernel_info, &buf[0x268]);
> >+
> > 	crc = partial_crc32(buf, i, crc);
> > 	if (fwrite(buf, 1, i, dest) != i)
> > 		die("Writing setup failed");
> >diff --git a/arch/x86/include/uapi/asm/bootparam.h
> >b/arch/x86/include/uapi/asm/bootparam.h
> >index 60733f137e9a..b05318112452 100644
> >--- a/arch/x86/include/uapi/asm/bootparam.h
> >+++ b/arch/x86/include/uapi/asm/bootparam.h
> >@@ -86,6 +86,7 @@ struct setup_header {
> > 	__u64	pref_address;
> > 	__u32	init_size;
> > 	__u32	handover_offset;
> >+	__u32	kernel_info_offset;
> > } __attribute__((packed));
> >
> > struct sys_desc_table {
>
> I should like to make make things a bit more stringent: additional
> data should be made offsets from the kernel_info structure *and they
> should live in the .rodata.kernel_info section*. We should add a size

OK.

> field for the entire .kernel_info section, thus ensuring it is a
> single self-contained blob.

.rodata.kernel_info contains its total size immediately behind the
"InfO" header. Do you suggest that we should add the size of
.rodata.kernel_info into setup_header too?

Daniel

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 1/3] x86/boot: Introduce the kernel_info
  2019-09-30 15:01     ` Daniel Kiper
@ 2019-09-30 17:18       ` H. Peter Anvin
  2019-10-01 11:41         ` Daniel Kiper
  0 siblings, 1 reply; 14+ messages in thread
From: H. Peter Anvin @ 2019-09-30 17:18 UTC (permalink / raw)
  To: Daniel Kiper
  Cc: linux-doc, linux-kernel, x86, bp, corbet, dpsmith, eric.snowberg,
	kanth.ghatraju, konrad.wilk, mingo, ross.philipson, tglx

On 2019-09-30 08:01, Daniel Kiper wrote:
> 
> OK.
> 
>> field for the entire .kernel_info section, thus ensuring it is a
>> single self-contained blob.
> 
> .rodata.kernel_info contains its total size immediately behind the
> "InfO" header. Do you suggest that we should add the size of
> .rodata.kernel_info into setup_header too?
> 

No, what I want is a chunked architecture for kernel_info.

That is:

/* Common chunk header */
struct kernel_info_header {
	uint32_t magic;
	uint32_t len;
};

/* Top-level chunk, always first */
#define KERNEL_INFO_MAGIC 0x45fdbe4f

struct kernel_info {
	struct kernel_info_header hdr;
	uint32_t total_size;		/* Total size of all chunks */

	/* Various fixed-sized data objects, OR offsets to other chunks */
};

Also "InfO" is a pretty hideous magic. In general, all-ASCII magics have much
higher risk of collision than *RANDOM* binary numbers. However, for a chunked
architecture they do have the advantage that they can be used also as a human
name or file name for the chunk, e.,g. in sysfs, so maybe something like
"LnuX" or even "LToP" for the top-level chunk might make sense.

How does that sound?

	-hpa


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 1/3] x86/boot: Introduce the kernel_info
  2019-09-30 17:18       ` H. Peter Anvin
@ 2019-10-01 11:41         ` Daniel Kiper
  2019-10-01 22:28           ` H. Peter Anvin
  0 siblings, 1 reply; 14+ messages in thread
From: Daniel Kiper @ 2019-10-01 11:41 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: linux-doc, linux-kernel, x86, bp, corbet, dpsmith, eric.snowberg,
	kanth.ghatraju, konrad.wilk, mingo, ross.philipson, tglx

On Mon, Sep 30, 2019 at 10:18:43AM -0700, H. Peter Anvin wrote:
> On 2019-09-30 08:01, Daniel Kiper wrote:
> >
> > OK.
> >
> >> field for the entire .kernel_info section, thus ensuring it is a
> >> single self-contained blob.
> >
> > .rodata.kernel_info contains its total size immediately behind the
> > "InfO" header. Do you suggest that we should add the size of
> > .rodata.kernel_info into setup_header too?
> >
>
> No, what I want is a chunked architecture for kernel_info.
>
> That is:
>
> /* Common chunk header */
> struct kernel_info_header {
> 	uint32_t magic;
> 	uint32_t len;
> };
>
> /* Top-level chunk, always first */
> #define KERNEL_INFO_MAGIC 0x45fdbe4f
>
> struct kernel_info {
> 	struct kernel_info_header hdr;
> 	uint32_t total_size;		/* Total size of all chunks */
>
> 	/* Various fixed-sized data objects, OR offsets to other chunks */
> };

OK, so, this is more or less what I had in my v3 patch before sending
this email. So, it looks that I am on good track. Great! Though I am not
sure that we should have magic for chunked objects. If yes could you
explain why? I would just leave len for chunked objects.

> Also "InfO" is a pretty hideous magic. In general, all-ASCII magics have much
> higher risk of collision than *RANDOM* binary numbers. However, for a chunked
> architecture they do have the advantage that they can be used also as a human
> name or file name for the chunk, e.,g. in sysfs, so maybe something like
> "LnuX" or even "LToP" for the top-level chunk might make sense.
>
> How does that sound?

Well, your proposals are more cryptic, especially the second one, than
mine but I tend to agree that more *RANDOM* magics are better. So,
I would choose "LToP" if you decipher it for me. Linux Top?

Daniel

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 2/3] x86/boot: Introduce the setup_indirect
  2019-07-12 15:56   ` hpa
@ 2019-10-01 14:47     ` Daniel Kiper
  0 siblings, 0 replies; 14+ messages in thread
From: Daniel Kiper @ 2019-10-01 14:47 UTC (permalink / raw)
  To: hpa
  Cc: linux-doc, linux-kernel, x86, bp, corbet, dpsmith, eric.snowberg,
	kanth.ghatraju, konrad.wilk, mingo, ross.philipson, tglx

On Fri, Jul 12, 2019 at 08:56:44AM -0700, hpa@zytor.com wrote:
> On July 4, 2019 9:36:11 AM PDT, Daniel Kiper <daniel.kiper@oracle.com> wrote:

[...]

> >diff --git a/arch/x86/include/uapi/asm/bootparam.h
> >b/arch/x86/include/uapi/asm/bootparam.h
> >index b05318112452..aaaa17fa6ad6 100644
> >--- a/arch/x86/include/uapi/asm/bootparam.h
> >+++ b/arch/x86/include/uapi/asm/bootparam.h
> >@@ -2,7 +2,7 @@
> > #ifndef _ASM_X86_BOOTPARAM_H
> > #define _ASM_X86_BOOTPARAM_H
> >
> >-/* setup_data types */
> >+/* setup_data/setup_indirect types */
> > #define SETUP_NONE			0
> > #define SETUP_E820_EXT			1
> > #define SETUP_DTB			2
> >@@ -10,6 +10,7 @@
> > #define SETUP_EFI			4
> > #define SETUP_APPLE_PROPERTIES		5
> > #define SETUP_JAILHOUSE			6
> >+#define SETUP_INDIRECT			7
> >
> > /* ram_size flags */
> > #define RAMDISK_IMAGE_START_MASK	0x07FF
> >@@ -47,6 +48,14 @@ struct setup_data {
> > 	__u8 data[0];
> > };
> >
> >+/* extensible setup indirect data node */
> >+struct setup_indirect {
> >+	__u32 type;
> >+	__u32 reserved;  /* Reserved, must be set to zero. */
> >+	__u64 len;
> >+	__u64 addr;
> >+};
> >+
> > struct setup_header {
> > 	__u8	setup_sects;
> > 	__u16	root_flags;
>

> This needs actual implementation; we can't advertise it until the
> kernel knows how to consume the data! It probably should be moved to
> after the 3/3 patch.
>
> Implementing this has two parts:
>
> 1. The kernel needs to be augmented so it can find current objects via
> indirection.
>
> 2. And this is the main reason for this in the first place: the early
> code needs to walk the list and map out the memory areas which are
> occupied so it doesn't clobber anything; this allows this code to be
> generic as opposed to having to know what is a pointer and what size
> it might point to.
>
> (The decompressor didn't need this until kaslr entered the picture,
> but now it does, sadly.)

Do you think about arch/x86/boot/compressed/kaslr.c:mem_avoid[]?
But it is static. OK, we can assume that we do not accept more than
something indirect entries. However, this is not nice...

> Optional/future enhancements that might be nice:
>
> 3. Add some kind of description (e.g. foo=u64 ; bar=str ; baz=blob) to
> make it possible to write a bootloader that can load these kinds of
> objects without specific enabling.

This means an extension to command line parser. Am I right?

> 4. Add support for mapping initramfs fragments  this way.
>
> 5. Add support for passingload-on-boot kernel modules.

I am not sure what you mean exactly by those two.

Anyway, I would focus only on things which are potentially useful now or
in the near future and not require much code changes. So, IMO #1 and #2
at this point.

Daniel

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 1/3] x86/boot: Introduce the kernel_info
  2019-10-01 11:41         ` Daniel Kiper
@ 2019-10-01 22:28           ` H. Peter Anvin
  2019-10-02 12:00             ` Daniel Kiper
  0 siblings, 1 reply; 14+ messages in thread
From: H. Peter Anvin @ 2019-10-01 22:28 UTC (permalink / raw)
  To: Daniel Kiper
  Cc: linux-doc, linux-kernel, x86, bp, corbet, dpsmith, eric.snowberg,
	kanth.ghatraju, konrad.wilk, mingo, ross.philipson, tglx

On 2019-10-01 04:41, Daniel Kiper wrote:
> 
> OK, so, this is more or less what I had in my v3 patch before sending
> this email. So, it looks that I am on good track. Great! Though I am not
> sure that we should have magic for chunked objects. If yes could you
> explain why? I would just leave len for chunked objects.
> 

It makes it easier to validate the contents (bugs happen...), and would allow
for multiple chunks that could come from different object files if it ever
becomes necessary for some reason.

We could also just say that dynamic chunks don't even have pointers, and let
the boot loader just walk the list.

>> Also "InfO" is a pretty hideous magic. In general, all-ASCII magics have much
>> higher risk of collision than *RANDOM* binary numbers. However, for a chunked
>> architecture they do have the advantage that they can be used also as a human
>> name or file name for the chunk, e.,g. in sysfs, so maybe something like
>> "LnuX" or even "LToP" for the top-level chunk might make sense.
>>
>> How does that sound?
> 
> Well, your proposals are more cryptic, especially the second one, than
> mine but I tend to agree that more *RANDOM* magics are better. So,
> I would choose "LToP" if you decipher it for me. Linux Top?
> 

Yes, Linux top [structure].

	-hpa


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 1/3] x86/boot: Introduce the kernel_info
  2019-10-01 22:28           ` H. Peter Anvin
@ 2019-10-02 12:00             ` Daniel Kiper
  0 siblings, 0 replies; 14+ messages in thread
From: Daniel Kiper @ 2019-10-02 12:00 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: linux-doc, linux-kernel, x86, bp, corbet, dpsmith, eric.snowberg,
	kanth.ghatraju, konrad.wilk, mingo, ross.philipson, tglx

On Tue, Oct 01, 2019 at 03:28:01PM -0700, H. Peter Anvin wrote:
> On 2019-10-01 04:41, Daniel Kiper wrote:
> >
> > OK, so, this is more or less what I had in my v3 patch before sending
> > this email. So, it looks that I am on good track. Great! Though I am not
> > sure that we should have magic for chunked objects. If yes could you
> > explain why? I would just leave len for chunked objects.
> >
>
> It makes it easier to validate the contents (bugs happen...), and would allow
> for multiple chunks that could come from different object files if it ever
> becomes necessary for some reason.

OK.

> We could also just say that dynamic chunks don't even have pointers, and let
> the boot loader just walk the list.

Yeah... That seams simpler. I will do that.

> >> Also "InfO" is a pretty hideous magic. In general, all-ASCII magics have much
> >> higher risk of collision than *RANDOM* binary numbers. However, for a chunked
> >> architecture they do have the advantage that they can be used also as a human
> >> name or file name for the chunk, e.,g. in sysfs, so maybe something like
> >> "LnuX" or even "LToP" for the top-level chunk might make sense.
> >>
> >> How does that sound?
> >
> > Well, your proposals are more cryptic, especially the second one, than
> > mine but I tend to agree that more *RANDOM* magics are better. So,
> > I would choose "LToP" if you decipher it for me. Linux Top?
> >
>
> Yes, Linux top [structure].

Thx!

Daniel

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2019-10-02 12:03 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-04 16:36 [PATCH v2 0/3] x86/boot: Introduce the kernel_info et consortes Daniel Kiper
2019-07-04 16:36 ` [PATCH v2 1/3] x86/boot: Introduce the kernel_info Daniel Kiper
2019-07-12 16:04   ` hpa
2019-09-30 15:01     ` Daniel Kiper
2019-09-30 17:18       ` H. Peter Anvin
2019-10-01 11:41         ` Daniel Kiper
2019-10-01 22:28           ` H. Peter Anvin
2019-10-02 12:00             ` Daniel Kiper
2019-07-04 16:36 ` [PATCH v2 2/3] x86/boot: Introduce the setup_indirect Daniel Kiper
2019-07-12 15:56   ` hpa
2019-10-01 14:47     ` Daniel Kiper
2019-07-04 16:36 ` [PATCH v2 3/3] x86/boot: Introduce the kernel_info.setup_type_max Daniel Kiper
2019-07-12 15:59   ` hpa
2019-07-12 11:58 ` [PATCH v2 0/3] x86/boot: Introduce the kernel_info et consortes Daniel Kiper

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).