Weekly Edition
Return to the Kernel page
| |||||||||||||
debugfs: rules not welcome
The kernel's debugfs filesystem is meant to be a place where kernel
developers can place any information which seems to be of value to
somebody. Unlike the other kernel virtual filesystems (/proc,
/sys), debugfs has an explicit "no rules" rule. Anything
developers want to put there is fair game, without regard for taste,
(hypothetically) ABI stability, or perceived usefulness. "No rules" does
not extend as far as compromising the security of the system, though,
which has led to an attempt to lock debugfs down.
Eugene Teo recently posted a request for CVE numbers for 20 separate vulnerabilities involving world-writable files in debugfs and sysfs. Some of the debugfs vulnerabilities would seemingly allow any local user to write arbitrary values into device registers - a situation from which little good can be expected to emerge. Expect yet another set of kernel updates in the near future as these holes are closed and fixes are made available to users. In response to these vulnerabilities, Kees Cook posted a patch which would cause debugfs to be mounted with root-only access permissions. That way, any future mistakes in debugfs would be inaccessible to nonprivileged users and, thus, would not be a new vulnerability in need of fixing. The patch was not received well; it looks suspiciously like a rule in a land where there are supposed to be no rules. Greg Kroah-Hartman responded:
It's just stupid mistakes being made here, don't try to lock down
the whole filesystem for just a handful of bugs.
Kees suggested that these mistakes could keep on happening, and that "no rules" might not be the best approach, but Alan Cox responded:
It's a debugging fs, it needs to be "no rules" other than the obvious
"don't mount it on production systems"
There is one little problem with the idea of not mounting debugfs on production systems, though: there is useful stuff in that filesystem. At the top of the list must certainly be the control files for perf and ftrace; most of our nice, new tracing infrastructure will not work without debugfs. There are also knobs for tweaking scheduler features, interfaces for the "usbmon" tool, interfaces used by Red Hat's kvm_stat tool, and so on. There is enough useful stuff in debugfs that is it can be found mounted well outside of kernel debugging environments; it has reached the point that Greg challenges the idea that debugfs should not be mounted on production systems:
No, not true at all, the "enterprise" distros all mount debugfs for
good reason on their systems.
"No rules" and "mounted on enterprise systems" seems like a bad combination; it would be nice to make things more secure. A number of proposals have been floated to do that, including:
The last concern could be a show stopper; it could force developers to maintain both the old and new interfaces in parallel for some years. Many developers, faced with that sort of task, may just decide to leave the interface where it is. Debugfs is not supposed to have any ABI guarantees, but, as has become clear in the past, such a policy does not necessarily prevent the creation of an ABI which must be maintained going forward. So debugfs on production systems seems likely to be with us for some time. Given that, there is no alternative to making it more secure. The checkpatch.pl change is a good start, but it cannot take the place of proper code review. Reviewers have a tendency to skip over debugfs code, but, if that code is to run on important systems, that tendency must be fought. Debugfs code must uphold the security of the system just like any other kernel code. (Log in to post comments)
debugfs: rules not welcome Posted Feb 24, 2011 8:10 UTC (Thu) by ajb (guest, #9694) [Link]
Perhaps the production-ready status needs to be pushed down to the granularity of individual debugfs files. Eg, add a flag to the API calls which create debugfs files, and a 'production mode' in debugfs, under which files without the flag set do not get made available (except perhaps to root).
debugfs: rules not welcome Posted Feb 24, 2011 8:50 UTC (Thu) by johill (subscriber, #25196) [Link]
Doesn't debugfs still cause crashes if there are ever files that can disappear from it, because it doesn't have proper lifetime management? Or did that get fixed eventually and I just missed it?
The case I'm thinking of is basically
fd = open(debugfs/file)
Developers versus administrators Posted Feb 24, 2011 16:39 UTC (Thu) by epa (subscriber, #39769) [Link]
It needs to split into a pure 'debugfs' (which contains stuff of interest to kernel developers only, has no rules, and should never be mounted on production systems) and a new 'diagfs' for things which might be of interest to system administrators.
Developers versus administrators Posted Feb 25, 2011 0:49 UTC (Fri) by giraffedata (subscriber, #1954) [Link] It needs to split into a pure 'debugfs' (which contains stuff of interest to kernel developers only, has no rules, and should never be mounted on production systems) and a new 'diagfs' for things which might be of interest to system administrators. Isn't the latter what sysfs and procfs are for?
Developers versus administrators Posted Feb 25, 2011 7:56 UTC (Fri) by epa (subscriber, #39769) [Link]
The trouble is that once you put something into sysfs or procfs, it becomes part of the kernel interface and you must commit to backwards compatibility. For that reason a lot of useful stuff goes into debugfs instead. But there are many things which are useful and safe to enable on production systems to fix whatever problems come up today, but need not become supported interfaces to preserve forever. Hence the need for an intermediate category between 'supported kernel feature' and 'no rules at all, never use on production systems'.
Developers versus administrators Posted Feb 25, 2011 9:44 UTC (Fri) by misiu_mp (guest, #41936) [Link]
Isn't it a good idea to make the really useful stuff part of the kernel api and maintain it for backwards compatibility? This could only strengthen the system.
I understand if features in debugfs are made by the kernel hackers themselves for their own benefit, but if those things become useful to others, they should be "productized". After all if debugfs is used today with no warranties of compatibility, then whatever uses is will be a burden to maintain and will make the useful stuff just a niche. Making the useful stuff a solid part of the kernel could open for new possibilities.
I would like to see some examples of
Developers versus administrators Posted Feb 28, 2011 17:04 UTC (Mon) by epa (subscriber, #39769) [Link] but if those things become useful to others, they should be "productized".But that's not the same thing as 'maintained with an unchanging interface for ever after'. It might be a useful thing to see how many times the frobfs code calls frob_inode(). Essential, even, for performance tuning on large systems. But the frobfs developers want to have freedom to change their code to get rid of the frob_inode() call without breaking backwards compatibility. So there must be a way to label this stuff as usable in production, but not guaranteed to be there in future kernel versions. In general any kind of instrumentation that works based on the kernel's internal data structures or control flow is useful to see but not a part of its API.
Developers versus administrators Posted Feb 26, 2011 3:01 UTC (Sat) by foom (subscriber, #14868) [Link]
Yeah, but....if something is useful and enabled on production systems, people will start depending on it. And then tools will start depending on it. And then you can't break it, and so diagfs becomes *yet another* place to look for the knob you want to check/tweak, just like you already have to look for it in both sysfs and procfs...
Developers versus administrators Posted Mar 8, 2011 9:40 UTC (Tue) by robbe (subscriber, #16131) [Link]
If there wasn't an implicit backwards-compatibility guarantee for stuff in debugfs, people could simply move the "production-ready" parts like perf to a final place in sysfs without any hitch. Yes, they would be gone in debugfs, but you're not supposed to depend on anything there.
Actually, I don't see the big problem. If you deem /debugfs/foo/{bar,baz} such production interfaces, why not move them to /sysfs/.../foo/{bar,baz} and provide the compatibility via a symlink? Is that really a maintenance burden?
I'd really like a mirror policy for phasing out ABI. I.e. if an interface has been in the kernel for X releases and Y years when it goes on the deprecation list, it can be removed after another X releases or Y years (whichever is greater).
debugfs: rules not welcome Posted Feb 25, 2011 0:01 UTC (Fri) by keybuk (subscriber, #18473) [Link]
Note that kees has patched Ubuntu to make debugfs root-only anyway:
debugfs: rules not welcome Posted Feb 25, 2011 19:30 UTC (Fri) by dmk (subscriber, #50141) [Link]
what about selecting at runtime (perhaps needing to remount) what entries are actually populating the debugfs..
something like
?
debugfs: rules not welcome Posted Mar 3, 2011 15:53 UTC (Thu) by mikachu (guest, #5333) [Link]
"Moving interfaces requires possibly cleaning them up, making a stronger commitment to ABI compatibility going forward and, importantly, breaking tools which depend on the current location of those interfaces."
There is something incredibly oxymoronic about not wanting to move an interface for fear of breaking ABI compatibility for fear of not being able to break ABI compatilibity.
debugfs: rules not welcome Posted Mar 5, 2011 1:35 UTC (Sat) by foom (subscriber, #14868) [Link]
Hah, I missed that sentence the first time I read the article. But that's indeed quite hilarious that "breaking tools" is a reason given to not want to move the files from a location that's supposedly "anything goes" with no ABI compatibility rules. :)
|
|||||||||||||