linux-kernel - Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

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: <20121207204325.GC29435@thunk.org>
Date:	Fri, 7 Dec 2012 15:43:25 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Chris Mason <chris.mason@...ionio.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ric Wheeler <rwheeler@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Martin Steigerwald <Martin@...htvoll.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Chinner <david@...morbit.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate
 UAPI

On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:
> 
> That's not what happened though, and the right way forward from here is
> to give the bit to the feature, maybe with a generic name like
> FALLOCATE_WITHOUT_BEING_HORRIBLY_SLOW.  

I don't think that's a good idea, because the current name explicitly
calls out the fact that we are making a tradeoff between what
***might*** be a security exposure in some cases (but which might be
perfectly fine in others) for performance.  Using the generic name
would hide the fact that this tradeoff is being made, and the
arguments (which I've never seen backed up with a specific design) is
that it's possible to speed up random writes into preallocated space
on a flash device without making any kind of tradeoff that might imply
a security tradeoff.

If indeed it is possible to speed up this particular workload without
making any kind of no-hide-stale tradeoff, then we won't need the bit
--- writes into fallocated space will just get faster, with or without
the bit

I am sure it will be possible to do this in some cases (for example if
you have a device that supports persistent trim which can quickly
zeroize the blocks in question), but I would be very surprised if it's
possible to completely eliminate the performance degradation for all
devices and workloads.  (Not all storage devices support persistent
trim, just for starters.)

In answer's to Linus's question, the reason why people are
hyperventilating so badly about this is that in some circles,
revealing stale data is so horrible that anyone who even tries to
suggest this should be excommunicated.  The mere existence of the
code, or that people are using it, horribly offends those people.

(Witness how people reacted when Linus changed the default of ext3 to
data=writeback many years ago in order to solve a performance problem
that was impacting him and other desktop users very badly.  At the
time, I understood why he made that change, but I know a lot of people
were horrified.  These days we have a better solution which is used by
ext4, but for desktop users at that time, it was a completely fair
engineering choice to make.)

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/