Linux as a single-user system
The patch in question comes from Iulia Manda; it creates a kernel configuration option that removes the concept of multi-user operation. When appropriately configured, the kernel runs every process with user and group IDs of zero and all capability bits set. This option also removes support for a long list of system calls dealing with user and group IDs and capabilities.
As is often the case with the more eyebrow-raising patches, this one is driven by the kernel "tinification" effort that seeks to shoehorn the kernel into small-memory systems. Such systems are likely to be running a single, dedicated application, perhaps as the init process, and they have little use for many of the features provided by the kernel — including multi-user operation. Configuring that support out saves a bit of memory (about 25KB), making it easier to fit a contemporary kernel on the smallest systems-on-chip.
Given the nature of the patch, it would not be surprising to see a chorus of opposition on the lists. In fact, the set of opponents consists mainly of Casey Schaufler, who said:
"Authoritative LSM hooks" are Linux security module functions that are able to increase the privilege level of a running process. They were extensively debated back in 2001 when the security module mechanism was being developed. Authoritative hooks did not make the cut in the end; they were seen as a significant security risk in their own right. At that time, one Casey Schaufler criticized the decision, seeing it as a selling-out of important functionality to ease the merging of security modules into the kernel.
Many years later, Casey clearly has not forgotten. He would apparently like to see the single-user option, if it is to be included at all, implemented as a security module using authoritative hooks. The tinification developers are unimpressed by that idea, though; reimplementing authoritative hooks would involve reviving an old (and resolved) discussion to get to a possibly inferior solution to the problem they are interested in addressing. So this patch is unlikely to evolve in that direction.
Beyond that, though, Casey raised a
complaint that has come up before with regard to tinification patches:
"You are opening the door to creating a 'Linux' kernel that does not
behave like Linux.
" Many of the patches in this area will, by their
basic nature, have that effect; they are, after all, concerned with
removing functionality that is not needed for one specific use case. If
the kernel is to be suitable for deployment on tiny systems, it will need
to be flexible enough to "not behave like Linux" on those systems.
That is one way of seeing the problem, anyway. Josh Triplett responded that it has long been possible to configure functionality out of the kernel and that the single-user patches are nothing special or new:
In the end, it comes down to a couple of questions: can the tinification
developers package their changes in a way that the larger development
community can accept, and is that community willing to tolerate patches
that enable fundamental changes in how the kernel works? The discussion is
not new, of course; it came up at the 2014
Kernel Summit among other places. It does not look like one that will
come to any sort of quick conclusion. But, in the end, if Linux is not
able to run well on very small systems, it will likely be pushed aside by a
system that does work well in that environment.
| Index entries for this article | |
|---|---|
| Kernel | Embedded systems |
Posted Feb 5, 2015 10:55 UTC (Thu)
by epa (subscriber, #39769)
[Link] (10 responses)
Come to think of it, I look forward to the next tinification patch that removes support for multiple processes, scheduling, and makes the only running process always have pid 1.
Posted Feb 5, 2015 12:07 UTC (Thu)
by tao (subscriber, #17563)
[Link] (6 responses)
Or do you see your tiny system using none of those?
Posted Feb 5, 2015 14:37 UTC (Thu)
by epa (subscriber, #39769)
[Link] (5 responses)
Posted Feb 5, 2015 16:21 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (3 responses)
What always could be preempted (through any interrupt, but usually the timer tick) is userspace threads.
Posted Feb 5, 2015 16:35 UTC (Thu)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Feb 12, 2015 0:52 UTC (Thu)
by kevinm (guest, #69913)
[Link] (1 responses)
Posted Feb 12, 2015 11:50 UTC (Thu)
by epa (subscriber, #39769)
[Link]
I guess that then you need to add an explicit scheduling step when returning from a system call, which may not exist at the moment.
Posted Feb 6, 2015 22:19 UTC (Fri)
by justincormack (subscriber, #70439)
[Link]
Posted Feb 5, 2015 17:25 UTC (Thu)
by josh (subscriber, #17465)
[Link] (2 responses)
That might potentially be worth doing, but it'd require a much more invasive patch for much less gain. And yes, unless you have a large number of processes or other data structures involving UID/GID, you likely wouldn't see much savings; and if you have a large number of processes, what are you doing running *all* of them as root? :)
> Come to think of it, I look forward to the next tinification patch that removes support for multiple processes, scheduling, and makes the only running process always have pid 1.
Compiling out fork() and exec() is definitely on the list.
Compiling out the scheduler would be rather more challenging, since that would also imply no kernel threads or other background processing.
Posted Feb 6, 2015 3:48 UTC (Fri)
by flussence (guest, #85566)
[Link]
Posted Feb 12, 2015 1:00 UTC (Thu)
by kevinm (guest, #69913)
[Link]
Posted Feb 5, 2015 16:25 UTC (Thu)
by malor (guest, #2973)
[Link] (4 responses)
It strikes me that this is being horrified that someone might use their hardware differently than you do.
Who the heck cares? If they run a Linux kernel that looks nothing at all like Linux on my machine, what harm does that do me?
He makes it sound almost like the Linux design is somehow holy, and that it would be heretical to do it any other way.
Posted Feb 6, 2015 17:38 UTC (Fri)
by ddevault (subscriber, #99589)
[Link] (3 responses)
For what it's worth, I support this particular kernel patch.
Posted Feb 6, 2015 18:36 UTC (Fri)
by malor (guest, #2973)
[Link] (1 responses)
How can you even define that? And why would you want to? If someone uses the kernel tree to make a box that doesn't look much at all like yours, how are you hurt?
Shouldn't decisions like that be purely from a maintenance/coding perspective?
Posted Feb 7, 2015 3:36 UTC (Sat)
by ddevault (subscriber, #99589)
[Link]
Posted Feb 6, 2015 23:08 UTC (Fri)
by josh (subscriber, #17465)
[Link]
If you might potentially have a use for it, we could use some explicit statements to that effect on LKML in response to the patch. Users asking for a feature make a much more compelling argument for that feature.
Posted Feb 7, 2015 1:42 UTC (Sat)
by gerdesj (subscriber, #5446)
[Link]
I've just had a quick look through something called Linux 0.0.1. I'm happy to be shot down because I'm not a native C reader but I couldn't see any evidence of UID != 0 I did see a directory called /usr/root mentioned though for HOME strangely enough.
Should that original release not be considered Linux anymore? A bit glib maybe but I think the ability to flag away chunks of what is unnecessary for the task in hand is probably a good idea and well within the spirit of "Linux".
My x86 and amd64 usage is rather different from the other arches and this seems to me like yet another arch that simply has different capabilities to many of the other ones. It's possible I might want to make use of that facility (dropping extra code paths if it were possible) even on amd64 if it might improve performance. Give *me* the choice, please.
Posted Feb 12, 2015 9:57 UTC (Thu)
by callegar (guest, #16148)
[Link]
Where does the memory saving come from?
Where does the memory saving come from?
Where does the memory saving come from?
Where does the memory saving come from?
Where does the memory saving come from?
Where does the memory saving come from?
Where does the memory saving come from?
Where does the memory saving come from?
Where does the memory saving come from?
Where does the memory saving come from?
Where does the memory saving come from?
Linux as a single-user system
Linux as a single-user system
Linux as a single-user system
Linux as a single-user system
Linux as a single-user system
Linux as a single-user system
Linux as a single-user system