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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1487210836.3019.2.camel@linux.intel.com>
Date:   Thu, 16 Feb 2017 10:07:16 +0800
From:   Chao Peng <chao.p.peng@...ux.intel.com>
To:     hpa@...or.com, "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org, grub-devel@....org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        Juergen Gross <jgross@...e.com>, Borislav Petkov <bp@...e.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Thomas Garnier <thgarnie@...gle.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Amnon Ilan <ailan@...hat.com>, Alexander Graf <agraf@...e.de>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Daniel Kiper <daniel.kiper@...cle.com>
Subject: Re: [RFC PATCH] x86/boot: make ELF kernel multiboot-able


> > 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."

Thanks Peter and Luis for comments.

Chao