[arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Nicolas Iooss]

2014-03-27 16:31 GMT+01:00 Bigby James <bigby.james at crepcran.com>:
> On Thu, Mar 27, 2014 at 09:07:23AM +0100, Nicolas Iooss wrote:
>>
>> Here are three arguments to motivate my disagreement.
>>
>> * First, removing LSM support makes it difficult for users to test
>> LSM. Before 3.13 kernel, users needed to recompile their kernel (or to
>> install linux-selinux AUR package) to be able to use SELinux. This is
>> a hard first step and I know too many people who thinks "I don't want
>> to recompile my kernel as I've already done magical things to make my
>> graphic card works and I don't want to break my fragile config". Now
>> people just needs to install packages (from unofficial repos or from
>> the AUR) as described in the wiki [4] and reboot to start using
>> SELinux.
>> * Second, it's possible to compile things which are disabled at
>> runtime. For example, I don't need to compile the kernel without IPv4
>> to test what breaks when running a non-IPv4 kernel, I only need to add
>> a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing
>> for LSM. Even if they are compiled, they can be enabled/disabled with
>> such runtime configuration and this config doesn't require much work.
>> * Third, users who want to combine several unofficial features for
>> their kernel already have to do weird things. For example, I'm using a
>> grsec kernel with SELinux. A few months ago, there were linux-grsec
>> and linux-selinux in the AUR but no package which provided both. Hence
>> I needed to build a custom package to have both. Now, the next time
>> linux-grsec's maintainer will sync its config with the official repo,
>> SELinux will be available in this package (unless I've missed
>> something) and I'll no longer need to build my custom kernel.
> 
> As a lowly end-user, I'll have to disagree with you. The bulk of your reasoning
> comes down to "*I* use it, so don't take it away from me." But your case is
> hardly representative; I highly doubt that the typical desktop user (that is,
> the typical Arch user) makes use of SELinux or its cohorts; no doubt there are
> people running Arch servers that use it, but again that's not representative of
> the community at large, in which many people just install Arch on their laptops
> and desktops for everyday production and entertainment use.
>  
> When I build a custom kernel for my laptop, the LSM stuff and kernel debugging
> options are the first to go, as they have absolutely no benefit for someone who
> uses a computer primarily for reasearch and writing, coding and design work, web
> browsing and music.  They're complements for specific use-cases---server
> administration (most likely when multiple users are involved) and kernel
> hacking, respectively---and are of no use to anyone who doesn't partake in those
> use-cases (how necessary is MAC to someone who interacts with and monitors a
> single machine all day?). Besides, as you've said, you already need to build the
> userspace utilities from source (because not too long ago, the devs voiced their
> opposition to maintaining SELinux officially), so leaving such features in the
> kernel to ease "testing" is both specious and a mismeasure of how useful or
> vital they might be. Suppose the majority of people who test SELinux decide to
> drop it, as seems to be the case in my (admittedly limited) observations. Of
> what value, then, is the work the devs did to maintain it?
> 
Sorry if my message sounded too much as "I use it so I want other people
to make my life easier". That was not the intended tone at all. If you
need a bit more background about how I use ArchLinux, let me say I'm
using it on my laptop, where I don't fear to do things that breaks my
system (and if often breaks) because I have easy physical access. When I
needed to set up SELinux on a server (not running Arch) a few months
ago, I decided to first familiarize myself with this software on my
laptop. It took me a long time before having a working system and I'm
trying to reduce that time for other users who might have same ideas as
I (eg. by reporting and helping fixing bugs like
http://lists.gnu.org/archive/html/bug-coreutils/2014-01/msg00009.html).

Of course, I'm biased when I speak of SELinux so basically I try to
imagine the state of mind of "normal" people by replacing "SELinux" with
"Linux containers", which I've never used and see as unneeded weight
(this is a biased unmotivated statement which may be untrue). I don't
know if currently to run LXC or systemd-nspawn you need to recompile
your kernel, but you need at least UTS namespaces, network namespaces...
and I don't know if anyone will consider disabling these features, but I
expect voices to be raised if someone thinks of removing CONFIG_UTS_NS
and CONFIG_NET_NS (or are such decisions expected to happen without
anybody noticing?).

>> That been said, I agree that having a kernel with less features would
>> be good. To my mind, here are possible ways :
>>
>> a) Create a linux-light package with less features than the linux
>> package, and don't trim linux' configuration.
>> b) Rename linux as "linux-full" (as an official package) and trim linux' config.
>> c) Create a package ("linux-src"?) which install the kernel sources
>> and provides an easy way to customize the config before making the
>> packages (with pkgbuild). Currently linux-grsec AUR package provides
>> this feature by using the MENUCONFIG environment variable [5].
>> d) Don't create new packages and trim linux' config (this is your
>> idea, if I understood correctly).
>>
>> Any of a) or b) would suits fine for me if you choose to drop LSM in
>> the lighter config.
>>
> 
> I've used Arch for years now, but I can remember what it was like as a n00b.
> From the perspective of someone who is new to Arch, this is grossly misleading.
> Someone unfamiliar with how Arch packaging works (or a long-term Archer who
> doesn't pay close enough attention to the news and mailing lists) will
> conceivably reason that "linux-full" = "linux-not-broken," and "linux-light" and
> "linux-src" = "I have to screw with it for two hours to get my GPU working."
> They'll likely just install linux-full anyway, unaware of the distinction. 
> 
> It seems far more reasonable to me to trim the kernel to those things typical of
> everyday desktop use, and trust that members of the community will maintain
> those things which they find useful separately. I don't mean to be presumptuous,
> but it's my understanding that the primary goal of the Arch devs and repo
> maintainers is to provide a minimal, functional distribution platform that users
> can utilize to craft their systems as they see fit. They don't want to cover
> every imaginable use-case, but provide users with tools with which to fulfill
> their own desires and needs themselves. What the devs provide in the base group,
> the [core] and [extra] repos are those things most common for mundane computer
> use via Linux-based operating systems. Special use cases are precisely what ABS
> and the AUR are there for.
> 
> Requiring people to build a custom kernel in order to *not have these features*
> is the exact situation are already in *right now.* Asking the devs to maintain
> multiple kernels just to save what I suspect is a minority---who already build
> several packages from the AUR, for rarely used functionality---a little time
> isn't reasonable.  Moreover, while I may mistake your meaning, the list above
> reads like you're asking the developers to make your preferred kernel build the
> default, and reasoning that "It's no big deal, if people don't want that stuff
> they can just build their own through ABS." That's not a solution at all, and
> again, *it's already the case right now.*
> 
Ok, my wording had been really bad if people understood that :( What I'm
trying to do is to make things easier for other people, not myself
(whatever the final decision is, I'll still use Arch in a config which
is not the default), and I certainly don't want the devs to waste time
doing duplicated work.

The ideas of having multiple supported kernel was a bad one (and thanks
for pointing that out) but I needed to ask what I asked to understand
better (and to make people with similar questions as I understand
better) why this thread is about "shrinking the supported kernel
configuration" and not about "creating a new smaller kernel".

My post was also to start thinking of what I will answer to people in a
few months when they'll ask "why do I need to recompile my kernel to use
SELinux? I don't have to recompile sudo to have OpenLDAP support?"
(these are quite random package names). I'll answer these people that
the kernel is not a package like others and that most people want a
kernel as small as possible, but don't care about feature-complete packages.

Thanks,

Nicolas