This is the mail archive of the
mailing list for the glibc project.
Re: support for calling Linux syscalls directly
- From: Kees Cook <keescook at chromium dot org>
- To: "H. Peter Anvin" <hpa at zytor dot com>
- Cc: Mike Frysinger <vapier at gentoo dot org>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 30 Jan 2013 15:22:44 -0800
- Subject: Re: support for calling Linux syscalls directly
- References: <firstname.lastname@example.org><5109A662.email@example.com>
On Wed, Jan 30, 2013 at 3:01 PM, H. Peter Anvin <firstname.lastname@example.org> 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
>> 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
> 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.
Chrome OS Security