[arch-dev-public] Trimming down our default kernel configuration
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) 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. 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
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?
Am 26.03.2014 20:08, schrieb Dave Reisner:
Looks like audit is still built into our kernel. Wasn't this meant to be reverted as well?
Forgot about that. That was pulled in by AppArmor or so.
On 26/03/14 03:08 PM, Dave Reisner wrote:
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.
I think we should keep Yama, because it's a simple knob providing a significant security boost without any integration into our packages. It's an especially nice improvement to many of our services able to run in a chroot, but not yet aware of process namespaces. Yama previously included knobs for protected symlinks and hardlinks, and those became core kernel features. It doesn't really make sense to me that this tiny feature was forced to be an LSM module... it was originally authored as a built-in sysctl switch and perhaps it will move in the future too. If someone wants to support the userspace component of a *non-invasive* (no patches) LSM module in [extra] or [community] down the road, then enabling it would make sense. We're never going to have good SELinux integration, and haphazard patches and policies from the AUR are only going to do more harm than good.
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.
I don't think this actually works properly with our kernel, as I played with it and just got a bunch of broken snapshots. I thought about moving it to [community] in the past, but Mozilla's rewindable debugger has erased any interest I once had in it: http://robert.ocallahan.org/2014/03/introducing-rr.html
On 03/26/2014 07:56 PM, Thomas Bächler wrote:
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.
I'm trying to make use of it since 3.13 and I can't recall if even pre-dump worked fine at least once, so +1. -- Bartłomiej Piotrowski http://bpiotrowski.pl/
On 26/03/14 02:56 PM, 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.
I think we should drop x32 support if no one is planning on packaging the minimum of a compiler and standard C library. It's cool, but no one appears to be very interested in using it in the real world. You would probably get bigger wins from recompiling with -march=native, so I somewhat doubt that anyone grasping for the last bit of performance will use our binaries anyway. This was already responsible for a security vulnerability in Arch: http://seclists.org/oss-sec/2014/q1/187
On Wed, Mar 26, 2014 at 06:53:43PM -0400, Daniel Micay wrote:
On 26/03/14 02:56 PM, 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.
I think we should drop x32 support if no one is planning on packaging the minimum of a compiler and standard C library. It's cool, but no one appears to be very interested in using it in the real world. You would probably get bigger wins from recompiling with -march=native, so I somewhat doubt that anyone grasping for the last bit of performance will use our binaries anyway.
This was already responsible for a security vulnerability in Arch:
Ah, I knew I forgot something from my last email. Yes, x32 should go away if we aren't interested in hosting the toolchain for it.
participants (4)
-
Bartłomiej Piotrowski
-
Daniel Micay
-
Dave Reisner
-
Thomas Bächler