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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2c0942db0904061548x2d34eff7g9b5332826509da53@mail.gmail.com>
Date:	Mon, 6 Apr 2009 15:48:00 -0700
From:	Ray Lee <ray-lk@...rabbit.org>
To:	Hua Zhong <hzhong@...il.com>
Cc:	Theodore Tso <tytso@....edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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

On Mon, Apr 6, 2009 at 3:25 PM, Hua Zhong <hzhong@...il.com> wrote:
> You are implying that if someone upgrades their kernel, then he must
> 1) upgrade it continuously and 2) without any scrutiny. Both are untrue.

Great, then they'll notice the default ext3 data mode changed, and
adjust their scripts accordingly. Problem solved.

> There are certain things people expect from the kernel, such as
> no ABI changes. To me ext3 default option falls into this category.

As the past several hundred messages on this topic has just shown,
while people may expected metadata vs data ordering to be a guarantee,
apparently it never was unless you specifically mounted your ext3
filesystem with data=ordered. The default was only that, a default,
and one that can still be specified explicitly.

> And even if they are nuts, you can't prove they don't exist, especially
> given how many software already depends on the ordered mode.

There are an unbounded number of possible incorrect setups in the
world. Should we live in fear of their existence without any proof?

> You also conveniently forgot to quote my question about security. Both
> are valid questions, not something I just totally made up.

Security on an embedded device starts with controlling physical
access. If they have access to the storage media all bets are off,
whether it's data=ordered or not. (Access to the storage media is
really what we're talking about here -- medical data, for example,
hitting the platter before the metadata updates that then make that
data unaccessible to other userspace processes.)

Because *if* they have access to the media, they can replace any
running code on that box, and your security is worthless.

So no, I don't see how that's a valid argument.

>> If they're willing to upgrade their kernel blindly, then they
>> shouldn't be doing embedded development.
>
> Linus once said that if you don't understand "not breaking user space" then
> you should not be doing kernel development. Or something to that extent.

Luckily, I do understand, and have argued on user-space's behalf for
years now. But your argument was hypothetical embedded developers who
upgrade their kernels without seeing what defaults changed, and then
getting burned by the different semantics. I can't muster up enough
give-a-damn to care about a minute percentage of the population (us
embedded developers) who aren't doing their job of reading
kernelnewbies to see what changed.

I accept Linus' argument that the change in crash behavior for random
folk is going to be very different, and that perhaps that alone should
drive keeping the default as it is today, but now we're talking about
the desktop space.
--
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/