Re: [Ksummit-discuss] [CORE TOPIC] Kernel tinification: shrinking the kernel and avoiding size regressions

[Dave Jones <davej@redhat.com>]

On Fri, May 02, 2014 at 09:44:42AM -0700, Josh Triplett wrote:
 
 > Topics:
 > - Kconfig, and avoiding excessive configurability in the pursuit of tiny
 > - Optimizing a kernel for its exact target userspace.
 > - Examples of shrinking the kernel

Something that's partially related here: Making stuff optional
reduces attack surface the kernel presents. We're starting to grow
more and more CONFIG options to disable syscalls. I'd like to hear
peoples reactions on introducing even more optionality in this area.

I first started thinking about this at LSF/MM where the subject of
sys_remap_file_pages came up. "What even uses this?" "hardly anything".
But for all the users that don't need it, there's this syscall always
built in that does horrible things with VM internals.  It's fortunate
that there hasn't been anything particularly awful beyond simple DoS
bugs in r_f_p.

Distribution kernels are in the sad position of having to always enable
this stuff, but at least for people building their own kernels, or
kernels for appliances, we could make their lives a little better by
not even building this stuff in.

I had a patch to make this particular syscall a cond_syscall, but then
XFS ate my homework and I haven't had chance to revisit this.
So, my questions are:
- are there other obvious syscalls we could make optional without userspace
  freaking out when they suddenly start getting ENOSYS ?
- how much configurability here is too much ?
  r_f_p was an obvious candidate because it's.. well, nasty.  Some of the
  more straightforward syscalls may not be such a big deal, but then we
  have CONFIG's for kcmp and other 'simple' syscalls already..

thoughts?

	Dave