| Message ID | 20240313150748.791236-2-ross.lagerwall@citrix.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | GRUB: Supporting Secure Boot of xen.gz | expand |
On 13.03.2024 16:07, Ross Lagerwall wrote: > 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). And the consideration to have ELF signable (by whatever extension to the ELF spec) went nowhere? Jan
Hi, I saw this on the list and have concerns: -------- Original Message -------- On 14 Mar 2024, 6:24 pm, Jan Beulich via Grub-devel < grub-devel@gnu.org> wrote: On 13.03.2024 16:07, Ross Lagerwall wrote: >> 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). > And the consideration to have ELF signable (by whatever extension to the ELF spec) went nowhere? Jan If the purpose of signing binaries is to prevent their execution unless they are signed by their owner, this is MALWARE unless the end user can replace the keys with one of their choosing. Adding a field to elf to provide this feature is IMHO asking for trouble because the key is stored elsewhere and there is nothing to prevent abuse of this field to deny users their freedom to run code, (ie by not providing them the key or a guaranteed mechanism for providing their own). On that note, why is it such a useful feature to restrict the freedom to run code in grub? If grub selects malware to execute, the user must have chosen to run it - or grub itself is compromised? Do you think that locking binaries down is the future for users to ensure their own security or it is acceptable for 3rd parties to hide platform keys to lock all systems down, even by binary? I'm not convinced. Damien Zammit GNU/Hurd hacker
On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich <jbeulich@suse.com> wrote: > > On 13.03.2024 16:07, Ross Lagerwall wrote: > > 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). > > And the consideration to have ELF signable (by whatever extension to > the ELF spec) went nowhere? > I'm not sure if you're referring to some ongoing work to create signable ELFs that I'm not aware of. I didn't choose that route because: * Signed PE binaries are the current standard for Secure Boot. * Having signed ELF binaries would mean that code to handle them needs to be added to Shim which contravenes its goals of being small and simple to verify. * I could be wrong on this but to my knowledge, the ELF format is not being actively updated nor is the standard owned/maintained by a specific group which makes updating it difficult. * Tools would need to be updated/developed to add support for signing ELF binaries and inspecting the signatures. I am open to suggestions of course but I'm not sure what benefits there would be to going the ELF route. Ross
On 14.03.2024 10:30, Ross Lagerwall wrote: > On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich <jbeulich@suse.com> wrote: >> >> On 13.03.2024 16:07, Ross Lagerwall wrote: >>> 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). >> >> And the consideration to have ELF signable (by whatever extension to >> the ELF spec) went nowhere? >> > > I'm not sure if you're referring to some ongoing work to create signable > ELFs that I'm not aware of. Something must have been invented already to make Linux modules signable. > I didn't choose that route because: > > * Signed PE binaries are the current standard for Secure Boot. > > * Having signed ELF binaries would mean that code to handle them needs > to be added to Shim which contravenes its goals of being small and > simple to verify. Both true, but neither goes entirely without saying, I suppose. > * I could be wrong on this but to my knowledge, the ELF format is not > being actively updated nor is the standard owned/maintained by a > specific group which makes updating it difficult. And PE/COFF isn't under control of a public entity / group afaik, which may be viewed as no better, if not worse. > * Tools would need to be updated/developed to add support for signing > ELF binaries and inspecting the signatures. As above, yes indeed. Jan
On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich <jbeulich@suse.com> wrote: > > On 14.03.2024 10:30, Ross Lagerwall wrote: > > On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich <jbeulich@suse.com> wrote: > >> > >> On 13.03.2024 16:07, Ross Lagerwall wrote: > >>> 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). > >> > >> And the consideration to have ELF signable (by whatever extension to > >> the ELF spec) went nowhere? > >> > > > > I'm not sure if you're referring to some ongoing work to create signable > > ELFs that I'm not aware of. > > Something must have been invented already to make Linux modules signable. Linux module signatures operate outside of the ELF container. In fact, AFAIK the actual signed content could be anything. The file format is: * Content (i.e. ELF binary) * Signature of content in PKCS7 format * Signature info, including signature length * Magic marker: "~Module signature appended~\n" This kind of arrangement does indeed work but it is fragile. Since the signature is on the entire contents and tools that understand ELF don't parse the signature, any transformation of the binary (e.g. to strip out debuginfo) will cause the signature to be lost / invalidated. Nevertheless, this could still be an option for Xen if this is deemed to be a preferred solution by others. It would be good to hear some opinions on this. > > > I didn't choose that route because: > > > > * Signed PE binaries are the current standard for Secure Boot. > > > > * Having signed ELF binaries would mean that code to handle them needs > > to be added to Shim which contravenes its goals of being small and > > simple to verify. > > Both true, but neither goes entirely without saying, I suppose. > > > * I could be wrong on this but to my knowledge, the ELF format is not > > being actively updated nor is the standard owned/maintained by a > > specific group which makes updating it difficult. > > And PE/COFF isn't under control of a public entity / group afaik, which > may be viewed as no better, if not worse. Agreed, I guess my point was that PE/COFF doesn't need to be updated to support signing because it already supports it. Thanks, Ross
On 14.03.2024 15:24, Ross Lagerwall wrote: > On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich <jbeulich@suse.com> wrote: >> On 14.03.2024 10:30, Ross Lagerwall wrote: >>> On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich <jbeulich@suse.com> wrote: >>>> On 13.03.2024 16:07, Ross Lagerwall wrote: >>>>> 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). >>>> >>>> And the consideration to have ELF signable (by whatever extension to >>>> the ELF spec) went nowhere? >>> >>> I'm not sure if you're referring to some ongoing work to create signable >>> ELFs that I'm not aware of. >> >> Something must have been invented already to make Linux modules signable. > > Linux module signatures operate outside of the ELF container. In fact, > AFAIK the actual signed content could be anything. The file format is: > > * Content (i.e. ELF binary) > * Signature of content in PKCS7 format > * Signature info, including signature length > * Magic marker: "~Module signature appended~\n" > > This kind of arrangement does indeed work but it is fragile. Since the > signature is on the entire contents and tools that understand ELF don't > parse the signature, any transformation of the binary (e.g. to > strip out debuginfo) will cause the signature to be lost / invalidated. This looks extremely poor to me, so ... > Nevertheless, this could still be an option for Xen if this is > deemed to be a preferred solution by others. It would be good to hear > some opinions on this. ... I'd rather not see this used for Xen. Jan
On Thu, Mar 14, 2024 at 02:24:31PM +0000, Ross Lagerwall wrote: > On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich <jbeulich@suse.com> wrote: > > > > On 14.03.2024 10:30, Ross Lagerwall wrote: > > > On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich <jbeulich@suse.com> wrote: > > >> > > >> On 13.03.2024 16:07, Ross Lagerwall wrote: > > >>> 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). > > >> > > >> And the consideration to have ELF signable (by whatever extension to > > >> the ELF spec) went nowhere? > > >> > > > > > > I'm not sure if you're referring to some ongoing work to create signable > > > ELFs that I'm not aware of. > > > > Something must have been invented already to make Linux modules signable. > > Linux module signatures operate outside of the ELF container. In fact, > AFAIK the actual signed content could be anything. The file format is: > > * Content (i.e. ELF binary) > * Signature of content in PKCS7 format > * Signature info, including signature length > * Magic marker: "~Module signature appended~\n" > > This kind of arrangement does indeed work but it is fragile. Since the > signature is on the entire contents and tools that understand ELF don't > parse the signature, any transformation of the binary (e.g. to > strip out debuginfo) will cause the signature to be lost / invalidated. > > Nevertheless, this could still be an option for Xen if this is > deemed to be a preferred solution by others. It would be good to hear > some opinions on this. No, IMO the PE route is likely the best one, as there's already all the tooling around it, and it's what other OSes use to perform secure boot. It would have been nice for ELF to grow an extension to the spec for image integrity data, but I don't see myself doing the work TBH. Thanks, Roger.
On Wed, Mar 13, 2024 at 03:07:42PM +0000, Ross Lagerwall wrote: > 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 I wonder if it would be simpler to use the following order instead: 1. Address tag 2. Load type tag 3. ELF header It's pointless to add a Loader type tag with load_type == 0, as that's already mandated by the Address tag. IOW: signaling the use of the Address tag here is kind of pointless, if the fields in the Address tag are set, that's the only signaling required for the data in the Address tag to be used. Or are we attempting to support images that set Address tag and Load type tag != 0 in order to use the Address tag when the loader doesn't recognize the Load type tag, and otherwise use a different format? Would it be sensible for multiboot2 to use PE in preference to ELF if present on the image? (without requiring any signaling). I would think this could be troublesome if kernels are so far expecting the ELF header to be used with multiboot2, even if they also expose a PE header. Thanks, Roger.
On Tue, Mar 19, 2024 at 1:18 PM Roger Pau Monné <roger.pau@citrix.com> wrote: > > On Wed, Mar 13, 2024 at 03:07:42PM +0000, Ross Lagerwall wrote: > > 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 > > I wonder if it would be simpler to use the following order instead: > > 1. Address tag > 2. Load type tag > 3. ELF header > > It's pointless to add a Loader type tag with load_type == 0, as that's > already mandated by the Address tag. IOW: signaling the use of the > Address tag here is kind of pointless, if the fields in the Address > tag are set, that's the only signaling required for the data in the > Address tag to be used. > > Or are we attempting to support images that set Address tag and Load > type tag != 0 in order to use the Address tag when the loader doesn't > recognize the Load type tag, and otherwise use a different format? No, that wasn't my intention. My intention for the load type tag was to have one tag that unambiguously describes the payload format and if that is missing, fall back to the previous logic for compatibility. It avoids more complicated heuristics if different payload types are added in the future. > > Would it be sensible for multiboot2 to use PE in preference to ELF if > present on the image? (without requiring any signaling). I would > think this could be troublesome if kernels are so far expecting the > ELF header to be used with multiboot2, even if they also expose a PE > header. > AFAIK an ELF image can't also be a valid PE/COFF image since they have different magic numbers at the start of the image. Perhaps it would be simpler to avoid introducing the load type tag and just load the payload based on the magic number? Ross
On Tue, Mar 19, 2024 at 02:46:59PM +0000, Ross Lagerwall wrote: > On Tue, Mar 19, 2024 at 1:18 PM Roger Pau Monné <roger.pau@citrix.com> wrote: > > > > On Wed, Mar 13, 2024 at 03:07:42PM +0000, Ross Lagerwall wrote: > > > 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 > > > > I wonder if it would be simpler to use the following order instead: > > > > 1. Address tag > > 2. Load type tag > > 3. ELF header > > > > It's pointless to add a Loader type tag with load_type == 0, as that's > > already mandated by the Address tag. IOW: signaling the use of the > > Address tag here is kind of pointless, if the fields in the Address > > tag are set, that's the only signaling required for the data in the > > Address tag to be used. > > > > Or are we attempting to support images that set Address tag and Load > > type tag != 0 in order to use the Address tag when the loader doesn't > > recognize the Load type tag, and otherwise use a different format? > > No, that wasn't my intention. My intention for the load type tag was > to have one tag that unambiguously describes the payload format and if > that is missing, fall back to the previous logic for compatibility. > It avoids more complicated heuristics if different payload types are > added in the future. > > > > > Would it be sensible for multiboot2 to use PE in preference to ELF if > > present on the image? (without requiring any signaling). I would > > think this could be troublesome if kernels are so far expecting the > > ELF header to be used with multiboot2, even if they also expose a PE > > header. > > > > AFAIK an ELF image can't also be a valid PE/COFF image since they have > different magic numbers at the start of the image. Perhaps it would > be simpler to avoid introducing the load type tag and just load the > payload based on the magic number? I would likely be fine with just handling it like we handle ELF, if a PE header is found use it. As long as ELF and PE headers are mutually exclusive. Thanks, Roger.
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;
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(-)