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: [email protected]
Internet: http://ts.fujitsu.com
Company Details: http://ts.fujitsu.com/imprint
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 <[email protected]>
SUSE Labs, CR
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
>
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
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: [email protected]
Internet: http://ts.fujitsu.com
Company Details: http://ts.fujitsu.com/imprint
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-
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
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