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

On Wed, Feb 15, 2017 at 12:58:37PM -0800, hpa@...or.com wrote:

[...]

> Multiboot has a fundamentally broken assumption, which is to do certain work

Just to be precise. We are talking about Multiboot2 here.

> for the kernel in the bootloader. This is fundamentally a bad idea, because

Why it is a bad idea? I think that it depends on a kernel. Some may wish to
figure out all/some machine details ourselves. However, some may do not care
and take everything from a bootloader. Anyway, Multiboot and Multiboot2 specs
do not force anybody to take one way or another. You are free to choose what
you like. Even more, you can pick exactly what you like.

> you always want to do things in the latest step possible during the boot process,

I can agree to some extent.

> being the most upgradeable,

Here I am not sure what you mean.

> and have the interface as narrow as possible.

That is obvious. Do you think that Multiboot/Multiboot2 protocols are
substantially suboptimal?

> Therefore, using Multiboot is actively a negative step.

Do you have better proposal? To be precise, I am not talking about patch itself
but about idea (of one common/standard boot protocol) in general.

> It is declared an "Open Standard" but anything can be such declared; it really
> is a claim that "everything should work like Grub."

I have not seen such statement in Multiboot and/or Multiboot2 spec. Of course it
was prepared by GRUB guys and the "reference" implementation is there. Though,
anybody may come and extend specs if he/she wishes. And I did it. Of course I can
agree that they are not perfect (especially Multiboot proto is very inflexible).
However, both protos try to standardize boot process. I think it is nice because
right now almost every (new) kernel has own boot protcol (some even support more
then one, sic!). And it is enormous task to support all of them in one boot loader.
So, I think that Multiboot protocols family (IMO, Multiboot2 is preferred today)
are good idea. Are they not perfect? Yes, but I do not think that proliferation
of tons of incompatible boot protocols, each specific for one kernel, is better.
So, if you think that we can fix something in Multiboot2 please tell us. If you
think that it is unfixable please tell us too. We can think about Multiboot3 too
(ehhh... maybe this is not the best idea). Anyway, it would be nice if one day
we have one common boot protocol for (almost) everybody.

Daniel