linux-ext4 - Re: [RFC] ext4_bmap() may return blocks outside filesystem

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: <87r62aidh8.fsf@frosties.localdomain>
Date:	Sat, 07 Feb 2009 14:27:31 +0100
From:	Goswin von Brederlow <goswin-v-b@....de>
To:	Theodore Tso <tytso@....edu>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [RFC] ext4_bmap() may return blocks outside filesystem

Theodore Tso <tytso@....edu> writes:

> On Thu, Feb 05, 2009 at 05:01:01PM -0500, Greg Freemyer wrote:
>> > It also has absolutely nothing to do with the original thread, which
>> > was block numbers which are far outside the range of valid block
>> > numbers given the size of the block device.  :-)
>> 
>> The subject was "return blocks outside filesystem".
>
> Yes, it's clear you didn't read the e-mail thread, but rather just
> keyed off the subject line.  :-)
>
>> In a thin-provisioning environment I'd argue that unmapped sectors are
>> "outside the filesystem". :)
>> 
>> Unfortunately, I can't get anyone else to see the world from my
>> apparently unique perspective. :(
>
> If you don't like this, don't use thin-provisioned devices.  Again, I
> don't see the likely scenario where your fears are likely to be a
> factor in a real world scenario.  If there are bugs in the

There will be bugs.

> thin-provisioned devices, people shouldn't use them.  Given that we

And people will still use them.

Assuming that storage boxes work perfectly is just ignoring reality.
Even if the software has no bugs there will still be hardware
failures. Given enough boxes there will be multi-bit toggles with
correct ECC sum in ram or on disks. Power and battery backups will
fail mid update and and and.

> are conservative about when we tell thin-provisioned devices that
> blocks are no longer in use (i.e., on journal commits, and if we
> crash, just don't tell the device the blocks can be reused), what's
> the problem that you're worried about?  How does it occur in real
> life?
>
> It's hard to defend against a theoretical problem when you only give
> vague fears about how it might be triggered...
>
> 						- Ted

I see the following scenario:

1) The filesystem / thin-provision gets corrupted somehow. fs bug,
hardware, whatever.

2) The thin-provision thinks a block is free while the FS thinks it is
in use. Make it a meta data block so it really matters.

3) The thin-provision still has the mapping and data of the block and
hasn't reused the block yet. On read the device will return the
correct data as long as the block is not reused. This seems to be a
valid implementation for a thin-provision device.

4) fsck will find no error but future writes will reuse the block on
the thin-provision device overwriting the data and causing
catastrophic FS corruption.

So I think a fsck pass to check FS used blocks against hardware used
blocks is essential if the FS does support thin-provisioned devices.
Once you free hardware blocks you have to check that what the FS and
hardware think are compatible.

MfG
        Goswin
--
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