linux-kernel - Re: Tux3 Report: Initial fsck has landed

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]

Message-ID: <20130128141209.GA22711@thunk.org>
Date:	Mon, 28 Jan 2013 09:12:09 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Daniel Phillips <daniel.raymond.phillips@...il.com>
Cc:	David Lang <david@...g.hm>, linux-kernel@...r.kernel.org,
	tux3@...3.org, linux-fsdevel@...r.kernel.org
Subject: Re: Tux3 Report: Initial fsck has landed

On Sun, Jan 27, 2013 at 10:13:37PM -0800, Daniel Phillips wrote:
> > The thing that jumps out at me with this is the question of how you will
> > avoid the 'filesystem image in a file' disaster that reiserfs had (where
> > it's fsck could mix up metadata chunks from the main filesystem with
> > metadata chunks from any filesystem images that it happened to stumble
> > across when scanning the disk)
> >
> Only superficially. Deep thoughts are in order. First, there needs to be a
> hole in the filesystem structure, before we would even consider trying to
> plug something in there. Once we know there is a hole, we want to
> narrow down the list of candidates to fill it. If a candidate already lies
> within a perfectly viable file, obviously we would not want to interpret
> that as lost metadata. Unless the filesystem is really mess up...
> 
> That is about as far as I have got with the analysis. Clearly, much more
> is required. Suggestions welcome.

The obvious answer is what resierfs4 ultimately ended up using.  Drop
a file system UUID in the superblock; mix the UUID into a checksum
which protects each of the your metadata blocks.  We're mixing in the
inode number as well as the fs uuid in in ext4's new metadata checksum
feature to protect against an inode table block getting written to the
wrong location on disk.  It will also mean that e2fsck won't mistake
an inode table from an earlier mkfs with the current file system.
This will allow us to avoid needing to zero the inode table for newly
initialized file systems.

Regards,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/