Re: [RFC PATCH] x86/boot: make ELF kernel multiboot-able

[hpa]

On February 15, 2017 12:13:36 PM PST, "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx> wrote:
>On Wed, Feb 15, 2017 at 10:12:07AM -0800, hpa@xxxxxxxxx wrote:
>> On February 15, 2017 6:41:56 AM PST, Chao Peng
><chao.p.peng@xxxxxxxxxxxxxxx> wrote:
>> >Multiboot specification
>>
>>(http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multiboot2)
>> >is an open standard that provides kernels with a uniform way to be
>booted
>> >by multiboot-compliant bootloaders (like grub).
>> >
>> >This patch is trying to make Linux ELF kernel image to be a
>> >multiboot-compliant OS so that it can be loaded by a
>multiboot-comliant
>> >bootloader. The benefit is eliminating the maintainance for realmode
>and
>> >decompression code and especially when the kernel is loaded in a
>virtual
>> >machine, the reducing for these code can greatly cuts down the boot
>time.
>> >
>> >However, the current version of multiboot spec doesn't support 64
>bit well
>> >so for 64 bit kernel we need stub code to jump from 32 bit code to
>64 bit
>> >code. Besides, there are still some other issues:
>> >
>> >1). '-z max-page-size=0x1000' is used so the text segment start is
>in
>> >multiboot header search scope because GNU LD has default page size
>of
>> >0x00200000 for ELF64, which will fail multiboot test.
>> >
>> >2). The bootloader like grub has support for ELF kernel (even for
>ELF64)
>> >which makes the patch easier. However, the current grub
>implementaion thinks
>> >the entry address should be a VA. E.g. for 64 bit kernel, the entry
>address
>> >(0x1000000) is actually phiscial address, grub refuses to load it by
>saying:
>> >'entry point isn't in a segment'.
>> >
>> >This patch is sent out as RFC in case you have some ideas.
>> >
>> >Signed-off-by: Chao Peng <chao.p.peng@xxxxxxxxxxxxxxx>
>> 
>> As has been shown many times before, this is a really bad idea. 
>Unless there
>> is a real-life use case where this matters enormously, this is nacked
>with
>> extreme prejudice.
>
>Just something to consider, provided the issues with multiboot get
>resolved:
>
>If you want to boot Xen you actually use the multiboot protocol, the
>last PVH
>boot patches had borrowed ideas from Multiboot to add an entry to
>Linux, only
>it was Xen'ified. What would be Multiboot 2 seemed flexible enough to
>allow all
>sorts of custom semantics and information stacked into a boot image.
>The last
>thought I had over this topic (before giving up)  was-- if we're going
>to add
>yet-another-entry (TM) why not add extend Mulitiboot 2 protocol with
>the
>semantics we need to boot any virtual environment and then add
>Multiboot 2
>support entry on Linux? We could redirect any custom boot mechanism
>then to
>just use that given its flexibility.
>
>  Luis

Multiboot has a fundamentally broken assumption, which is to do certain work for the kernel in the bootloader.  This is fundamentally a bad idea, because you always want to do things in the latest step possible during the boot process, being the most upgradeable, and have the interface as narrow as possible.

Therefore, using Multiboot is actively a negative step.  It is declared an "Open Standard" but anything can be such declared; it really is a claim that "everything should work like Grub."
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.