Re: support for calling Linux syscalls directly

["H. Peter Anvin" <hpa at zytor dot com>]

On 01/30/2013 09:56 PM, Mike Frysinger wrote:
> On Wednesday 30 January 2013 18:01:54 H. Peter Anvin wrote:
> > 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.
>
> could you elaborate on syscall(3) limitations ?  we used to have syscall#()
> inline funcs exported at various places (including the kernel's own headers),
> and those were a pain to maintain as well.  PIC issues readily come to mind.
> although, if we have explicit buy in from the kernel peeps to maintain it in
> all the various userland setups, it should be a much nicer ride.

The ugliest problem is on 32-bit architectures that require register 
alignment for 64-bit arguments.  There the extra argument to syscall(3) 
will push the rest of the registers out of alignment.  Then you have 
issues like the fact that s390 has a completely different calling 
convention for 6-argment system calls, that ARM likes to swap argument 
orders from other architectures due to its multiple calling conventions 
and you have a total mess.

The klibc infrastructure I refer to does not use inlines; instead it 
uses machine-generated assembly stub functions generated from a 
description file which looks a lot like C prototypes:

https://git.kernel.org/?p=libs/klibc/klibc.git;a=blob;f=usr/klibc/SYSCALLS.def;hb=HEAD

Obviously most system calls in that file would not be relevant.

> > 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.
>
> will the kernel types get namespaced ?  or will it rely on the C library to
> provide the proper structures (according to relevant standards) ?  the problem
> we have currently with the network headers is they define the same structure
> name.  we don't want to have that be the starting point for a new lib, and it
> seems like it'd be real easy for that to become more of a problem.  another
> example is handling of bits that often share the enum/define names such as stat
> or fcntl or mmap.
>
> > The "red line" for this library should be if it interacts with
> > non-kernel data types in any kind of nontrivial way.
>
> that's a good boundary to lay down.  i fear without rigorous control, it will
> be ripe for abuse by people to bypass glibc, or grow into an ugly monolithic
> mountain due to feature creep.

Well, the situation is only worse in every way with syscall(3).  There 
you may end up with glibc types being passed to the kernel without any 
kind of type checking, or even misaligned or swapped, and it works on 
some architectures and not others.

Either way, communication between kernel and glibc maintainers will 
obviously be necessary.  I will try to do my part in that.

	-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.