[arch-general] [arch-dev-public] Trimming down our default kernel configuration
lisaev at umail.iu.edu
Wed Mar 26 15:18:43 EDT 2014
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
> 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
GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: not available
More information about the arch-general