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

[Dave Reisner]

On Wed, Mar 26, 2014 at 07:56:26PM +0100, Thomas Bächler wrote:
> Hello all,
> 
> it won't be too long until 3.14 is out and I want to address a topic
> that has been bugging me for a while. Our kernel includes everything and
> the kitchensink. I have no problem with delivering drivers that can be
> built modular, but there are other things that have an unknown impact on
> everyone.
> 
> I want to trim our kernel down to what we actually support.

+1

> 1) Once we agreed to disable one LSM, everyone else said "we can enable
> LSM XYZ, too". And so we did. Right now, we enable SELinux, SMACK,
> Tomoyo, AppArmor and Yama, although we don't support the userspace for
> any of those.
> 
> I propose to drop all of them.

Very much agreed. Though, I wouldn't mind if we kept yama around in some
disabled form if possible. There's no userspace component here, just the
ptrace_scope knob in sysctl, which a lot of other distros enable.  It
affects a rather small number of app, but potentially closes off a
fairly large security concern.

> 2) We patch our kernel to allow enabling CHECKPOINT_RESTORE without
> enabling CONFIG_EXPERT. I have no idea what the impact of this option
> is, other than that it was requested in order to support some tool that
> can freeze and save single processes resume them later. I am generally
> sceptical towards options that require CONFIG_EXPERT, so I propose
> dropping this one, too.

CRIU userspace tools are in the AUR. +1 to dropping this unless we have
someone to wants to actually maintain this in the repos.

> 3) We enable tons of debug options in the "Kernel Hacking" section, many
> of which have a "small performance impact". I'd like to get rid of those
> that we don't need (I didn't go through all of them yet).
> 
> What I'd like is a discussion where people suggest more things that
> could or should be dropped, and tell me what is absolutely needed and
> why. I hope that such a discussion makes it clearer to me how I should
> proceed.

Looks like audit is still built into our kernel. Wasn't this meant to be
reverted as well?