linux-kernel - Re: [PATCH 01/61] Rules on how to use sysfs in userspace programs

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: <20070713021445.GB27045@suse.de>
Date:	Thu, 12 Jul 2007 19:14:45 -0700
From:	Greg KH <gregkh@...e.de>
To:	Pavel Machek <pavel@....cz>
Cc:	linux-kernel@...r.kernel.org, Kay Sievers <kay.sievers@...y.org>
Subject: Re: [PATCH 01/61] Rules on how to use sysfs in userspace programs

On Fri, Jul 13, 2007 at 12:41:14AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > +The kernel exported sysfs exports internal kernel implementation-details
> > > > +and depends on internal kernel structures and layout. It is agreed upon
> > > > +by the kernel developers that the Linux kernel does not provide a stable
> > > > +internal API. As sysfs is a direct export of kernel internal
> > > > +structures, the sysfs interface can not provide a stable interface eighter,
> > > > +it may always change along with internal kernel changes.
> > > 
> > > It is also agreed upon by the kernel developers that the Linux kernel
> > > does have a stable user<->kernel API... so we have a small problem
> > > here. 
> > 
> > I agree, that is why we have described the proper ways to use /sys in a
> > manner that is acceptable to future changes in it.
> > 
> > > Maybe solution is to declare /sys unstable, but... perhaps /sys can
> > > stop mirroring internal structures? I do not think we should codify
> > > our failure to keep /sys stable here.
> > 
> > I think that /sys is to valuable to say it can just never be used by
> > userspace programs.  With these suggestions, do you see any problems
> > with any potential future changes in the layout that you can come up
> > with?
> 
> I'm afraid that userland programmers just will not read/follow
> this... and we will not know.

Yes we will, when things break on their side due to normal movements
around within sysfs.

Is there any other way you can imagine to get the word out on how to use
this properly?  I'm working with the LSB, so perhaps we can add it to
their next spec for compliance testing of applications...

> [Perhaps CONFIG_STRESS_SYSFS_PARSERS would be useful? Move stuff
> randomly to expose broken /sys users?]

Right now that is CONFIG_SYSFS_DEPRECATED :)

> Then, we'll get binary-only applications working okay relying on
> specific /sys structure, and soon, we'll be unable to change /sys.
> 
> [Perhaps we can make large parts of sysfs superuser-only, so that
> "normal" application can not rely on it?]

Like those big "binary-only applications" don't already run as root...

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/