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] [day] [month] [year] [list]

Message-ID: <20170220184658.GA14469@router-fw-old.local.net-space.pl>
Date:   Mon, 20 Feb 2017 19:46:58 +0100
From:   Daniel Kiper <dkiper@...-space.pl>
To:     The development of GNU GRUB <grub-devel@....org>
Cc:     Daniel Kiper <dkiper@...-space.pl>,
        Juergen Gross <jgross@...e.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Matt Fleming <matt@...eblueprint.co.uk>, phcoder@...il.com,
        Daniel Kiper <daniel.kiper@...cle.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, Alexander Graf <agraf@...e.de>,
        arvidjaar@...il.com, "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Chao Peng <chao.p.peng@...ux.intel.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andy Lutomirski <luto@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...e.de>, Amnon Ilan <ailan@...hat.com>,
        Thomas Garnier <thgarnie@...gle.com>, konrad.wilk@...cle.com
Subject: Re: [RFC PATCH] x86/boot: make ELF kernel multiboot-able

On Thu, Feb 16, 2017 at 09:00:05PM -0800, H. Peter Anvin wrote:
> On 02/16/17 15:27, Daniel Kiper wrote:
> > That is obvious. Do you think that Multiboot/Multiboot2 protocols are
> > substantially suboptimal?
>
> Yes.  They push a lot of things into the bootloader for no good reason,

I have not seen anything in Multiboot(2) specs which stipulates that every
bootloader must implement all features. If somebody needs minimal Multiboot(2)
compatible bootloader he/she can do that. Just parse Multiboot(2) header and
provide, let's call it in that way, empty boot data. Is it difficult?

> thus tying the kernel's hands and making the whole boot process more
> fragile.

Every kernel may take from the bootloader via Multiboot(2) what it needs.
No more no less. There is no requirement to use all data provided by
the bootloader.

> It isn't either like Grub has been very good about keeping to any spec,
> their own or others.

Could you be more precise?

Daniel