All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Lagerwall <ross.lagerwall@citrix.com>
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Ross Lagerwall <ross.lagerwall@citrix.com>
Subject: [PATCH 1/7] multiboot2: Add load type header and support for the PE binary type
Date: Wed, 13 Mar 2024 15:07:42 +0000	[thread overview]
Message-ID: <20240313150748.791236-2-ross.lagerwall@citrix.com> (raw)
In-Reply-To: <20240313150748.791236-1-ross.lagerwall@citrix.com>

Currently, multiboot2-compatible bootloaders can load ELF binaries and
a.out binaries. The presence of the address header tag determines
how the bootloader tries to interpret the binary (a.out if the address
tag is present else ELF).

Add a new load type header tag that explicitly states the type of the
binary. Bootloaders should use the binary type specified in the load
type tag. If the load type tag is not present, the bootloader should
fall back to the previous heuristics.

In addition to the existing address and ELF load types, specify a new
optional PE binary load type. This new type is a useful addition since
PE binaries can be signed and verified (i.e. used with Secure Boot).

Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
---
 doc/multiboot.texi | 39 ++++++++++++++++++++++++++++++++++-----
 doc/multiboot2.h   | 13 +++++++++++++
 2 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index df8a0d056e76..d12719c744eb 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -511,11 +511,12 @@ assumes that no bss segment is present.
 
 Note: This information does not need to be provided if the kernel image
 is in @sc{elf} format, but it must be provided if the image is in a.out
-format or in some other format. When the address tag is present it must
-be used in order to load the image, regardless of whether an @sc{elf}
-header is also present. Compliant boot loaders must be able to load
-images that are either in @sc{elf} format or contain the address tag
-embedded in the Multiboot2 header.
+format or in some other format. If the load type tag is not specified
+and the address tag is present it must be used in order to load the
+image, regardless of whether an @sc{elf} header is also present.
+Compliant boot loaders must be able to load images that are either in
+@sc{elf} format or contain the address tag embedded in the Multiboot2
+header.
 
 @subsection The entry address tag of Multiboot2 header
 
@@ -732,6 +733,34 @@ and @samp{2} means load image at highest possible address but not
 higher than max_addr.
 @end table
 
+@node Load type tag
+@subsection Load type tag
+
+@example
+@group
+        +-------------------+
+u16     | type = 11         |
+u16     | flags             |
+u32     | size = 12         |
+u32     | load_type         |
+        +-------------------+
+@end group
+@end example
+
+This tag indicates the type of the payload and how the boot loader
+should load it.
+
+The meaning of each field is as follows:
+
+@table @code
+@item load_type
+Recognized load types are @samp{0} for address (i.e. load a.out using
+the address tag), @samp{1} for ELF, and @samp{2} for PE. Compliant
+bootloaders should implement support for a.out and ELF as a minimum.  If
+this tag is not specified, the boot loader should attempt to load the
+payload using the information specified in the address tag if present,
+else it should load the payload as an ELF binary.  @end table
+
 @node Machine state
 @section MIPS machine state
 
diff --git a/doc/multiboot2.h b/doc/multiboot2.h
index b181607075b2..d4cae05706e4 100644
--- a/doc/multiboot2.h
+++ b/doc/multiboot2.h
@@ -75,6 +75,7 @@
 #define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI32  8
 #define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
 #define MULTIBOOT_HEADER_TAG_RELOCATABLE  10
+#define MULTIBOOT_HEADER_TAG_LOAD_TYPE  11
 
 #define MULTIBOOT_ARCHITECTURE_I386  0
 #define MULTIBOOT_ARCHITECTURE_MIPS32  4
@@ -179,6 +180,18 @@ struct multiboot_header_tag_relocatable
   multiboot_uint32_t preference;
 };
 
+struct multiboot_header_tag_load_type
+{
+  multiboot_uint16_t type;
+  multiboot_uint16_t flags;
+  multiboot_uint32_t size;
+#define MULTIBOOT_LOAD_TYPE_ADDRESS     0
+#define MULTIBOOT_LOAD_TYPE_ELF         1
+#define MULTIBOOT_LOAD_TYPE_PE          2
+#define MULTIBOOT_LOAD_TYPE_TOTAL       3
+  multiboot_uint32_t load_type;
+};
+
 struct multiboot_color
 {
   multiboot_uint8_t red;
-- 
2.43.0



WARNING: multiple messages have this Message-ID (diff)
From: Ross Lagerwall via Grub-devel <grub-devel@gnu.org>
To: grub-devel@gnu.org
Cc: Ross Lagerwall <ross.lagerwall@citrix.com>,
	xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>
Subject: [PATCH 1/7] multiboot2: Add load type header and support for the PE binary type
Date: Wed, 13 Mar 2024 15:07:42 +0000	[thread overview]
Message-ID: <20240313150748.791236-2-ross.lagerwall@citrix.com> (raw)
In-Reply-To: <20240313150748.791236-1-ross.lagerwall@citrix.com>

Currently, multiboot2-compatible bootloaders can load ELF binaries and
a.out binaries. The presence of the address header tag determines
how the bootloader tries to interpret the binary (a.out if the address
tag is present else ELF).

Add a new load type header tag that explicitly states the type of the
binary. Bootloaders should use the binary type specified in the load
type tag. If the load type tag is not present, the bootloader should
fall back to the previous heuristics.

In addition to the existing address and ELF load types, specify a new
optional PE binary load type. This new type is a useful addition since
PE binaries can be signed and verified (i.e. used with Secure Boot).

Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
---
 doc/multiboot.texi | 39 ++++++++++++++++++++++++++++++++++-----
 doc/multiboot2.h   | 13 +++++++++++++
 2 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index df8a0d056e76..d12719c744eb 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -511,11 +511,12 @@ assumes that no bss segment is present.
 
 Note: This information does not need to be provided if the kernel image
 is in @sc{elf} format, but it must be provided if the image is in a.out
-format or in some other format. When the address tag is present it must
-be used in order to load the image, regardless of whether an @sc{elf}
-header is also present. Compliant boot loaders must be able to load
-images that are either in @sc{elf} format or contain the address tag
-embedded in the Multiboot2 header.
+format or in some other format. If the load type tag is not specified
+and the address tag is present it must be used in order to load the
+image, regardless of whether an @sc{elf} header is also present.
+Compliant boot loaders must be able to load images that are either in
+@sc{elf} format or contain the address tag embedded in the Multiboot2
+header.
 
 @subsection The entry address tag of Multiboot2 header
 
@@ -732,6 +733,34 @@ and @samp{2} means load image at highest possible address but not
 higher than max_addr.
 @end table
 
+@node Load type tag
+@subsection Load type tag
+
+@example
+@group
+        +-------------------+
+u16     | type = 11         |
+u16     | flags             |
+u32     | size = 12         |
+u32     | load_type         |
+        +-------------------+
+@end group
+@end example
+
+This tag indicates the type of the payload and how the boot loader
+should load it.
+
+The meaning of each field is as follows:
+
+@table @code
+@item load_type
+Recognized load types are @samp{0} for address (i.e. load a.out using
+the address tag), @samp{1} for ELF, and @samp{2} for PE. Compliant
+bootloaders should implement support for a.out and ELF as a minimum.  If
+this tag is not specified, the boot loader should attempt to load the
+payload using the information specified in the address tag if present,
+else it should load the payload as an ELF binary.  @end table
+
 @node Machine state
 @section MIPS machine state
 
diff --git a/doc/multiboot2.h b/doc/multiboot2.h
index b181607075b2..d4cae05706e4 100644
--- a/doc/multiboot2.h
+++ b/doc/multiboot2.h
@@ -75,6 +75,7 @@
 #define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI32  8
 #define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
 #define MULTIBOOT_HEADER_TAG_RELOCATABLE  10
+#define MULTIBOOT_HEADER_TAG_LOAD_TYPE  11
 
 #define MULTIBOOT_ARCHITECTURE_I386  0
 #define MULTIBOOT_ARCHITECTURE_MIPS32  4
@@ -179,6 +180,18 @@ struct multiboot_header_tag_relocatable
   multiboot_uint32_t preference;
 };
 
+struct multiboot_header_tag_load_type
+{
+  multiboot_uint16_t type;
+  multiboot_uint16_t flags;
+  multiboot_uint32_t size;
+#define MULTIBOOT_LOAD_TYPE_ADDRESS     0
+#define MULTIBOOT_LOAD_TYPE_ELF         1
+#define MULTIBOOT_LOAD_TYPE_PE          2
+#define MULTIBOOT_LOAD_TYPE_TOTAL       3
+  multiboot_uint32_t load_type;
+};
+
 struct multiboot_color
 {
   multiboot_uint8_t red;
-- 
2.43.0


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

  reply	other threads:[~2024-03-13 15:06 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-13 15:07 [PATCH 0/7] GRUB: Supporting Secure Boot of xen.gz Ross Lagerwall
2024-03-13 15:07 ` Ross Lagerwall via Grub-devel
2024-03-13 15:07 ` Ross Lagerwall [this message]
2024-03-13 15:07   ` [PATCH 1/7] multiboot2: Add load type header and support for the PE binary type Ross Lagerwall via Grub-devel
2024-03-14  7:24   ` Jan Beulich
2024-03-14  7:24     ` Jan Beulich via Grub-devel
2024-03-14  8:12     ` Damien Zammit via Grub-devel
2024-03-14  8:12       ` Damien Zammit
2024-03-14  8:49     ` Vladimir 'phcoder' Serbinenko
2024-03-14  9:30     ` Ross Lagerwall
2024-03-14  9:30       ` Ross Lagerwall via Grub-devel
2024-03-14 13:37       ` Jan Beulich
2024-03-14 13:37         ` Jan Beulich via Grub-devel
2024-03-14 14:24         ` Ross Lagerwall
2024-03-14 14:24           ` Ross Lagerwall via Grub-devel
2024-03-14 14:33           ` Jan Beulich
2024-03-14 14:33             ` Jan Beulich via Grub-devel
2024-03-19 12:12           ` Roger Pau Monné
2024-03-19 12:12             ` Roger Pau Monné via Grub-devel
2024-03-19 13:18   ` Roger Pau Monné
2024-03-19 13:18     ` Roger Pau Monné via Grub-devel
2024-03-19 14:46     ` Ross Lagerwall
2024-03-19 14:46       ` Ross Lagerwall via Grub-devel
2024-03-20 11:04       ` Roger Pau Monné
2024-03-20 11:04         ` Roger Pau Monné via Grub-devel
2024-03-13 15:07 ` [PATCH 2/7] multiboot2: Allow 64-bit entry tags Ross Lagerwall
2024-03-13 15:07   ` Ross Lagerwall via Grub-devel
2024-03-19 10:07   ` Roger Pau Monné
2024-03-19 10:07     ` Roger Pau Monné via Grub-devel
2024-03-28 15:05     ` Ross Lagerwall
2024-03-28 15:05       ` Ross Lagerwall via Grub-devel
2024-03-28 15:41       ` Roger Pau Monné
2024-03-28 15:41         ` Roger Pau Monné via Grub-devel
2024-03-13 15:07 ` [PATCH 3/7] multiboot2: Add support for the load type header tag Ross Lagerwall
2024-03-13 15:07   ` Ross Lagerwall via Grub-devel
2024-03-15  7:30   ` Vladimir 'phcoder' Serbinenko
2024-03-15  7:30     ` Vladimir 'phcoder' Serbinenko
2024-03-28 14:58     ` Ross Lagerwall
2024-03-28 14:58       ` Ross Lagerwall via Grub-devel
2024-03-13 15:07 ` [PATCH 4/7] multiboot2: Add PE load support Ross Lagerwall
2024-03-13 15:07   ` Ross Lagerwall via Grub-devel
2024-03-13 15:07 ` [PATCH 5/7] multiboot2: Add support for 64-bit entry addresses Ross Lagerwall
2024-03-13 15:07   ` Ross Lagerwall via Grub-devel
2024-03-13 15:07 ` [PATCH 6/7] efi: Allow loading multiboot modules without verification Ross Lagerwall
2024-03-13 15:07   ` Ross Lagerwall via Grub-devel
2024-03-13 15:07 ` [PATCH 7/7] verifiers: Verify after decompression Ross Lagerwall
2024-03-13 15:07   ` Ross Lagerwall via Grub-devel
2024-03-15  3:50   ` Michael Chang
2024-03-15  3:50     ` Michael Chang via Grub-devel
2024-03-15  7:25   ` Vladimir 'phcoder' Serbinenko
2024-03-28 14:55     ` Ross Lagerwall via Grub-devel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240313150748.791236-2-ross.lagerwall@citrix.com \
    --to=ross.lagerwall@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=daniel.kiper@oracle.com \
    --cc=grub-devel@gnu.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.