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

[Ben Hutchings <ben@decadent.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 2554 bytes --]

On Fri, 2014-05-02 at 15:49 -0400, Dave Jones wrote:
> On Fri, May 02, 2014 at 03:33:14PM -0400, Theodore Ts'o wrote:
>  > There's been a huge focus on system calls in this discussion, and I
>  > suspect this is a bit of a red herring.  Taking a look at "git log
>  > arch/x86/syscalls/syscall_64.tbl" --- since all the world's is no
>  > longer a Vax, but rather an x86_64 :-P --- there really hasn't been
>  > that many new system calls lately.
> 
> I may have a vested interest in syscalls :)
> 
> The rate we're adding them has slowed down, but the rate at which we're
> finding bugs exposed through them has accelerated enormously over the
> last few years.
> 
> To use just one example, on certain systems I'd love to be able to just
> turn off sys_perf_event_open given what a trainwreck of vulnerabilities it's been
> over the last few years [comedy: it is actually a config option, but x86
> 'selects' it, so you'll have it and you'll like it].
> Thankfully at least the scarier parts of it are now hidden behind the
> paranoid sysctl.

I have considered proposing perf_event_paranoid=3 to disable it
completely for non-root.

>  > And if you look at things like renameat(2), the actual code savings by
>  > removing renameat(2) is pretty small, and IMHO, not worth the
>  > complexity and uncertainty that it would represent to application
>  > programmers of "does this system call exist or doesn't it".
> 
> I think we've got two categories here.
> 
> "variant" syscalls like renameat, which just offers enhancements over
> an existing syscall. Stuff that things like glibc tend to care about.
> This stuff is usually pretty boring, and not even worth considering for
> potentially disabling imo.
> 
> 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.
> 
> 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"
[...]

Since Michael often seems to be the one testing those corner cases while
writing documentation, it seems like you're getting back to the old
issue of whether lack of documentation should be a blocker for adding
new system calls.

Ben.

-- 
Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]