GRUB and the risk of block list corruption in extX
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
Signature · 13 lines
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,
Quoted 14 lines · Martin Wilck
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".
Quoted 6 lines
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.
Quoted 1 line
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.
Quoted 1 line
3) could it be caused by e4defrag?
If you defrag the image file then yes. But that's obvious I guess.
Quoted 2 lines
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.
Quoted 1 line
5) Anything else?
No, I don't think so.
Quoted 2 lines
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
Signature · 2 lines
Jan Kara <[email protected]> SUSE Labs, CR
Quoted 8 lines · 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."
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
Quoted 24 lines
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
Quoted 8 lines · 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."
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
Quoted 8 lines · Theodore Ts'o
Quoted 3 lines
"
/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
Signature · 13 lines
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