Re: support for calling Linux syscalls directly

[Kees Cook <keescook at chromium dot org>]

On Wed, Jan 30, 2013 at 3:01 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 01/24/2013 08:14 PM, Mike Frysinger wrote:
>> spawning a new thread w/summarized info because the previous ones
>> were going in circles of "read the previous thread".  so i read
>> them.
>>
>> to summarize, the anti-arguments were: - it pollutes the ABI - it
>> takes up code space and sits there largely unused - there are few
>> users to justify the overhead - people can use syscall() directly
>> - the kernel people could provide their own header
>>
>> while the pro-arguments are: - we already have a bunch syscall
>> trampolines, some very old (init_module) while others are recent
>> (process_vm_readv, setns) - having a single "authoritative"
>> prototype location is better than people open coding it in every
>> project (especially when documentation is often scare to
>> non-existent) because it's very error prone - a kernel header
>> easily introduces API (define/enum/structure/etc...) collisions
>> (see recent network header thread as an easy example) that are non-
>> trivial to resolve
>>
>> looking at linux/syscalls.list, there's actually quite a number in
>> there that i'd classify on the "uncommonly used" side, although
>> i'll grant that kexec is pushing the edge.
>>
>> from the "pro" pov, i don't think people care whether the syscall
>> is in the shared C library and part of the official ABI.  the
>> focus is on there being 1 header for code to include.  so i wonder
>> if we couldn't satisfy people by providing either static inlines or
>> a libsyscall_nonshared.a that is referenced via the libc.so linker
>> script.
>
> I have had a number of discussions with people on this topic,
> especially given that syscall(3) is fundamentally flawed on a number
> of architectures, and that some architectures have been forced to use
> nonstandard signatures, complicating things.
>
> What I think makes sense is to create a library separate from glibc
> presumably called libinux containing the Linux-specific bits.  This
> libinux could ideally not just service glibc but also uClibc and
> Bionic (klibc itself is a little too "special" in that it doesn't have
> a dynamic linker at all.)
>
> My intent was to revamp the infrastructure from klibc to create
> libinux, and eventually try to get it into the Linux kernel tree so
> that when new oddball system calls are added we can get everything in
> one place -- headers (with the recent uapi work), library, and of
> course the kernel itself.
>
> The "red line" for this library should be if it interacts with
> non-kernel data types in any kind of nontrivial way.
>
> What do you think?

This makes sense. Especially given that the syscalls mentioned in the
other thread really are unique to Linux, and arguable don't belong in
the (supposedly) kernel-agnostic world of glibc.

-Kees

--
Kees Cook
Chrome OS Security