Re: GRUB and the risk of block list corruption in extX

[Chris Murphy]

On Feb 18, 2013, at 10:02 PM, Andrey Borzenkov <address@hidden> wrote:

> 
> Chainloading is actually the only sane way to do multiboot. While it
> may have started due to BIOS limitations, today chainloading is simply
> passing control to another bootloader.

If a system has only linux, chain loading doesn't need to be used at all. In 
particular if GRUB2 is employed.

The only case I know of that necessitates chain loading with GRUB2 is Windows 
on BIOS hardware because there isn't a GRUB boot loader to replace the Windows 
OSLoader processes.

> If you want to have "master" bootloader that loads everything else,
> you have to ensure that when "something else" changes, it is reflected
> in master bootloader configuration. That's unrealistic.

It's also untrue. GRUB can first load a grub.cfg pointing to the grub.cfg of 
each distribution; those distribution specific grub.cfg's are updated by those 
distributions. The first grub.cfg only needs updating when a distribution is 
added/subtracted - which is no different than what you'd have to do with the 
first boot loaders config if you were chain loading to a 2nd bootloader rather 
than to merely a configuration file.

> I have test VM with Windows/Fedora/openSUSE. I installed openSUSE

> after Fedora. Wanna guess if openSUSE kerenls are present in Fedora
> grub.cfg?

The lack of cooperation on inter-distribution multiboot experience is 
orthogonal to chain loading.

> 
>> Name something you can only do via chainloading that you cannot do by 
>> keeping a singular
>> primary boot loader up-to-date.
> 
> This requires close cooperation between *all* installed OSes that is
> simply not going to happen.

Chainloading doesn't solve this problem. You still have a primary bootloader 
that doesn't know anything about the 2nd, 3rd, 4th bootloaders. You still have 
to rewrite some configuration file to make it aware of the distribution 
specific boot loader.

> 
> Oh, and how to you add options for Windows loader to you primary grub2
> bootloader?

Windows on BIOS does necessitate chain loading, that's its legacy.

> 
>> Chainloading is a relic of BIOS limitations. It's a relic of boot sectors. 
>> That's not how things
>> work with UEFI. The way forward is precisely the end to chainloading.
> 
> Huh? EFI has master bootloader which *chainloads* other bootladers. If
> anything, this is "chainloading made right".


OK I think that's a broad use of chain loading. UEFI defines a boot manager, 
which is used to choose a boot loader application, which loads a kernel. In 
that envisioned sequence there's no actual replacement of a block of 
instructions with another. The boot manager runs within UEFI, the OS loader 
application runs along side the boot manager as part of boot services, and the 
kernel is loaded by the OS loader into a separate area of memory too - it's not 
wholesale replaced. So I wouldn't call it chain loading unless you're going to 
significantly broaden the definition of chain loading.

In the case of Fedora and Secure Boot, shim.efi loads grubx64.efi, and that 
might be chainloading if grubx64.efi actually replaces shim.efi. I don't know 
if it does, it seems they'd have to be independently located in memory because 
shim.efi needs to confirm/deny the signed status of grubx64.efi before it's 
executed.

In the case of GRUB Legacy chain loading GRUB2 or winload.exe, yeah sure it's 
real mode so code in a 512KB is literally being replaced with read in code. 
That's chain loading.

And in any case, UEFI doesn't rely on boot sectors, let alone block lists. The 
one and only boot loader you choose via the boot manager is expected to be 
capable of reading the file system that contains the kernel and initramfs.


Chris Murphy