Re: multiboot2 and module2 boot issues via GRUB2
On 01.04.2021 03:06, Roman Shaposhnik wrote: > And the obvious next question: is my EVE usecase esoteric enough that > I should just go ahead and do a custom GRUB patch or is there a more > general interest in this? Not sure if it ought to be a grub patch - the issue could as well be dealt with in Xen, by concatenating modules to form a monolithic initrd. Jan ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2 and module2 boot issues via GRUB2
On 01.04.2021 21:43, Andrew Cooper wrote: > On 01/04/2021 09:44, Roger Pau Monné wrote: >> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote: >>> On 01.04.2021 03:06, Roman Shaposhnik wrote: And the obvious next question: is my EVE usecase esoteric enough that I should just go ahead and do a custom GRUB patch or is there a more general interest in this? >>> Not sure if it ought to be a grub patch - the issue could as well >>> be dealt with in Xen, by concatenating modules to form a monolithic >>> initrd. >> I would rather have it done in the loader than Xen, mostly because >> it's a Linux boot specific format, and hence I don't think Xen should >> have any knowledge about it. >> >> If it turns out to be impossible to implement on the loader side we >> should consider doing it in Xen, but that's not my first option. > > Concatenating random things which may or may not be initrds is > absolutely not something Xen should do. We don't have enough context to > do it safely/sensibly. Well, I wasn't suggesting anywhere to concatenate random things. Instead I was envisioning a command line option giving us the context we need (e.g. "initrd=3+5"). Jan ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/7] multiboot2: Add load type header and support for the PE binary type
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 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/7] multiboot2: Add load type header and support for the PE binary type
On 14.03.2024 10:30, Ross Lagerwall wrote: > On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich 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 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/7] multiboot2: Add load type header and support for the PE binary type
On 14.03.2024 15:24, Ross Lagerwall wrote: > On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich wrote: >> On 14.03.2024 10:30, Ross Lagerwall wrote: >>> On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich 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 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
