linux-kernel - Re: 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]

Date:	Sun, 10 Jun 2007 10:02:00 -0400
From:	Theodore Tso <tytso@....edu>
To:	Greg KH <greg@...ah.com>
Cc:	linux-kernel@...r.kernel.org, Kay Sievers <kay.sievers@...y.org>
Subject: Re: Rules on how to use sysfs in userspace programs

On Fri, Jun 08, 2007 at 01:36:37PM -0700, Greg KH wrote:
> The kernel exported sysfs exports internal kernel implementation-details
> and depends on internal kernel-structures and layout. It is agreed upon
> 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't provide a stable interface too, it
> may always change along with internal kernel changes.

I want to step back and ask a very fundamental philosophical question
--- who are the intended users of sysfs?  If it exports an interface,
part of which is known not be stable, except for backwards
compatibility issues, why and to whom are we exporting them?

If the answer is "no one", then maybe modulo backwards compatibility
issues, we should only export via sysfs those things that are
guaranteed to be a stable interface.  Or maybe there should be a mount
option that filters out anything which isn't guaranteed to be stable,
so that user programs can easily determine if they are using anything
"bad" --- and then a year or two from now, we make that mount option
the default, and require a mount option if people want to see the
unstable bits of sysfs.

Way back in 2003, Rusty's OLS keynote talked at great length about
kernel design and interface similicity as a hallmark of good design:

    1. Compiler/linker won't let you get it wrong.
    2. Compiler will warn if you get it wrong.
    3. The simplest use is the correct one.
    4. The name tells you how to use it.
    5. Do it right or it will break at runtime.
    6. Follow common convention and you'll get it right.
    7. Read the documentation and you'll get it right.
    8. Read the implementation and you'll get it right.
    9. Read the correct mailing list thread and you'll get it right.
    10. Read the documentation and you'll get it wrong.
    11. Follow common convention and you'll get it wrong.
    12. Do it right and it will break at runtime.
    13. The name tells you how not to use it.
    14. The obvious use is wrong.
    15. Compiler will warn if you get it right.
    16. Compiler won't let you get it right.
    17. It's impossible to get right. 

The documentation is a good step, but wouldn't it be better if we can
prohibit (or warn) applications who are getting it wrong in the first
place?  Providing interfaces that aren't stable, and then requiring
people to read documentation so they know not to use them, seems to be
providing an attractive nuisance.

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