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

[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]

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

[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

[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

[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

[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

[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

[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]

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

[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

[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

[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

[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)                         |
+-------+-------------------------------------------------------------+

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

[Eric Sandeen]

On 2/9/13 6:17 PM, Chris Murphy wrote:
> 
> On 2013-02-07 15:50:07 GMT Eric Sandeen wrote:
> 
>> To be clear, this is only the case when installing the bootloader
>> itself to a partition containing a filesystem, not when installing
>> to the MBR, correct?
> 
> Correct.
> 
>> Which is different than saying "/boot is on ext4" - it's putting
>> the bootloader itself on a partition containing a filesystem,
>> something which is a bit more unusual, I think.
> 
> Some users apparently want distribution specific boot loaders as
> secondary, chain loaded from a primary boot loader that goes in the
> MBR gap.
> 

Understood, just didn't want this to turn into a "grub2 doesn't work
on ext4?!" meme.  :)

Thanks,
-Eric

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

[Theodore Ts'o]

On Sat, Feb 09, 2013 at 05:17:58PM -0700, Chris Murphy wrote:
> On the other hand…
> 
> > There are some folks who are proposing that we use a bootloader inode:
> > for grub's benefit. 
> 
> Who are requesting this? If not GRUB's devs, it would seem there are
> other developers who are also paranoid.

Well, it was one of the participants (or observers) of 

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

He posted on the linux-ext4 list a week or so ago:

    http://comments.gmane.org/gmane.comp.file-systems.ext4/36637

> > But it's not something that has been terribly high priority, since
> > it's basically more of a security blanket for the grub2 developers
> > more than anything else….
> 
> It may be a security blanket for grub2 developers. However, it
> appears to me users want a security blanket also.

Well, a participant of on the redhat bugzilla inquired about it.

If someone wants to send me some patches, I'm happy to review them.  I
personally think it's not a great use of time, but that's the
wonderful thing about open source.  You can always send patches.  :-)

> Despite my bias against two bootloaders (I think it's ridiculous,
> but then I prefer 1/2 a boot loader), the question I have is if a
> blocklist is really needed to find and load the 2nd boot loader?
> Because needing a blocklist in the VBR implies the first boot loader
> doesn't understand ext(4). If true, before engineering file system
> changes, users need to upgrade their ancient primary boot loader.

It's been a long time since I really spent a lot of time studying
grub, but my understanding is that the first boot loader (which fits
in the MBR) is just too small to have room to understand the ext[234]
file system; you can't really do a lot in 492 bytes of x86
assembly.....  That's why it uses a block list instead.

But honestly, I really don't care a whole lot about the emotional
insecurity of the grub2 developers, and if distributions are worried
about their users being insecure, they can always comment out the
alarmist message in grub2.  Or they can send me patches.  :-)

	 	    	       	    	     - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Chris Murphy]

On 2013-02-07 15:50:07 GMT Eric Sandeen wrote:

> To be clear, this is only the case when installing the bootloader itself to a partition containing a filesystem, not when installing to the MBR, correct?

Correct.

> Which is different than saying "/boot is on ext4" - it's putting the bootloader itself on a partition containing a filesystem, something which is a bit more unusual, I think.

Some users apparently want distribution specific boot loaders as secondary, chain loaded from a primary boot loader that goes in the MBR gap.



On 2013-02-07 20:53:35 GMT Theodore Ts'o wrote:

> This only happens if grub2 can't install itself in the space between the MBR and the beginning of the first partition.

The message also happens when the user explicitly requests grub-install to "install to a partition" instead of to the MBR gap, on ext.

grub-install /dev/sda1

instead of

grub-install /dev/sda

There are different behaviors depending on file system: Not allowed at all on XFS (with or without --force); only possible with --force on ext; only possible without --force on btrfs.


> I think the grub2 developers are being far too paranoid.


Possibly. On the one hand syslinux/extlinus works in a similar way to GRUB's --force option creating a blocklist, although I'm not familiar enough with extlinux to know if there's a significant difference.

On the other hand…

> There are some folks who are proposing that we use a bootloader inode:
> for grub's benefit. 

Who are requesting this? If not GRUB's devs, it would seem there are other developers who are also paranoid.

> But it's not something that has been terribly high priority, since it's basically more of a security blanket for the grub2 developers more than anything else….

It may be a security blanket for grub2 developers. However, it appears to me users want a security blanket also. 

Users can do what they want now, with existing tools. The bug report details the two simple commands to enable this, but some users find that inadequate. What they really want is a GUI switch in their OS installer to do this for them, and would be managed by fulfilling RH BZ 886502 (related bug to the OP's cited bug).

Despite my bias against two bootloaders (I think it's ridiculous, but then I prefer 1/2 a boot loader), the question I have is if a blocklist is really needed to find and load the 2nd boot loader? Because needing a blocklist in the VBR implies the first boot loader doesn't understand ext(4). If true, before engineering file system changes, users need to upgrade their ancient primary boot loader.

GRUB legacy 5+ years ago (and extlinux) can "chain" load to GRUB 2 by directly reading ext, and locate /boot/grub2/i386-pc/core.img; even if it is fragmented, even if aggressive fsck, or online defragmenting is performed. The only thing the blocklist does is point to core.img, the thing that's normally in the MBR gap (or BIOS Boot partition on GPT).

And GRUB2 as a primary bootloader goes a step easier which is it can find, load, display and execute distribution specific grub configuration files, both current and legacy formats. It's not even necessary to chain load from GRUB2 to GRUB1 or 2.

So I don't actually understand what the request really is for, it seems there are multiple other ways of arriving at the goal, and the request for blocklist safety and boot loader inodes is uncompelling. 

Maybe increasing ext's VBR is useful since GRUB and extlinux already have code to leverage that method of embedding for btrfs, which has a 64KB pad at the start (vs ext's 1KB). But even here I'm skeptical of the need.


Chris Murphy--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Martin Wilck]

On 02/07/2013 09:53 PM, Theodore Ts'o wrote:

>>   "/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be
>>   installed in this setup by using blocklists. However, blocklists are
>>   UNRELIABLE and their use is discouraged."
> 
> This only happens if grub2 can't install itself in the space between
> the MBR and the beginning of the first partition.  So in practice,
> most people won't see this unless they install the root partition on
> the whole disk, or perhaps for disks with GUUID partition tables.

It happens when you try to install the boot loader directly in the start
sector of the root or boot partition. That's an option that many Linux
distributions have been offering their users for multiboot support in
the past, and which some people find pracital for multiboot systems.

Thanks a lot,
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

[Theodore Ts'o]

On Thu, Feb 07, 2013 at 11:18:30AM +0100, Martin Wilck wrote:
> Hello,
> 
> you may have seen the following warning that is displayed when
> someone tries to install GRUB2 on in a extX partition:
> 
>   "/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be
>   installed in this setup by using blocklists. However, blocklists are
>   UNRELIABLE and their use is discouraged."

This only happens if grub2 can't install itself in the space between
the MBR and the beginning of the first partition.  So in practice,
most people won't see this unless they install the root partition on
the whole disk, or perhaps for disks with GUUID partition tables.

I think the grub2 developers are being far too paranoid.  In practice,
ext4 doesn't move blocks around.  If you create a file and then mark
the it as immutable, it should be pretty much safe.  Yes, if you do an
off-line shrink (or in some vary rare cases, an off-line resize2fs
expand operation) it's possible that the file blocks might get moved,
but that's a pretty rare case.

There are some folks who are proposing that we use a bootloader inode:

#define EXT2_BOOT_LOADER_INO  5	       /* Boot loader inode */

for grub's benefit.  It doesn't really make things any safer from a
block relocation perspective, but maybe since it's "official", maybe
it would make the grub2 developers feel better.  But it's not
something that has been terribly high priority, since it's basically
more of a security blanket for the grub2 developers more than anything
else....

						- Ted

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

[Eric Sandeen]

On 2/7/13 4:18 AM, Martin Wilck wrote:
> Hello,
> 
> you may have seen the following warning that is displayed when
> someone tries to install GRUB2 on in a extX partition:
> 
>   "/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be
>   installed in this setup by using blocklists. However, blocklists are
>   UNRELIABLE and their use is discouraged."

To be clear, this is only the case when installing the bootloader itself to
a partition containing a filesystem, not when installing to the MBR, correct?

Which is different than saying "/boot is on ext4" - it's putting the bootloader
itself on a partition containing a filesystem, something which is a bit more
unusual, I think.

-Eric

> Recently I have been involved in discussions about this on
> https://bugzilla.redhat.com/show_bug.cgi?id=872826.
> 
> 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".
> 
> My question to the extX experts: Under what circumstances (except
> modifying, overwriting, deleting the bootloader image "core.img" itself)
> can a block list referencing "core.img" be corrupted? In particular:
> 
>  1) could it happen during ordinary operation, filesystem code silently
>    moving blocks around?
>  2) could it happen in an e2fsck run?
>  3) could it be caused by e4defrag?
>  4) could it happen with resize2fs even if the blocks occupied by the
> file fit in the size that the FS is resized to (otherwise obviously "yes")?
>  5) Anything else?
>  6) if the file was protected with the IMMUTABLE flag, would any of 1-5
> still be able to corrupt the file?
> 
> Regards
> Martin
> 

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

[Jan Kara]

  Hello,

On Thu 07-02-13 11:18:30, Martin Wilck wrote:
> you may have seen the following warning that is displayed when
> someone tries to install GRUB2 on in a extX partition:
> 
>   "/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be
>   installed in this setup by using blocklists. However, blocklists are
>   UNRELIABLE and their use is discouraged."
> 
> Recently I have been involved in discussions about this on
> https://bugzilla.redhat.com/show_bug.cgi?id=872826.
> 
> 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".
> 
> My question to the extX experts: Under what circumstances (except
> modifying, overwriting, deleting the bootloader image "core.img" itself)
> can a block list referencing "core.img" be corrupted? In particular:
> 
>  1) could it happen during ordinary operation, filesystem code silently
>    moving blocks around?
  No.

>  2) could it happen in an e2fsck run?
  Yes, if there is some corruption found. But then all bets are off anyway.
I.e. if fsck in -p (preen) mode fails, you have to rerun grub after fixing
the fs.

>  3) could it be caused by e4defrag?
  If you defrag the image file then yes. But that's obvious I guess.

>  4) could it happen with resize2fs even if the blocks occupied by the
> file fit in the size that the FS is resized to (otherwise obviously "yes")?
  If you do offline resize and we need to grow number of group descriptor
blocks it may happen we move around blocks. For online resize we only allow
to resize upto the amount of reserved descriptor blocks so there it cannot
happen. Shrinking should be safe unless the file is in the part of
filesystem that is being removed.

>  5) Anything else?
  No, I don't think so.

>  6) if the file was protected with the IMMUTABLE flag, would any of 1-5
> still be able to corrupt the file?
  IMMUTABLE flag has no impact on these.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

GRUB and the risk of block list corruption in extX

[Martin Wilck]

Hello,

you may have seen the following warning that is displayed when
someone tries to install GRUB2 on in a extX partition:

  "/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be
  installed in this setup by using blocklists. However, blocklists are
  UNRELIABLE and their use is discouraged."

Recently I have been involved in discussions about this on
https://bugzilla.redhat.com/show_bug.cgi?id=872826.

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

My question to the extX experts: Under what circumstances (except
modifying, overwriting, deleting the bootloader image "core.img" itself)
can a block list referencing "core.img" be corrupted? In particular:

 1) could it happen during ordinary operation, filesystem code silently
   moving blocks around?
 2) could it happen in an e2fsck run?
 3) could it be caused by e4defrag?
 4) could it happen with resize2fs even if the blocks occupied by the
file fit in the size that the FS is resized to (otherwise obviously "yes")?
 5) Anything else?
 6) if the file was protected with the IMMUTABLE flag, would any of 1-5
still be able to corrupt the file?

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