linux-kernel - Re: [PATCH 0/8][RFC] IO latency/throughput fixes

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:	Wed, 08 Apr 2009 21:40:43 -0500
From:	Eric Sandeen <sandeen@...deen.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Ray Lee <ray-lk@...rabbit.org>, Hua Zhong <hzhong@...il.com>,
	Theodore Tso <tytso@....edu>,
	Jens Axboe <jens.axboe@...cle.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/8][RFC] IO latency/throughput fixes

Linus Torvalds wrote:
> 
> On Mon, 6 Apr 2009, Linus Torvalds wrote:
>> thing that we think people would be happiest with.
>>
>> I think "ordered" was a reasonable default, but that was at least partly 
>> because _both_ ordered and writeback sucked (partly in different ways).
>>
>> I do think we could make it a config option.
> 
> A patch _something_ like this.
> 
> A few notes:
> 
>  - This is UNTESTED (of course)
> 
>  - If I did this right, this _only_ overrides the data mode if it's not 
>    explicitly specified on disk in the superblock mount options.
> 
> IOW, if you have done a 
> 
> 	tune2fs -o journal_data_ordered
> 
> then this will _not_ override that. Only in the absense of any explicit 
> flags should this trigger and then make the choice be 'writeback'.
> 
> And just to be _extra_ backwards compatible, if you really want the old 
> behavior, and don't want to set the ordering flag explicitly, just answer 
> 'y' to the EXT3_DEFAULTS_TO_ORDERED Kconfig question. 
> 
> What do people think? Anybody want to test?

I think this is a terrible idea.  I ran the following test with
data=writeback on 2.6.29.1 (which doesn't have the rename & truncate
hacks, but they would not help in this case, either):

tar xvjf linux-2.6.29.1.tar.bz2; echo b > /proc/sysrq-trigger

This simulates a crash on a busy system.  I got back 8000+ files
containing other people's data.

data=ordered isn't just "nicer" behavior than writeback on a crash, it's
necessary today for security.  Making data=writeback default is a
security flaw.

Are we really considering (wait, not considering; it's checked in
already!) - blowing a huge security hole in the filesystem used on the
vast majority of installations in the name of speed?

Chris suggested earlier in this thread that we should use the XFS trick
of not extending the i_size until io completion, and I agree that it
makes sense.  Chris even offered to take a stab at it and I hope I can
work with him on this.  It's a -much- better answer than this
reactionary change.

-Eric
--
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/