[Ksummit-discuss] [CORE TOPIC] Kernel tinification: shrinking the kernel and avoiding size regressions
Jan Kara
jack at suse.cz
Fri May 2 22:04:03 UTC 2014
On Fri 02-05-14 13:11:03, 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.
So I always thought various security modules or audit are there exactly
to limit attack surface like this (now please pardon my ignorance if I'm
wrong because I know close to nothing about the security stuff). So in my
imagination I'd say you could ship even a distro with a default policy
where e.g. r_f_p would be prohibited and if you ever found an application
that needs it, you could create a separate policy for it (and in the ideal
case where the application is packaged by the distro the policy would come
with it). Am I dreaming too much?
Honza
--
Jan Kara <jack at suse.cz>
SUSE Labs, CR
More information about the Ksummit-discuss
mailing list