linux-kernel - Re: [PATCH] fs: Correct SuS compliance for open of large file without options

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: <20070927213445.GA7857@kroah.com>
Date:	Thu, 27 Sep 2007 14:34:45 -0700
From:	Greg KH <greg@...ah.com>
To:	Theodore Tso <tytso@....edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jens Axboe <jens.axboe@...cle.com>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] fs: Correct SuS compliance for open of large file
	without options

On Thu, Sep 27, 2007 at 02:37:42PM -0400, Theodore Tso wrote:
> On Thu, Sep 27, 2007 at 10:59:17AM -0700, Greg KH wrote:
> > Come on now, I'm _very_ tired of this kind of discussion.  Please go
> > read the documentation on how to _use_ sysfs from userspace in such a
> > way that you can properly access these data structures so that no
> > breakage occurs.
> 
> I've read it; the question is whether every single application
> programmer or system shell script programmer who writes code my system
> depends upon has read it this document buried in the kernel sources,
> or whether things will break spectacularly --- one of those things
> that leaves me in suspense each time I update the kernel.

Ok, how then should I advertise this better?  What can we do better to
help userspace programmers out in this regard?

> I'm reminded of Rusty's 2003 OLS Keynote, where he points out that
> what's important is not making an interface easy to use, but _hard_
> _to_ _misuse_.

Me and Pat Mochel sat in that talk and instantly had an "oh shit" moment
when it came to the in-kernel usage of sysfs and the driver model.  Ever
since then, I have been working to change the code to make it better.
With the exception of the recent help from Kay, I am the only one doing
this as Pat has been gone for a few years and isn't coming back.

> That fact that sysfs is all laid out in a directory, but for which
> some directories/symlinks are OK to use, and some are NOT OK to use
> --- is why I call the sysfs interface "an open pit".

We (well, Kay mostly) have also been working on fixing this all up to
make it much harder to use sysfs incorrectly.  We will have a single
device tree (well, almost a single tree, it's getting there), so that
all of the information is only in one place, and you don't have to go
searching all over the place for it.  That is a direct improvement over
the old design where somethings were in one place, and others in
another.

And because of the original design mistakes, we have only been able to
change things for the better in a slow manner.  We have had userspace
programs fixed up for _years_ before we are able to make the
corresponding changes in the kernel, so as to not break the distros that
are slow to upgrade packages and kernels (like Debian.)

If I had my druthers, we could instantly put some patches into the tree
to fix up the sysfs "mess" once and for all, creating a unified, single
tree, with only a handful of needed symlinks to be able to categorize
certain things.  We have the patches (Kay wrote them over a year ago),
and userspace programs work just fine with them (udev and HAL), but
because we need to support 5 year old userspace programs running
tomorrows kernel, we must take very tiny, slow steps to get there.

And yes, sysfs has slowly changed over the years, and along the way we
have kept things working, with only very minor problems.  You have no
idea the crazy mismatch of kernels and userspace programs we have had to
deal with.  And it will continue to change, slowly, until we reach the
unified-tree goal, and all of those old crufty userspace programs are
dead and buried (I got a bug report about RHEL's udev version 039 just
yesterday.)

So you can't have it both ways.  You can't complain that sysfs isn't
stable, and isn't "properly userspace friendly" at the same time.  In
order to fix the issues, we have to change it, and do it slowly, because
I don't want to break some distros that can't keep up with the others.

thanks,

greg k-h
-
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/