linux-ext4 - Re: References to unmapped sectors

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] [day] [month] [year] [list]

Date:	Sat, 07 Feb 2009 14:41:44 +0100
From:	Goswin von Brederlow <goswin-v-b@....de>
To:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: References to unmapped sectors

Greg Freemyer <greg.freemyer@...il.com> writes:

> I just have a very fundamental issue with a storage spec that allows
> random garbage to be returned in response to a read request with no
> signaling mechanism included to notify the kernel that it is reading
> trash.  Ric has told me that in the real world, storage vendors are
> likely to return a well defined pattern (nulls, etc.) in response to
> reads of these unmapped sectors.  If true, why not have the spec say
> so.

More flexibility for implementations. It means implementations do not
have to check for the validity of read requests. This can sometimes
speed up things, save (non volatile) memory, save disk syncs, save
global locks for mapping updates, ...

Imagine if the C standard would require that accessing a invalid
pointer would abort the program. Suddenly every pointer access would
have to be validated in case the pointer is invalid but accidentally
points to some (for the cpu) valid address.

> Or have some way to communicate to the kernel which sectors are
> reliable (mapped) vs. unreliable (unmapped).
>
> On the one hand the whole purpose of the SCSI DIF/DIX extension is to
> ensure that the data being read from a scsi device is the exact data
> that was written, but the thin-provisioning specs go in the opposite
> direction and allow complete garbage to be returned with no signaling
> mechanism to allow the kernel to even conceivably find out.
>
> Instead of focusing on the negative, I'll reword my issue to discuss
> how unmapped sector knowledge (if available) could be used to
> _improve_ the current functionality of a filesystem:
>
> ==> Positive spin on how knowledge of which sectors are unmapped could
> improve filesystem reliability

Isn't it more advantageous for wear leveling? The more unused blocks a
device has the better it can level wear and thereby extend the
lifetime of the device.

> The original email discussed pointers that in someway became corrupted
> to point at blocks which NEVER contained valid data.  Since the data
> is outside of the overall range of data blocks, it can be identified
> and both the kernel and userspace can be prevented from relying on
> what would obviously be trash.
>
> Whatever mechanism caused the bmap pointers to point outside the
> overall range of the filesystem, I assume could just as easily cause
> the those pointers to point at unmapped sectors.
>
> If the SCSI / ATA specs were enhanced to somehow notify the kernel
> when a read of these unmapped sectors occurred, then both the  kernel
> and userspace could be protected from relying on this potential trash
> as well.

At least there should be a scsi reply for this. The use of which could
still be optional. So either an error or any data could be
valid. Obviously requiring a proper error would be better for the
user.

> FYI: I've tried to find a way to send my comments to the T10
> committee, but I have not found a way to do that since the spec is not
> in a "public comment" period at present.
>
> Greg

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