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

[Leonid Isaev]

On Wed, 26 Mar 2014 19:56:26 +0100
Thomas Bächler <thomas at archlinux.org> 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.

Thanks for doing this.

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

I agree regarding SELinux/Apparmor (it's not only userspace tools, but also
sane application policies that are missing).

However, I don't think that Yama requires any userspace components, does it?
Currently, I boot with "security=yama" and completely disabled non-admin
ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama
available albeit disabled by default (as they now do).

> 
> 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.
> 
> 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.
> 
> Regards
> Thomas
> 

Best,
-- 
Leonid Isaev
GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20140326/1446d0da/attachment.asc>