linux-ext4 - Re: [PATCH e2fsprogs] Add ZFS detection to libblkid

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 07 Apr 2009 00:40:33 -0700
From:	Andreas Dilger <adilger@....com>
To:	"Ricardo M. Correia" <Ricardo.M.Correia@....com>
Cc:	Eric Sandeen <sandeen@...hat.com>, "Theodore Ts'o" <tytso@....edu>,
	linux-ext4@...r.kernel.org, Karel Zak <kzak@...hat.com>
Subject: Re: [PATCH e2fsprogs] Add ZFS detection to libblkid

On Apr 06, 2009  20:22 +0100, Ricardo Correia wrote:
> On Sáb, 2009-04-04 at 15:25 -0600, Andreas Dilger wrote:
> > I _suppose_ there is no hard requirement that the ub_magic is present in
> > the first überblock slot at 128kB, but that does make it harder to find.
> > In theory we would need to add 256 magic value checks, which seems
> > unreasonable.  Ricardo, do you know why the zfs.img.bz2 has bad überblocks
> > for the first 4 slots?
> 
> Your supposition is correct - there's no requirement that the first
> uberblock that gets written to the uberblock array has to be in the
> first slot.
> 
> The reason that this image has bad uberblocks in the first 4 slots is
> that, in the current ZFS implementation, when you create a ZFS pool, the
> first uberblock that gets written to disk has txg number 4, and the slot
> that gets chosen for each uberblock is "txg_nr % nr_of_uberblock_slots".
> 
> So in fact, it's not that the first 4 uberblocks are bad, it's just that
> the first 4 slots don't have any uberblocks in them yet.
> 
> However, even though currently it's txg nr 4 that gets written first,
> this is an implementation-specific detail that we cannot (or should not)
> rely upon.

So my proposal to check the 0th, 4th, and 8th überblock in both
the first and second VDEV label should be pretty safe.

> BTW, I also agree that it would be useful for ext3's mkfs to zero-out
> the first and last 512 KB of the partition, to get rid of the ZFS labels
> and magic values, although if it detects these magic values, it would be
> quite useful for mkfs to refuse to format the partition, forcing the
> user to specify some "--force" flag (like "zpool create" does), or at
> least ask the user for confirmation (if mkfs is being used in
> interactive mode), to avoid accidental data destruction.
> 
> If this is not done, then maybe leaving the ZFS labels intact could be
> better, so that the user has a chance to recover (some/most) of it's
> data, in case he made a mistake.

Well, if ZFS is currently using this filesystem, then the kernel will
have the block device open O_EXCL, which will prevent the mkfs from
happening.

Whether it will be a feature to "--force" mkfs to overwrite an ext3
superblock or ZFS superblock is questionable.  The problem with needing
"--force" is that people tend to hard-code this into their scripts
(so that their script always works) and then due to only having a single
"--force" flag it also forces other, possibly more destructive, behaviour
(e.g. --force is needed to mke2fs on a file so that it can be mounted
via loopback, but will also force mke2fs on a filesystem that actually
IS in use, etc).

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

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