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

["Bird, Tim" <Tim.Bird@sonymobile.com>]

On Friday, May 02, 2014 10:11 AM, Dave Jones wrote:
> 
> 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?

For deeply embedded, I think a good technique is to fine-tune the syscalls to the exact set of programs
that will be run.  For my size research last year (See http://elinux.org/System_Size_Auto-Reduction
and http://elinux.org/images/9/9e/Bird-Kernel-Size-Optimization-LCJ-2013.pdf), I discussed
some results from doing the following:
 - scanning the all the binaries in the file system
 - generating a list of used and unused system calls
 - adding a kernel mechanism to eliminate any unused syscalls, at compile time
   (using LTO, all I had to do was make the syscall unreachable, and the compiler
   eliminated the calls automatically.  Some of the work was removing parts of Andy Kleen's LTO
   patches which prevented unreferenced code from being optimized out.)

The syscalls were detected with a tool that scanned the program's assembly code on ARM,
and found all syscall sequences.  Binaries were statically linked for analysis.

On a default-configured kernel, the system eliminated 161 syscalls, and saved about 95k.
On a minimally configured kernel, the system eliminated 120 syscalls, and saved 48K.

The remaining syscalls for my minimal system consisting of busybox and a web server
was 184 syscalls.  with additional coding and refactoring of the app and busybox, additional
syscalls could have been eliminated.

Some syscalls that were unused, still ended up hanging around due to a few funny references.
With some code refactoring, some additional savings might be possible.

Note that this system required no new kernel CONFIGs, and used macros to hide most of the
complexity from the rest of the kernel source.

I did some other automatic code elimination techniques, with varying results.  These can be seen
in the presentation.
 -- Tim

P.S. I realize this technique is not suitable for general-purpose distributions of Linux.