public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
	Kees Cook <keescook@chromium.org>,
	linux-kernel@vger.kernel.org, Ben Hutchings <ben@decadent.org.uk>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Ludwig Nussel <ludwig.nussel@suse.de>,
	Alessandro Rubini <rubini@gnudd.com>,
	linux-doc@vger.kernel.org
Subject: Re: Hardening debugfs (Was Re: [PATCH] debugfs: more tightly restrict default mount mode)
Date: Thu, 30 Aug 2012 11:15:13 -0500	[thread overview]
Message-ID: <503F9191.20209@landley.net> (raw)
In-Reply-To: <20120829040935.GB21265@kroah.com>

On 08/28/2012 11:09 PM, Greg Kroah-Hartman wrote:
> On Tue, Aug 28, 2012 at 05:55:45PM -0500, Rob Landley wrote:
>> I've always been a bit confused by the debugfs design, which seems a
>> giant compost heap like /proc where we find a specific styrofoam cup
>> useful and the temporary thing becomes permanent. (Why is there _one_
>> debugfs?)
> 
> The rules for debugfs are very simple:
> 	There are no rules.
> 
> That's it.  It's up to the kernel developer to do what they need to do,
> for debugging stuff, how ever they best see fit.

Emergent de-facto standards with no review or versioning or anything,
check. It's the "every driver in the system shares a common resource
with no arbitration or guidelines" thing that I have trouble with.

Is it possible to have multiple instances of this filesystem? If so, can
they have -o "modulename,modulename,modulename..." so that only certain
modules' files get put in this instance?

I understand that /sys/module/$BLAH has rules and we can't have that,
but having a giant slush pile and asserting it won't become a new /proc
because reasons makes me nervous.

For example, ftrace is already built on top of debugfs. If debugfs has
no rules, but ftrace does, can another module put stuff in "tracing"? If
a stable API isn't important, will we start bundling whatever userspace
tools ftrace needs in with the kernel, along with udev/systemd? Or is
the position that ftrace will never have non-debugging uses, just like
ptrace?

> Yes, it replaces proc for all of the debugging stuff that shouldn't have
> been there before, how it's structured, is up to the developer adding
> the code.

For a definition of "replaces" that does not actually remove any of the
existing entries from /proc. (That garbage can's full, here's a new one?)

The problem with /proc is that lots of things used it for different
purposes with no rules. The goal of debugfs is to provide something that
lots of things use for different purposes, explicitly with no rules.

I'm just wondering why it's a big common hairball instead of separate
per-module filesystems. (Other than "Linux will never have a unionfs
because the perfect is the enemy of the good".)

Eh, it's your thing, not mine. I just don't understand it.

> greg k-h

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

      reply	other threads:[~2012-08-30 16:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-27 20:32 [PATCH] debugfs: more tightly restrict default mount mode Kees Cook
2012-08-27 20:41 ` Greg Kroah-Hartman
2012-08-28  7:44 ` Alessandro Rubini
2012-08-28 14:41 ` Hardening debugfs (Was Re: [PATCH] debugfs: more tightly restrict default mount mode) Theodore Ts'o
2012-08-28 14:55   ` Ben Hutchings
2012-08-28 15:02     ` Theodore Ts'o
2012-08-28 17:09   ` Greg Kroah-Hartman
2012-08-28 19:43     ` Kees Cook
2012-08-28 22:55   ` Rob Landley
2012-08-29  4:09     ` Greg Kroah-Hartman
2012-08-30 16:15       ` Rob Landley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=503F9191.20209@landley.net \
    --to=rob@landley.net \
    --cc=ben@decadent.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ludwig.nussel@suse.de \
    --cc=rubini@gnudd.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox