GRUB and the risk of block list corruption in extX

GRUB and the risk of block list corruption in extX

[Martin Wilck]

Hello,

this is a question about the long-running topic of installing GRUB in
partitions or partitionless disks.

Recently I have been involved in discussions about this on
https://bugzilla.redhat.com/show_bug.cgi?id=872826. The Fedora boot
loader can't be installed in partition headers any more. The major
reason given by the Fedora developers is the famous GRUB warning
"blocklists are UNRELIABLE and their use is discouraged."

The Grub manual says "installing to a filesystem means that GRUB is
vulnerable to its blocks being moved around by filesystem features such
as tail packing, or even by aggressive fsck implementations".

I'd like to understand how this blocklist corruption might come to pass
(except for cases where "core.img" itself is moved, deleted, or
overwritten by user space tools). Also, it has been recommended to
prevent accidental corruption by setting the IMMUTABLE flag on core.img,
and I'd like to ask for the GRUB experts' opinion about that.
Finally I'd like to know if it's true that the GRUB team plans to drop
block list support altogether in a future version.

Regards
Martin Wilck

PS: It has been stated that of recent filesystems, this matters most for
extX, because btrfs has a 64k header where embedding GRUB is usually
possible. Therefore I asked a similar question on ext4-devel.



-- 
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering

FUJITSU
Fujitsu Technology Solutions GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn, Germany
Phone:			++49 5251 525 2796
Fax:			++49 5251 525 2820
Email:			martin.wilck@ts.fujitsu.com
Internet:		http://ts.fujitsu.com
Company Details:	http://ts.fujitsu.com/imprint

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

[Martin Wilck]

> herefore I asked a similar question on ext4-devel.

The ext4 developers have made some interesting comments on the subject:
http://thread.gmane.org/gmane.comp.file-systems.ext4/36911On 02/07/2013

Regards
Martin

-- 
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering

FUJITSU
Fujitsu Technology Solutions GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn, Germany
Phone:			++49 5251 525 2796
Fax:			++49 5251 525 2820
Email:			martin.wilck@ts.fujitsu.com
Internet:		http://ts.fujitsu.com
Company Details:	http://ts.fujitsu.com/imprint

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

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

This is not a complete answer but one of my problems is that such requests
don't even suply any kind of reason to go into such installs. We nerd to
consider usecases before even considering using an approach which is known
for some pretty serious problems. Will answer in more details later.
On Feb 7, 2013 11:47 AM, "Martin Wilck" <martin.wilck@ts.fujitsu.com> wrote:

> Hello,
>
> this is a question about the long-running topic of installing GRUB in
> partitions or partitionless disks.
>
> Recently I have been involved in discussions about this on
> https://bugzilla.redhat.com/show_bug.cgi?id=872826. The Fedora boot
> loader can't be installed in partition headers any more. The major
> reason given by the Fedora developers is the famous GRUB warning
> "blocklists are UNRELIABLE and their use is discouraged."
>
> The Grub manual says "installing to a filesystem means that GRUB is
> vulnerable to its blocks being moved around by filesystem features such
> as tail packing, or even by aggressive fsck implementations".
>
> I'd like to understand how this blocklist corruption might come to pass
> (except for cases where "core.img" itself is moved, deleted, or
> overwritten by user space tools). Also, it has been recommended to
> prevent accidental corruption by setting the IMMUTABLE flag on core.img,
> and I'd like to ask for the GRUB experts' opinion about that.
> Finally I'd like to know if it's true that the GRUB team plans to drop
> block list support altogether in a future version.
>
> Regards
> Martin Wilck
>
> PS: It has been stated that of recent filesystems, this matters most for
> extX, because btrfs has a 64k header where embedding GRUB is usually
> possible. Therefore I asked a similar question on ext4-devel.
>
>
>
> --
> Dr. Martin Wilck
> PRIMERGY System Software Engineer
> x86 Server Engineering
>
> FUJITSU
> Fujitsu Technology Solutions GmbH
> Heinz-Nixdorf-Ring 1
> 33106 Paderborn, Germany
> Phone:                  ++49 5251 525 2796
> Fax:                    ++49 5251 525 2820
> Email:                  martin.wilck@ts.fujitsu.com
> Internet:               http://ts.fujitsu.com
> Company Details:        http://ts.fujitsu.com/imprint
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 3302 bytes --]

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

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

This is not a complete answer but one of my problems is that such requests
don't even suply any kind of reason to go into such installs. We nerd to
consider usecases before even considering using an approach which is known
for some pretty serious problems. Will answer in more details later.
On Feb 7, 2013 11:47 AM, "Martin Wilck" <martin.wilck@ts.fujitsu.com> wrote:

[-- Attachment #2: Type: text/html, Size: 503 bytes --]

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

[Martin Wilck]

> This is not a complete answer but one of my problems is that such
> requests don't even suply any kind of reason to go into such installs.
> We nerd to consider usecases before even considering using an approach
> which is known for some pretty serious problems. Will answer in more
> details later.

In my case, the reason is a multiboot setup based on chainloading the
indiviual installed OS's bootloaders from a central, primary bootloader.
This is easily accomplished by installing the individual OS's
bootloaders in their respective "/" or "/boot" partitions. Linux
distributions have encouraged this kind of setup over several years -
"install boot loader in first sector of root/boot partition" used to be
a prominent option somewhere in the installation process (these
distributions were usually GRUB 0.9x based - GRUB 0.9x developers didn't
seem to have a big issue with stage1_5 being loaded via block lists).

Recent GRUB2-based distributions like Fedora have removed this option,
and some users are dissatisfied with that. I would like to understand
what the actual risk is. So I'd appreciate examples for the "pretty
serious problems" you mention.

Regards
Martin


-- 
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering

FUJITSU
Fujitsu Technology Solutions GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn, Germany
Phone:			++49 5251 525 2796
Fax:			++49 5251 525 2820
Email:			martin.wilck@ts.fujitsu.com
Internet:		http://ts.fujitsu.com
Company Details:	http://ts.fujitsu.com/imprint

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

[Lennart Sorensen]

On Fri, Feb 08, 2013 at 06:17:57PM +0100, Martin Wilck wrote:
> In my case, the reason is a multiboot setup based on chainloading the
> indiviual installed OS's bootloaders from a central, primary bootloader.
> This is easily accomplished by installing the individual OS's
> bootloaders in their respective "/" or "/boot" partitions. Linux
> distributions have encouraged this kind of setup over several years -
> "install boot loader in first sector of root/boot partition" used to be
> a prominent option somewhere in the installation process (these
> distributions were usually GRUB 0.9x based - GRUB 0.9x developers didn't
> seem to have a big issue with stage1_5 being loaded via block lists).
> 
> Recent GRUB2-based distributions like Fedora have removed this option,
> and some users are dissatisfied with that. I would like to understand
> what the actual risk is. So I'd appreciate examples for the "pretty
> serious problems" you mention.

grub 2 has a lot more features, is a lot bigger, and might not fit in
your embedding area of some filesystems.

Of course the block list breaks if the file in the filesystem is modified
or moved without updating the block list, which used to break lilo all the
time whenever one forgot to run the lilo command after making a change.
Sure grub 0.9x was a bit less fragile than lilo, but block lists for
files that could potentially be changed is fragile.

Embedding enough of grub in the first track or a boot partition (as EFI
systems support, as do a number of non x86 architectures) gives a much
more reliable system since it can read anything else it needs using the
filesystem and hence doesn't break if files are changed.

-- 
Len Sorensen

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

[Bruce Dubbs]

Lennart Sorensen wrote:
> On Fri, Feb 08, 2013 at 06:17:57PM +0100, Martin Wilck wrote:
>> In my case, the reason is a multiboot setup based on chainloading the
>> indiviual installed OS's bootloaders from a central, primary bootloader.
>> This is easily accomplished by installing the individual OS's
>> bootloaders in their respective "/" or "/boot" partitions. Linux
>> distributions have encouraged this kind of setup over several years -
>> "install boot loader in first sector of root/boot partition" used to be
>> a prominent option somewhere in the installation process (these
>> distributions were usually GRUB 0.9x based - GRUB 0.9x developers didn't
>> seem to have a big issue with stage1_5 being loaded via block lists).
>>
>> Recent GRUB2-based distributions like Fedora have removed this option,
>> and some users are dissatisfied with that. I would like to understand
>> what the actual risk is. So I'd appreciate examples for the "pretty
>> serious problems" you mention.
>
> grub 2 has a lot more features, is a lot bigger, and might not fit in
> your embedding area of some filesystems.
>
> Of course the block list breaks if the file in the filesystem is modified
> or moved without updating the block list, which used to break lilo all the
> time whenever one forgot to run the lilo command after making a change.
> Sure grub 0.9x was a bit less fragile than lilo, but block lists for
> files that could potentially be changed is fragile.
>
> Embedding enough of grub in the first track or a boot partition (as EFI
> systems support, as do a number of non x86 architectures) gives a much
> more reliable system since it can read anything else it needs using the
> filesystem and hence doesn't break if files are changed.

You don't need an EFI system to give GRUB enough space.  You just need 
to partition the drive so the first partition starts at 1MB instead of 
sector 63.  I think using a GPT partition scheme is quite preferred over 
the MSDOS scheme designed 30 years ago.

I will note that this causes problems for some systems, but I haven't 
seen it since I don't do windows.

   -- Bruce

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

[Lennart Sorensen]

On Fri, Feb 08, 2013 at 12:56:52PM -0600, Bruce Dubbs wrote:
> You don't need an EFI system to give GRUB enough space.  You just
> need to partition the drive so the first partition starts at 1MB
> instead of sector 63.  I think using a GPT partition scheme is quite
> preferred over the MSDOS scheme designed 30 years ago.

That's true.  Does grub-install check the partition table to see how much
room there is before placing itself after the MBR?  I haven't checked
that since I tend to use GPT these days.

> I will note that this causes problems for some systems, but I
> haven't seen it since I don't do windows.

-- 
Len Sorensen

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

[Andrey Borzenkov]

В Fri, 8 Feb 2013 13:58:36 -0500
"Lennart Sorensen" <lsorense@csclub.uwaterloo.ca> пишет:

> On Fri, Feb 08, 2013 at 12:56:52PM -0600, Bruce Dubbs wrote:
> > You don't need an EFI system to give GRUB enough space.  You just
> > need to partition the drive so the first partition starts at 1MB
> > instead of sector 63.  I think using a GPT partition scheme is quite
> > preferred over the MSDOS scheme designed 30 years ago.
> 
> That's true.  Does grub-install check the partition table to see how much
> room there is before placing itself after the MBR?

Yes. It even checks whether it has other known software that installs
something in post-MBR gap and can install itself in free space
(assuming it is enough).

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

[Martin Wilck]

On 02/08/2013 07:42 PM, Lennart Sorensen wrote:

> Of course the block list breaks if the file in the filesystem is modified
> or moved without updating the block list, which used to break lilo all the
> time whenever one forgot to run the lilo command after making a change.

True. lilo accessed the conf file itself via block list, IIRC.  The conf
file is typically changed often. GRUB's "core.img", on the contrary,
tends to be pretty static. Moreover, it's usually created using
grub2-install, which runs grub-setup anyway after core.img is rewritten
(thus recreating the block list if necessary).

> Sure grub 0.9x was a bit less fragile than lilo, but block lists for
> files that could potentially be changed is fragile.

"files that could potentially be changed" is important here. As long as
"core.img" itself isn't touched, the risk of the block list being
corrupted is very small; at least that's what the ext4 developers said
on the parallel thread on ext4-devel. The risk can be further reduced
with "chattr +i core.img". Grub 0.9x' stage1_5_* files are 100% static,
and thus practically safe.

> Embedding enough of grub in the first track or a boot partition (as EFI
> systems support, as do a number of non x86 architectures) gives a much
> more reliable system since it can read anything else it needs using the
> filesystem and hence doesn't break if files are changed.

I understand that, but sometimes it's just not enough.

Martin

-- 
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering

FUJITSU
Fujitsu Technology Solutions GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn, Germany
Phone:			++49 5251 525 2796
Fax:			++49 5251 525 2820
Email:			martin.wilck@ts.fujitsu.com
Internet:		http://ts.fujitsu.com
Company Details:	http://ts.fujitsu.com/imprint

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

[Chris Murphy]

On Feb 8, 2013, at 10:17 AM, Martin Wilck <martin.wilck@ts.fujitsu.com> wrote:

>> This is not a complete answer but one of my problems is that such
>> requests don't even suply any kind of reason to go into such installs.
>> We nerd to consider usecases before even considering using an approach
>> which is known for some pretty serious problems. Will answer in more
>> details later.
> 
> In my case, the reason is a multiboot setup based on chainloading the
> indiviual installed OS's bootloaders from a central, primary bootloader.


Why do you specifically want a blocklist method of getting the primary bootloader to load the second? What is your primary bootloader and version? The only reason I can think of that you would need a blocklist, is if your primary bootloader is so old that it doesn't understand the file system the 2nd bootloader is installed on. In the case of Fedora 18, default is /boot on it's own partition, on ext4; so if your primary bootloader understands ext4, it doesn't need a blocklist to load GRUB2. It can directly find and load /boot/grub2/i-386-pc/core.img.

If the primary boot loader is GRUB2, it's capable of reading many file systems, and then finding a distribution specific grub configuration file and consuming it. Even legacy formats.


> Recent GRUB2-based distributions like Fedora have removed this option,
> and some users are dissatisfied with that. 

If the enhancement in bug 886502 were to happen, would this enable your primary boot loader to find either Fedora's grub.cfg, or core.img instead of depending on a blocklist?

https://bugzilla.redhat.com/show_bug.cgi?id=886502

Chris Murphy

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

[Martin Wilck]

Chris,

> Why do you specifically want a blocklist method of getting the primary bootloader to load the second? 

I may have expressed myself unclearly.

What I want is the *secondary* boot loader to be able to load *its own
code* from a partition header (e.g. ext4) using block lists. The primary
boot loader in the setup I prefer is actually embedded in the MBR and
thus doesn't use block lists. It will use "chainloader" command to
access the boot sector of the secondary boot loader (well I guess that's
also a primitve "block list" if you want to see it that way).

> If the primary boot loader is GRUB2, it's capable of reading many
> file systems, and then finding a distribution specific grub
> configuration file and consuming it. Even legacy formats.

Using chainloading has the advantage that the primary bootloader (it's
indeed GRUB 0.9x in my case) doesn't have to understand the more
advanced filesystems of newer distros. It's no problem to boot a btrfs
distro in this way, and when Fedora 31 comes out with KlingonFS as
default filesystem, my stupid Grub 0.9X will still be able to chainload
it, as long as KlingonFS supports embedding a boot loader in its
partition header. Fedora 18's GRUB2 will not be able to do that using a
secondary "grub.cfg", unless someone backports a KlingonFS module for it
(fortunately, GRUB2 would be able to chainload, too).

I like the fact that GRUB2 is able to detect foreign installations and
offer auto-generated boot menu entries for them. But there are some
scenarios for which the primitive chainloading mechanism is better suited.

> If the enhancement in bug 886502 were to happen, would this enable your primary boot loader to find either Fedora's grub.cfg, or core.img instead of depending on a blocklist?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=886502

As long as I install F18 on extX, yes. But as explained above, it
wouldn't be my preferred solution.

Martin

-- 
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering

FUJITSU
Fujitsu Technology Solutions GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn, Germany
Phone:			++49 5251 525 2796
Fax:			++49 5251 525 2820
Email:			martin.wilck@ts.fujitsu.com
Internet:		http://ts.fujitsu.com
Company Details:	http://ts.fujitsu.com/imprint

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

[Chris Murphy]

On Feb 18, 2013, at 10:16 AM, Martin Wilck <martin.wilck@ts.fujitsu.com> wrote:

> Using chainloading has the advantage that the primary bootloader (it's
> indeed GRUB 0.9x in my case) doesn't have to understand the more
> advanced filesystems of newer distros.

Updating your boot loader has the advantage that you don't need two boot loaders to do what one can do. You haven't explained why GRUB2 can't be your primary boot loader.


> It's no problem to boot a btrfs
> distro in this way, and when Fedora 31 comes out with KlingonFS as
> default filesystem, my stupid Grub 0.9X will still be able to chainload
> it, as long as KlingonFS supports embedding a boot loader in its
> partition header.

Effectively you're asking for indefinitely supporting GRUB 0.9, by requiring other dependencies so that can happen.

If GRUB 0.91 hadn't added XFS support explicitly, it would be impossible to boot from XFS using chainloading because XFS doesn't have a boot sector. There's no place to put the blocklist. The way to support booting from new file systems isn't to require those file systems have specific features to enable chainloading, but to keep the boot loader up to date so it knows how to traverse that file system natively.

Chainloading was never a good idea, it was the only idea for supporting multiboot on hardware with a brain dead BIOS that was never designed with multiboot in mind.

> Fedora 18's GRUB2 will not be able to do that using a
> secondary "grub.cfg", unless someone backports a KlingonFS module for it
> (fortunately, GRUB2 would be able to chainload, too).

This is such a nonsense, red herring argument. There aren't new file systems popping up every 6-12 months. And who cares about Fedora 18's GRUB2 in another 6 years when there is yet another new file system? It should have been upgraded or replaced well before then.

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. Not making it easier to do.

> 
> I like the fact that GRUB2 is able to detect foreign installations and
> offer auto-generated boot menu entries for them. But there are some
> scenarios for which the primitive chainloading mechanism is better suited.

Name something you can only do via chainloading that you cannot do by keeping a singular primary boot loader up-to-date.

And then state why 'grub2-install --force' on your own is inadequate. Why should GUI installers literally encourage users to not upgrade their primary boot loader? That objectively seems like a bad idea to me, bad advice. If people want to enable a fundamentally flawed workflow like chainloading, nothing prevents it. The tools are there, right now, to let you do what you want. But to make it easy for the typical user who has no idea what a bad idea it is to be using a 6 year old unmaintained, unsupport boot loader, is like giving them razor blades and telling them to go play on the free way. It's cruel. And it's bad advice.

> 
>> If the enhancement in bug 886502 were to happen, would this enable your primary boot loader to find either Fedora's grub.cfg, or core.img instead of depending on a blocklist?
>> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=886502
> 
> As long as I install F18 on extX, yes. But as explained above, it
> wouldn't be my preferred solution.

I find the explanation uncompelling. If you find GRUB2 overly bloated and complicated, then maybe you shouldn't expect your boot loader to boot from new file systems; this isn't a required workflow. There's nothing wrong with bootfs on FAT32 or ext[234] with syslinux or extlinux, i.e. the kernel and initramfs go there, and then placing rootfs on the more advanced file system.


Chris Murphy

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

[Andrey Borzenkov]

On Tue, Feb 19, 2013 at 1:07 AM, Chris Murphy <lists@colorremedies.com> wrote:
>
> Chainloading was never a good idea, it was the only idea for supporting multiboot on hardware with a brain dead BIOS that was never designed with multiboot in mind.
>

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 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. You do not go
and run os-prober in chroot on every other Linux you may have when you
install additional kernel.

I have test VM with Windows/Fedora/openSUSE. I installed openSUSE
after Fedora. Wanna guess if openSUSE kerenls are present in Fedora
grub.cfg?

> 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.

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

> 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".

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

[Chris Murphy]

On Feb 18, 2013, at 10:02 PM, Andrey Borzenkov <arvidjaar@gmail.com> 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

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

[Michael Chang]

2013/2/19 Chris Murphy <lists@colorremedies.com>:
>
> On Feb 18, 2013, at 10:02 PM, Andrey Borzenkov <arvidjaar@gmail.com> 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.

This is based on assumption that all foreign distribution must
maintain a grub.cfg which is not true.  If they offer options of other
bootloader than grub2 why bother them to maintain grub.cfg ?

>
>> 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.

Some people who use standard mbr boot code to manage their booting,.
The reason they would like to keep that old practice is they don't
want to bet their destiny on any primary bootloader of any
distribution as it fails for whatever reasons would render your entire
system un-bootable. They could still booting to other distribution via
togging the active flag and perform the rescue of data.

In this case they require grub2 be chainloaded as secondary bootloader
not the master one.

Regards,
Michael

>>
>> 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
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

On 19.02.2013 09:43, Michael Chang wrote:

>  They could still booting to other distribution via
> togging the active flag and perform the rescue of data.

If they have the ability to toggle this flag, why don't they have the
ability to simply reinstall bootloader?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

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

[Chris Murphy]

On Feb 19, 2013, at 1:43 AM, Michael Chang <mchang@suse.com> wrote:

> 2013/2/19 Chris Murphy <lists@colorremedies.com>:
>> 
>> 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.
> 
> This is based on assumption that all foreign distribution must
> maintain a grub.cfg which is not true.

The context was GRUB, so yes I'm assuming GRUB configuration files in this case. But GRUB2 can still do what most other boot loaders can't which is read pretty much any common file system out there, and even find boot files on md raid and lvm. It can chain load the distribution's unique boot loader by reading the file system its on. Blocklists, VBR boot sectors, are still not needed.

>  If they offer options of other
> bootloader than grub2 why bother them to maintain grub.cfg ?

I'm not suggesting that distributions be required to play nice in the multiboot sandbox. But if they want to be cooperative, they might actually have to cooperate somehow. Doesn't seem totally surprising to me.

>> Name something you can only do via chainloading that you cannot do by keeping a singular
>> primary boot loader up-to-date.

> Some people who use standard mbr boot code to manage their booting,.

> The reason they would like to keep that old practice is they don't
> want to bet their destiny on any primary bootloader of any
> distribution as it fails for whatever reasons would render your entire
> system un-bootable. They could still booting to other distribution via
> togging the active flag and perform the rescue of data.

It meets my vague and loose requirements, but the failure is an edge case. And it's fine there are tools that help people with their edge cases. But this work around to regain bootability requires esoteric knowledge on the part of the user (in addition to being an edge case for it to occur). The probability of both happening at the same time, is low. I don't think this is a case of good design. There's also still a single point of failure, LBA0. It's not as if the risk of rewriting those 512 bytes is zero, just to change the active flag. I don't see how the probability of boot loader failure is meaningfully reduced.


Chris Murphy

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

[Martin Wilck]

Chris,

> Effectively you're asking for indefinitely supporting GRUB 0.9, by requiring other dependencies so that can happen.

The only other dependency I am asking for is the ability for the distro
boot loader to be installed in the root or boot partition. That's not much.

The biggest argument for Fedora not being able to do this has been the
claimed danger of block list corruption. I started this thread in order
to clarify what this warning about fragility actually means, and what
the actual risk scenario is.

That's the only aspect of this discussion that is worth bothering the
GRUB developers with. The validity of my use case should be discussed
elsewhere.

Martin

-- 
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering

FUJITSU
Fujitsu Technology Solutions GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn, Germany
Phone:			++49 5251 525 2796
Fax:			++49 5251 525 2820
Email:			martin.wilck@ts.fujitsu.com
Internet:		http://ts.fujitsu.com
Company Details:	http://ts.fujitsu.com/imprint

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

[Chris Murphy]

On Feb 19, 2013, at 1:47 AM, Martin Wilck <martin.wilck@ts.fujitsu.com> wrote:

> Chris,
> 
>> Effectively you're asking for indefinitely supporting GRUB 0.9, by requiring other dependencies so that can happen.
> 
> The only other dependency I am asking for is the ability for the distro
> boot loader to be installed in the root or boot partition. That's not much.

You're asking for more than you apparently realize. You said you wanted to be able to support KlingonFS, but your idea can't do this alone. I already used XFS as a real example file system that will not be bootable using your idea, and I see it as conclusive proof of a fundamentally broken concept.

If you want new file systems to support booting, then the primary boot loader needs to be able to understand that file system. 

Next, your idea requires the installer UI code to check the target file system before installing the boot loader. Every file system has a different location for this blocklist or boot loader code, there is no standardization. And in the case of XFS, this test fails and now you need extra UI code to indicate to the user that installing to an XFS partition isn't supported. And you need code that warns the user that even though a boot loader is being installed, that the installed system won't be bootable out of the box because the 1st boot loader doesn't know about the 2nd.

And all of this needs to be tested.

Instantly you're talking about *dozens* of people, dozens of hours of coding and testing. And this is because you don't want to type grub2-install --force. I don't understand how you think a GUI installer enabled to install in root/boot is "not much" and yet for you to type --force is too much?


> The biggest argument for Fedora not being able to do this has been the
> claimed danger of block list corruption.

The biggest argument is:
https://bugzilla.redhat.com/show_bug.cgi?id=872826#c10

> That's the only aspect of this discussion that is worth bothering the
> GRUB developers with. The validity of my use case should be discussed
> elsewhere.

anaconda-devel-list@redhat.com


Chris Murphy

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

[Martin Wilck]

On 02/19/2013 07:56 PM, Chris Murphy wrote:

>> The biggest argument for Fedora not being able to do this has been the
>> claimed danger of block list corruption.

> The biggest argument is:
> https://bugzilla.redhat.com/show_bug.cgi?id=872826#c10

Sorry, I see nothing in that comment that I'd call an argument.

>> That's the only aspect of this discussion that is worth bothering the
>> GRUB developers with. The validity of my use case should be discussed
>> elsewhere.
> 
> anaconda-devel-list@redhat.com

Well I'd rather follow up on bugzilla. Apologies to everyone that the
discussion went off-topic for this list.

Martin
-- 
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering

FUJITSU
Fujitsu Technology Solutions GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn, Germany
Phone:			++49 5251 525 2796
Fax:			++49 5251 525 2820
Email:			martin.wilck@ts.fujitsu.com
Internet:		http://ts.fujitsu.com
Company Details:	http://ts.fujitsu.com/imprint

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]

I haven't gone through this whole thread yet but this is one of problems
with blocklist installs:
Suppose blocklist changes because of e.g. user mistake. Yet at the old
location there is still the old core.img. For the time being. So this
problem may go unnoticed for years yet if someone has the ability to
create new files on the disk in question, he creates ton of files with
copies of malicious sector, one of them will overwrite core and be
executed on next reboot.
This is a securitxy problem coming from the fact that in normal
environment blocklists are abstracted away into files and are no longer
either visible or considered, yet they are still manipulated. embedding
zone doesn't have this problem since it's by definition never manipulated.
Another trouble is that ext4 devs control only their own implementation.
But there are several more floating around. Once we had problems because
hurd ext2 behaviour is different from Linux one. Additionally, as long
as behaviour of not modifying blocklists of core.img isn't specified as
official implementations which would do so (specifically the cow
flavours) are within their rights.
It's possible to add ext4 parsing to boot sector but it's not sure that
it will be maintainable in face of new ext* features.
A possibility is to use 2 unused sectors in front of ext* to store
initial stage but it doesn't help if embedding isn't available for other
reasons than installing to partition.
Having embedded zone described by an inode is unusual but is usable as
long as:
1) special sector allocation. It must be (at least, preferably more)
4K-aligned (necessary for supporting 4K-sector disks) and contiguous.
Either:
2a) miniature parser in boot.S to find this file. Greatly simplified if
inode is fixed, since fs parameters are fixed it would be a
straightforward of value read.
2b) immutability of blocklist. This also implies that this file can't be
shrunk or deleted.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

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

[Martin Wilck]

Vladimir,

thanks for your thoughtful answer. I understand your concerns better now.

On 02/19/2013 10:37 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> Suppose blocklist changes because of e.g. user mistake. Yet at the old
> location there is still the old core.img. For the time being. So this
> problem may go unnoticed for years yet if someone has the ability to
> create new files on the disk in question, he creates ton of files with
> copies of malicious sector, one of them will overwrite core and be
> executed on next reboot.

Am I understanding correctly that the user mistake you describe must be
some manipulation of "core.img" itself (e.g. running grub2-mkimage but
now grub2-setup, which would classify as "mistake" in a blocklist setup)?

Martin

-- 
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering

FUJITSU
Fujitsu Technology Solutions GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn, Germany
Phone:			++49 5251 525 2796
Fax:			++49 5251 525 2820
Email:			martin.wilck@ts.fujitsu.com
Internet:		http://ts.fujitsu.com
Company Details:	http://ts.fujitsu.com/imprint

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

On 19.02.2013 13:58, Martin Wilck wrote:

> Vladimir,
> 
> thanks for your thoughtful answer. I understand your concerns better now.
> 
> On 02/19/2013 10:37 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> 
>> Suppose blocklist changes because of e.g. user mistake. Yet at the old
>> location there is still the old core.img. For the time being. So this
>> problem may go unnoticed for years yet if someone has the ability to
>> create new files on the disk in question, he creates ton of files with
>> copies of malicious sector, one of them will overwrite core and be
>> executed on next reboot.
> 
> Am I understanding correctly that the user mistake you describe must be
> some manipulation of "core.img" itself (e.g. running grub2-mkimage but
> now grub2-setup, which would classify as "mistake" in a blocklist setup)?

Yes. Such kind of mistakes. Or deleting GRUB and restoring it from backup.

> 
> Martin
> 




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

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

[Martin Wilck]

>> Am I understanding correctly that the user mistake you describe must be
>> some manipulation of "core.img" itself (e.g. running grub2-mkimage but
>> now grub2-setup, which would classify as "mistake" in a blocklist setup)?
> 
> Yes. Such kind of mistakes. Or deleting GRUB and restoring it from backup.

I agree that this is a serious scenario that everybody using block lists
should be wary about.

But I am not fully convinced that it justfies the strong warning
grub2-setup emits, let alone the conclusions the Fedora team drew from
it. After all, this scenario requires the user to make a serious mistake
as root, and we all know that this can have all kinds of really bad
consequences.

AFAICS, for extX/Linux at least, there is no risk scenario that doesn't
involve this kind of serious user mistake.

Martin

-- 
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering

FUJITSU
Fujitsu Technology Solutions GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn, Germany
Phone:			++49 5251 525 2796
Fax:			++49 5251 525 2820
Email:			martin.wilck@ts.fujitsu.com
Internet:		http://ts.fujitsu.com
Company Details:	http://ts.fujitsu.com/imprint

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

[Andrey Borzenkov]

On Thu, Feb 7, 2013 at 2:47 PM, Martin Wilck
<martin.wilck@ts.fujitsu.com> wrote:
> Hello,
>
Hi Martin

> this is a question about the long-running topic of installing GRUB in
> partitions or partitionless disks.
>
> Recently I have been involved in discussions about this on
> https://bugzilla.redhat.com/show_bug.cgi?id=872826. The Fedora boot
> loader can't be installed in partition headers any more. The major
> reason given by the Fedora developers is the famous GRUB warning
> "blocklists are UNRELIABLE and their use is discouraged."
>
> The Grub manual says "installing to a filesystem means that GRUB is
> vulnerable to its blocks being moved around by filesystem features such
> as tail packing, or even by aggressive fsck implementations".
>
> I'd like to understand how this blocklist corruption might come to pass
> (except for cases where "core.img" itself is moved, deleted, or
> overwritten by user space tools). Also, it has been recommended to
> prevent accidental corruption by setting the IMMUTABLE flag on core.img,
> and I'd like to ask for the GRUB experts' opinion about that.
> Finally I'd like to know if it's true that the GRUB team plans to drop
> block list support altogether in a future version.
>


I think this is simply the wrong question for upstream. The primary
consideration is, what happens inside filesystem is outside of grub
scope, so grub simply cannot commit itself to saying "it's fine and we
support it everywhere". Because grub has no control over what happens.

If you are sure in your environment corruption cannot happen (e.g.
because you use filesystem that is known to be not susceptible to such
corruption) then by all means do it.

grub2 does not stop you from doing it. It just wants you to do it consciously :)

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

[Martin Wilck]

Andrey,

> I think this is simply the wrong question for upstream. The primary
> consideration is, what happens inside filesystem is outside of grub
> scope, so grub simply cannot commit itself to saying "it's fine and we
> support it everywhere". Because grub has no control over what happens.

But isn't the question about a real world corruption scenario legitimate
nonetheless? And who else but the GRUB developers would be able to
answer it?

Upstream possibly underestimates the unsettledness that the strong
wording of grub2-install's warning and the constraint to allow block
lists only with "--force" has caused among users and other developers.
The Fedora developers took this warning so seriously that the option of
installing anywhere else but in the MBR has been removed from the installer.

> grub2 does not stop you from doing it. It just wants you to do it
> consciously :)

Good :)

Martin


-- 
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering

FUJITSU
Fujitsu Technology Solutions GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn, Germany
Phone:			++49 5251 525 2796
Fax:			++49 5251 525 2820
Email:			martin.wilck@ts.fujitsu.com
Internet:		http://ts.fujitsu.com
Company Details:	http://ts.fujitsu.com/imprint

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

[Andrey Borzenkov]

В Thu, 07 Feb 2013 11:47:33 +0100
Martin Wilck <martin.wilck@ts.fujitsu.com> пишет:

> Hello,
> 
> this is a question about the long-running topic of installing GRUB in
> partitions or partitionless disks.
> 

Here is example how using filesystem blocklists may lead to unbootable
system without any extX corruption involved.

- user sets up multiboot system with Windows as primary bootloader
- standard technique to add Linux loaders has always been - copy
  partition boot sector and "launch" it from Windows loader
- user copies Linux partition boot sector which points to core.imng
  absolute disk position
- user updates grub in Linux. core.img is rewritten and its position
  changes
- next time user tries to boot Linux (s)he gets blinking cursor

So *any* third party bootloader that relies on being able to
"chainload" *copy* of boot sector will give you the same issue.

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

[Martin Wilck]

Andrey,

> Here is example how using filesystem blocklists may lead to unbootable
> system without any extX corruption involved.
> 
> - user sets up multiboot system with Windows as primary bootloader
> - standard technique to add Linux loaders has always been - copy
>   partition boot sector and "launch" it from Windows loader
> - user copies Linux partition boot sector which points to core.imng
>   absolute disk position
> - user updates grub in Linux. core.img is rewritten and its position
>   changes
> - next time user tries to boot Linux (s)he gets blinking cursor
> 
> So *any* third party bootloader that relies on being able to
> "chainload" *copy* of boot sector will give you the same issue.

I understand. It's generally understood that updating core.img without
updating the boot sector is a bad idea. In this particular case updating
the boot sector is not enough because the copy needs to be updated, too.

The background for my question was a different scenario, with a
chainload-capable boot loader in the MBR and secondary boot loaders in
partition boot sectors. It is that scenario that the new anaconda
installer doesn't support any more, and the major argument from the
Fedora devs for this (apart from sparing dev and QA resources) was the
warning emitted by GRUB when users try to install using block lists.

I am still convinced that the risk of boot loader corruption in that
scenario is extremely low.

Martin

-- 
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering

FUJITSU
Fujitsu Technology Solutions GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn, Germany
Phone:			++49 5251 525 2796
Fax:			++49 5251 525 2820
Email:			martin.wilck@ts.fujitsu.com
Internet:		http://ts.fujitsu.com
Company Details:	http://ts.fujitsu.com/imprint

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

[Dr. Tilmann Bubeck]

There is a solution under way. Linux 3.10 will include code written by 
me to secure core.img of grub when running from ext4. This means, that 
ext4 will be as safe to use for grub chainloading as btrfs or any other 
filesystem offering "embedding".

I am currently extending grub-setup.c to use this new functionality. I 
will send a patch to this list in a few days. Hopefully you can apply 
this patch, so that this issue will be fixed.

Kind regards,
  Till


Am 03.05.2013 10:21, schrieb Martin Wilck:
> Andrey,
>
>> Here is example how using filesystem blocklists may lead to unbootable
>> system without any extX corruption involved.
>>
>> - user sets up multiboot system with Windows as primary bootloader
>> - standard technique to add Linux loaders has always been - copy
>>    partition boot sector and "launch" it from Windows loader
>> - user copies Linux partition boot sector which points to core.imng
>>    absolute disk position
>> - user updates grub in Linux. core.img is rewritten and its position
>>    changes
>> - next time user tries to boot Linux (s)he gets blinking cursor
>>
>> So *any* third party bootloader that relies on being able to
>> "chainload" *copy* of boot sector will give you the same issue.
>
> I understand. It's generally understood that updating core.img without
> updating the boot sector is a bad idea. In this particular case updating
> the boot sector is not enough because the copy needs to be updated, too.
>
> The background for my question was a different scenario, with a
> chainload-capable boot loader in the MBR and secondary boot loaders in
> partition boot sectors. It is that scenario that the new anaconda
> installer doesn't support any more, and the major argument from the
> Fedora devs for this (apart from sparing dev and QA resources) was the
> warning emitted by GRUB when users try to install using block lists.
>
> I am still convinced that the risk of boot loader corruption in that
> scenario is extremely low.
>
> Martin
>


-- 
+-------+-------------------------------------------------------------+
|       | dr. tilmann bubeck               reinform medien- und       |
|       |                                  informationstechnologie AG |
| rein  | fon  : +49 (711) 7 82 76-52      loeffelstr. 40             |
| form  | fax  : +49 (711) 7 82 76-46      70597 stuttgart / germany  |
|    AG | cell.: +49 (172) 8 84 29 72      fon: +49 (711) 75 86 56-10 |
|       | email: t.bubeck@reinform.de      http://www.reinform.de     |
|       +-------------------------------------------------------------+
|       | pflichtangaben nach paragraph 80, AktG:                     |
|       | reinform medien- und informationstechnologie AG, stuttgart  |
|       | handelsregister stuttgart, HRB 23001                        |
|       | vorstand:     dr. tilmann bubeck (vorsitz)                  |
|       | aufsichtsrat: frank stege (vorsitz)                         |
+-------+-------------------------------------------------------------+