lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <5113CD2F.9010908@redhat.com> Date: Thu, 07 Feb 2013 09:50:07 -0600 From: Eric Sandeen <sandeen@...hat.com> To: Martin Wilck <martin.wilck@...fujitsu.com> CC: linux-ext4@...r.kernel.org Subject: Re: GRUB and the risk of block list corruption in extX 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists