linux-ext4 - Re: [PATCH] ext4: Fix checksum errors with indexed dirs

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]

Message-ID: <20200206094143.GG14001@quack2.suse.cz>
Date:   Thu, 6 Feb 2020 10:41:43 +0100
From:   Jan Kara <jack@...e.cz>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     Jan Kara <jack@...e.cz>, Ted Tso <tytso@....edu>,
        linux-ext4@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] ext4: Fix checksum errors with indexed dirs

On Thu 06-02-20 08:49:44, Jan Kara wrote:
> On Wed 05-02-20 11:04:23, Andreas Dilger wrote:
> > On Feb 5, 2020, at 10:30 AM, Jan Kara <jack@...e.cz> wrote:
> > > DIR_INDEX is not enabled. This is harsh but it should be very rare (it
> > > means someone disabled DIR_INDEX on existing filesystem and didn't run
> > > e2fsck), e2fsck can fix the problem, and we don't want to answer the
> > > difficult question: "Should we rather corrupt the directory more or
> > > should we ignore that DIR_INDEX feature is not set?"
> > 
> > Wouldn't it be better to continue allowing the directory to be read, but
> > not modified?  Otherwise, essentially, metadata_csum is making the
> > filesystem _less_ robust rather than making it more robust.  We don't
> > _need_ the htree index to do a lookup in the directory.
> 
> Hum, I was somewhat afraid it may be a bit fragile but thinking about it
> now, there aren't that many places that need to check. OK, I will try to do
> this and see how it looks.

When I actually implemented this and started testing, I found out why I
didn't want to do it this way :) - the directories are not readable anyway
because checksums are failing for block 0 (which used to be htree root
node). And I'd rather not pile up further hacks in the kernel trying to
work around this. As I wrote in the changelog, chances of anyone hitting
this in practice are rather low and e2fsck can do the right thing...

								Honza

-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR