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]
Date:	Sat, 7 Feb 2009 10:51:51 -0500
From:	Theodore Tso <tytso@....edu>
To:	Goswin von Brederlow <goswin-v-b@....de>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [RFC] ext4_bmap() may return blocks outside filesystem

On Sat, Feb 07, 2009 at 02:27:31PM +0100, Goswin von Brederlow wrote:
> 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.

That's highly unlikely, actually.  Once you tell the thin-provisioning
device that the block is not in use, they will delete the mapping from
their mapping structures.  So it's highly unlikely you will be able to
recover once you send the TRIM command.

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

The way this can happen today is if the bitmap block gets corrupted,
and so a block which is in use gets used by another inode.  So now you
have a filesystem block overwritten by a data block from an inode ---
so you have potentially catastrophic FS corruption, even before you
issue the ATA TRIM command.  This can happen to day, and in practice,
it is extremely rare.  So permit me for being highly dubious about
your claim this is going to happen more often with thin-provisioned
devices.

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

The filesystem might not even know whether or not a thin-provisioned
device is in use.  The OS may not even know whether the device is
thin-provisioned.  So ultiamtely, it's not up to the FS...

		      		       	      - 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ