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

Thu Mar 27 16:59:31 EDT 2014

I am a complete noob and only follow the lists out of interest. I am
also very young, so please forgive my impertinence. Thanks Thomas for
your work!! Just my 2c:

On 03/27/2014 08:34 PM, Nicolas Iooss wrote:
> 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".

Because of this: "Arch Linux defines simplicity as without unnecessary
additions, modifications, or complications, and provides a lightweight
UNIX-like base structure that allows an individual user to shape the
system according to their own needs. In short: an elegant, minimalist
approach."[1]

The main kernel *should* be simple *_by that definition_*. From my
(limited) point of view, the default in Arch should always be the most
lightweight, practical solution. This is not RHEL or Ubuntu, we have a
very limited workforce and want to be simple.

I hope that I didn't offend anybody.

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

Cheers,
Bennett

[1]source: https://wiki.archlinux.org/index.php/The_Arch_Way

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20140327/f933a883/attachment.asc>