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] [day] [month] [year] [list]
Date:	Mon, 28 Jan 2008 13:59:19 -0700
From:	Andreas Dilger <adilger@....com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Theodore Tso <tytso@....edu>, Matthias Koenig <mkoenig@...e.de>,
	linux-ext4@...r.kernel.org, hvogel@...e.de,
	Girish Shilamkar <Girish.Shilamkar@....COM>,
	Eric Sandeen <esandeen@...hat.com>
Subject: Re: Integrating patches in SLES10 e2fsprogs

On Jan 28, 2008  10:54 -0600, Eric Sandeen wrote:
> Theodore Tso wrote:
> > On Mon, Jan 28, 2008 at 04:26:53PM +0100, Matthias Koenig wrote:
> >>> Patch6:         e2fsprogs-mdraid.patch
> >>>
> >>> This apparently adds a new environment variable,
> >>> BLKID_SKIP_CHECK_MDRAID, which forces blkid to not detect mdraid
> >>> devices.  I'm not sure why.
> >> Workaround for people having stale RAID signature on their disk:
> >> https://bugzilla.novell.com/show_bug.cgi?id=100530
> > 
> > Hmm... there's got to be a better way around this.
> 
> Won't help existing block devices, but it'd be nice to have a common
> library which could be called @ mkfs time to wipe out all known
> signatures...
> 
> mkfs.xfs tries to do this, but it'd be silly to duplicate in every mkfs.

Well, blkid already has a way to _detect_ a lot of filesystem signatures,
so it might be relatively easy to exploit the type_array[] entries to have
it zap out all of these blocks.  That said, the majority of them are in
the first 68kB of the filesystem (mdraid excluded) so it shouldn't be too
hard to zero them out.  Let's hope nobody ever uses "0x00000000" as magic.

mke2fs already tries to do this, though I notice:
- the zap_sector() call will skip the entire write if there is a BSD bootblock,
  instead of skipping only the first sector(s) and overwriting the rest...
  Since I don't know much about BSD bootblocks, I don't know what the right
  behaviour is, but I can guess we still want to zero out 4-68kB (or whatever).
- it only overwrites up to sector 8 (4kB) and not further into the disk to
  catch e.g. reiserfs superblocks.  Usually it will overwrite this anyways
  (GDT, bitmaps, inode table), but in some rare cases it might not.

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

Powered by blists - more mailing lists