linux-kernel - [RFC] Multiboot2 drafting

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

Date:	Sat, 03 Apr 2010 19:01:41 +0200
From:	Vladimir 'φ-coder/phcoder' Serbinenko 
	<phcoder@...il.com>
To:	linux-kernel@...r.kernel.org,
	The development of GRUB 2 <grub-devel@....org>
Subject: [RFC] Multiboot2 drafting

Hello, all. In GRUB2 community we're currently working on a
next-generation multiboot specification. It has goals similar to the
original multiboot specification but with important flaws fixed:
1) Instead of having bunch of pointers to subtables it uses a tagged
structure now. It allows it to be easier expandable, consume less space
if some fields aren't used and is easier to relocate.
2) Now it's portable. It has fields for specification of architecture
and proper field alignment. So now adding a new arcitecture is as easy
as adding a new arcitecture id and a section dealing with
architecture-specific problems like register usage to pass information.
Currently it has only i386 and mips though. Both are implemented in bzr
trunk grub[1]
Short summary:
Multiboot specification is done as an unified protocol between
bootloader and kernel to allow supporting more kernels and bootloaders
with less effort. The easiest way to use it is to create an ELF image
with an additional header which announces multiboot support and specific
kernel requirements. But it's also possible to put loading address in
multiboot header and use a non-ELF format.
When image is loaded one of GPRs contaians a magic number to identify
that kernel was loaded as multiboot and another GPR contains a pointer
to information table. The most needed information is already there, more
is in review progress, and if you feel like we're missing somethin feel
free to contact.
Complete specification is available at
http://bzr.savannah.gnu.org/r/grub/branches/multiboot2/ or at
http://download.savannah.gnu.org/releases-noredirect/grub/phcoder/multiboot.pdf

Some advantages:
1) Removes the need to support a fundamentaly different boot protocol
for every architecture. In future it may even be possible to have just
one image per ISA and rely on information supplied by bootloader to
differentiate between platforms (it doesn't prevent creation of an image
optimised for one platform)
2) Better collaboration between bootloaders and kernels by avoiding to
implement "one protocol per kernel".
3) Possibility to inform bootloader of exact kernel requirements and
supported features.
4) Uniform interface for retrieving e.g. memory map and initial console
info across platforms.
<Anything else you request ;)>

Any comment about multiboot2 spec is welcome.

Would it be possible for Linux in perspective to use multiboot2 instead
or in addition to current protocols?

Thanks for your time.

[1] Available with
bzr co --lightweight http://bzr.savannah.gnu.org/r/grub/trunk/grub/
or as a tarball at
http://download.savannah.gnu.org/releases-noredirect/grub/phcoder/grub-r2283.tgz

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Download attachment "signature.asc" of type "application/pgp-signature" (294 bytes)