Multiboot Specification specifies an interface between a bootloader and a operating system, such that any complying boot loader should be able to load any complying operating system, because it provides a standard means for the communications between the bootloader and operating system software. According to this specification, it defines an interface in these three main aspects:
- Multiboot header: The format of an OS image as seen by a boot loader. A MB-compliant boot loader can search this header to determine how to load the OS image, and where to jump (the location of the entry point).
- Initial processor states: The state of a machine when a boot loader starts an OS. The specification defines the processor state before transferring to OS.
- Multiboot information structure: The format of boot information passed by a boot loader to an OS. e.g. such an information structure may contains memory map(e820 map), modules(like bzImage, initrd), UEFI information, cmdline options etc..
GRUB 2 (GRand Unified Bootloader) is one that is a multiboot-compliant bootloader. It can boot any multiboot-compliant operating systems. And as an OS image, GRUB2 itself is also multiboot-compliant, which means it can be booted by itself and any other multiboot-compliant bootloaders. Tboot has the similar capabilities.
- MB version 0.6.96: http://www.gnu.org/software/grub/manual/multiboot/multiboot.html
- MB version 1.6: http://nongnu.askapache.com/grub/phcoder/multiboot.pdf
Note that an OS image can embed both Multiboot 1 and Multiboot 2 header into a single image, however, basically the bootloader should provide a configuration mechanism to let users select which version of header (boot specification) will be used.
However, there is still a limitation:
- It doesn't define 64bit entry points, and doesn't define the 64bit processor handoff states. In reality, this introduces some issues in some special case. for example, when the Bootloader is 64bit and the OS image is also 64bit, then if both bootloader and OS are multiboot-compliant, the extra code logics must be introduced: 1) for bootloader, it must have to do processor mode switch from 64bit to 32bit in order to call the 32bit entry of OS image, and 2) for OS, it must also have to add a similar code stub to do processor mode in reverse order.