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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 04 Apr 2009 15:25:07 -0600
From:	Andreas Dilger <adilger@....com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	"Ricardo M. Correia" <Ricardo.M.Correia@....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 04, 2009  08:04 -0500, Eric Sandeen wrote:
> And from another report, another user's zfs partition:
> 
> # hexdump -C first_400K | grep "0c b1 07 b0 f5 02 00 00"
> # hexdump -C first_400K | grep "00 00 02 f5 b0 07 b1 0c"
> # hexdump -C first_400K | grep "0c b1 ba 00"
> 00015e30  30 e8 ff ff 85 c0 5b 75  48 8b 06 35 0c b1 ba 00
> 
> Should we be looking for 0x00babloc at offset 00015e30?

In probe.c I see the magic (that I've been assuming is correct, because
it isn't really that easy to read):

  { "zfs",       8,      0,  8, "\0\0\x02\xf5\xb0\x07\xb1\x0c", probe_zfs },
  { "zfs",       8,      0,  8, "\x0c\xb1\x07\xb0\xf5\x02\0\0", probe_zfs },
  { "zfs",     264,      0,  8, "\0\0\x02\xf5\xb0\x07\xb1\x0c", probe_zfs },
  { "zfs",     264,      0,  8, "\x0c\xb1\x07\xb0\xf5\x02\0\0", probe_zfs },

but looking at this I have no idea what this magic value is supposed
to represent, from reading the ondiskformat0822.pdf (ZFS spec) document.

According to that the __u64 ub_magic is supposed to be 0x0000000000bab10c
(big endian) or 0x0xb1ba0000000000 (little endian), at 128kB offset, and
128*1kB thereafter (assuming the filesystem has been used enough to
write 128 transactions).  This should repeat again at 256kB + 128kB.

In the zfs.img.bz2 that I have (and sent Karel recently for util-linux-ng)
I don't see the ub_magic at the right offset.  The NVpair data IS
in the right 16kB offset, and contains all of the expected data (version,
name, pool_guid, etc) so it isn't just an issue of the device having the
wrong offset.  The ub_magic is at 0x21000, 0x21400, ..., and for the
second überblock at 0x61000, 0x61400, so this is off by 0x1000 or 16kB.

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?



In any case, the ZFS magic above is completely broken and needs fixing,
as does the patch I sent Karel for util-linux-ng.  For e2fsprogs it seems
it should be something like the following:

  { "zfs",     128,      0,  8, "\0\0\0\0\0\xba\xb1\xc",probe_zfs },
  { "zfs",     128,      0,  8, "\xc\xb1\xba\0\0\0\0\0",probe_zfs },
  { "zfs",     132,      0,  8, "\0\0\0\0\0\xba\xb1\xc",probe_zfs },
  { "zfs",     132,      0,  8, "\xc\xb1\xba\0\0\0\0\0",probe_zfs },
  { "zfs",     136,      0,  8, "\0\0\0\0\0\xba\xb1\xc",probe_zfs },
  { "zfs",     136,      0,  8, "\xc\xb1\xba\0\0\0\0\0",probe_zfs },
  { "zfs",     384,      0,  8, "\0\0\0\0\0\xba\xb1\xc",probe_zfs },
  { "zfs",     384,      0,  8, "\xc\xb1\xba\0\0\0\0\0",probe_zfs },
  { "zfs",     388,      0,  8, "\0\0\0\0\0\xba\xb1\xc",probe_zfs },
  { "zfs",     388,      0,  8, "\xc\xb1\xba\0\0\0\0\0",probe_zfs },
  { "zfs",     392,      0,  8, "\0\0\0\0\0\xba\xb1\xc",probe_zfs },
  { "zfs",     392,      0,  8, "\xc\xb1\xba\0\0\0\0\0",probe_zfs },

and for util-linux-ng it should be like the following:

               { .magic = "\0\0\0\0\0\xba\xb1\xc", .len = 8,
                 .kboff = 128, .sboff = 0 },
               { .magic = "\xc\xb1\xba\0\0\0\0\0", .len = 8,
                 .kboff = 128, .sboff = 0 },
               { .magic = "\0\0\0\0\0\xba\xb1\xc", .len = 8,
                 .kboff = 132, .sboff = 0 },
               { .magic = "\xc\xb1\xba\0\0\0\0\0", .len = 8,
                 .kboff = 132, .sboff = 0 },
               { .magic = "\0\0\0\0\0\xba\xb1\xc", .len = 8,
                 .kboff = 136, .sboff = 0 },
               { .magic = "\xc\xb1\xba\0\0\0\0\0", .len = 8,
                 .kboff = 136, .sboff = 0 },
               { .magic = "\0\0\0\0\0\xba\xb1\xc", .len = 8,
                 .kboff = 384, .sboff = 0 },
               { .magic = "\xc\xb1\xba\0\0\0\0\0", .len = 8,
                 .kboff = 384, .sboff = 0 },
               { .magic = "\0\0\0\0\0\xba\xb1\xc", .len = 8,
                 .kboff = 388, .sboff = 0 },
               { .magic = "\xc\xb1\xba\0\0\0\0\0", .len = 8,
                 .kboff = 388, .sboff = 0 },
               { .magic = "\0\0\0\0\0\xba\xb1\xc", .len = 8,
                 .kboff = 392, .sboff = 0 },
               { .magic = "\xc\xb1\xba\0\0\0\0\0", .len = 8,
                 .kboff = 392, .sboff = 0 },


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