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

[Theodore Ts'o <tytso@mit.edu>]

On Fri, May 02, 2014 at 03:49:35PM -0400, Dave Jones wrote:
> 
> I may have a vested interest in syscalls :)

Well, yes, fair enough.  :-)

> And then we have "enable boatload of code" syscalls that are typically
> used by a few standalone apps/features. kexec, checkpointing, whatever
> db it was that cares about remap_file_pages, mempolicy, etc. etc.

Sure, that's fair enough.  I would just use a somewhat broader
definition of "boatload of code", since not all of these boatloads are
accessed via system calls.  Some are accessed via new pseudo-file
systems, some via new ioctls, some via new fallocate code points, etc.

> It's this "not used by every user" code that tends to scare me, because
> it's written with 1-2 well behaved bits of userspace in mind, which
> usually means "has so many unchecked corner cases it's not even funny"

And I think we can also further break this down into the classes of
code which require root privs (i.e., like kexec), and those which can
be used by any userid.  It's the latter which is much more problematic
from a security perspective --- as well from a "it's much harder to
change the ABI without breaking large numbers of userspace programms".
(Where as if it's only being used by 1-2 well behaved bits of
privileged userspace, it's actually a tiny bit easier to evolve the ABI.)

So perhaps what that means it that _these_ are the features which
require the most amount of paranoia and testing before we let them
into the mainline kernel in the first place.  Otherwise, once they get
in, there's always a chance that systemd or some other piece of
userspace will strict strictly requiring said optional feature, and it
doesn't matter whether we put in a CONFIG option to disable the
feature --- we'll never be able to do it.

	    	  	   	      - Ted