linux-ext4 - Re: [PATCH] e2fsprogs - pass1c terminates early if hard links

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: <20070411104230.GA19237@thunk.org>
Date:	Wed, 11 Apr 2007 06:42:31 -0400
From:	Theodore Tso <tytso@....edu>
To:	Andreas Dilger <adilger@...sterfs.com>
Cc:	Jim Garlick <garlick@...l.gov>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] e2fsprogs - pass1c terminates early if hard links

On Tue, Apr 10, 2007 at 10:22:20PM -0600, Andreas Dilger wrote:
> On Apr 10, 2007  23:40 -0400, Theodore Tso wrote:
> > Also note that providing a
> > script which generates the test filesystem is now preferred to
> > including an image.gz file; it avoids the need for binary patches, and
> > it makes it clearer how the test filesystem is constructed.
> 
> Agreed, though in some cases it is considerably easier to produce the
> corruption via binary editing than debugfs commands unless there are
> now facilities to copy blocks/bytes around within the filesystem?

Yes, there are still some facilities that could be added to make life
more convenient.  We don't currently have a way to modify indirect blocks
directly (although I may create that soon or patches would be
greatfully accepted :-), and of course there is a similar issue with
extents and extended attributes blocks.

A facility to set a specific range of bytes, or copy a range of bytes
from one block/offset to another (to simulate a disk controller
hiccup) is definitely not a bad idea.  Maybe something like this?

write_data_bytes <block>/<offset>  <hex string> 
write_data_ascii <block>/<offset>  <ascii string> 
copy_data_bytes <block/offset> <block/offset> <count>

> > +set_inode_field /dir/foo block[0] 30
> > +set_inode_field /dir2/bar block[0] 30
> > +set_inode_field /dir3/baz block[0] 30
> > +set_inode_field /dir/fee block[0] 34
> > +set_inode_field /dir2/fie block[0] 34
> > +set_inode_field /dir3/foe block[0] 34
> 
> Also, items such as these presuppose that the directory has specific
> blocks allocated to it, which need the test case to be constructed in
> multiple passes (to extract these numbers) and could break at some time 
> in the future.

At the moment I'm assuming that e2fsprogs block allocation algorithms
(which are not as sophisticated as what's in the kernel) aren't going
to be changing.  If they change, you're right, they could break the
test.  At the minimum I should document where the numbers are coming
from in the test.

I could imagine a debugfs extension where we could do things like:

set_var $shared_blk /dir4/quux block[0]
set_inode_field /dir/foo block[0] $shared_blk
set_inode_field /dir2/bar block[0] $shared_blk
set_inode_field /dir3/baz block[0] $shared_blk

Of course the temptation then would be to start adding conditions,
functions, maybe an entire tcl interpreter....   :-)

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