Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 8 Sep 2012 18:14:49 -0400
From: Rich Felker <>
Subject: Re: capset() capget() syscalls

On Sat, Sep 08, 2012 at 05:02:35PM +0100, Justin Cormack wrote:
> On Fri, Sep 7, 2012 at 5:56 AM, Rich Felker <> wrote:
> > On Thu, Sep 06, 2012 at 09:22:58AM +0100, Justin Cormack wrote:
> >> For reference (this list is not complete), Musl is missing the
> >
> > Would you be willing to complete this list and submit a patch to add
> > all the missing syscalls?
> >
> OK stage 1, I have gone through all the syscalls (on x64) to work out
> what is missing. As people have been going and adding them there are
> now not that many that should definitely be in.
> missing and should definitely be in:
> accept4
> acct
> dup3
> ppoll
> preadv
> pwritev
> recvmmsg
> setdomainname
> setns
> syncfs

Agreed. Most of them are trivial to add, but acct may be problematic
unless we also add the ugly header with the struct definitions for
on-disk representation of process accounting info. Otherwise, programs
might assume it exists since acct exists and break when it doesn't.

Also, recvmmsg will require the same ugly kernel bug workarounds as
revcmsg requires, on 64-bit targets. Since there's not just one msghdr
to fix up, but a whole list of them, there may not be temporary
storage available for all of them. I think it might be easier/cleaner
to just unconditionally call recvmsg in a loop in this case,
implementing the MSG_WAITFORONE logic in userspace if possible. Of
course this eliminates all the performance advantages of recvmmsg on
64-bit machines. I think we really need to get the kernel folks to fix
the underlying bugs, and then we can make the workarounds conditional
on kernel version...

> missing but fairly specialist (or not useful), not sure if some should
> be exposed, not all in glibc (some are very new):
> create_module

Deprecated, part of the ancient (2.2? 2.0?) kernel module interface, I

> exit_group

This is actually the syscall for the exit function. The syscall named
"exit" is the syscall for the pthread_exit function. It's confusing.

> futex

glibc does not expose this as far as I know. I would not be opposed to
having sys/futex.h however. It's less ugly than having to use
linux/futex.h and syscall()...

> get_kernel_syms

Probably deprecated..?

> clock_adjtime

Modern, should be exposed.

> get_thread_area

Largely useless, and intended only for use in implementing pthreads.

> io_cancel, io_destroy, io_getevents, io_setup, io_submit (ie native
> Linux aio not posix aio)

Is there any legitimate user of this horrible API? Last I checked
these functions were only useful for block-aligned IO on block devices
and the impression I got was that they were designed solely for
Oracle's use. (puke) I suppose they could be useful for FUSE drivers
too, however. We can add them if they have legitimate software that
needs them.

> kexec_load

Useful, especially for certain embedded systems.

> lookup_dcookie
> migrate_pages
> mincore

Not sure about these; possibly useful.

> modify_ldt

Probably useful for dosemu or something...

> mqgetsetattr (used internally to provide mq interfaces)

Indeed; we already use it there.

> name_to_handle_at
> nfsservctl
> open_by_handle_at

Useful for userspace nfsd, maybe other similar things.

> perf_event_open
> getcpu
> personality

Not sure about these.

> process_vm_readv
> process_vm_writev

These are supported.

> query_module

Almost surely deprecated.

> quotactl
> remap_file_pages

Probably useful. Don't know details.

> sched_setaffinity, sched_getaffinity (note glibc uses different
> interface to syscalls)

Useful, I think, but we should provide the libc api, not the low-level
syscall api.

> sendmmsg (probably should be in but no man page on my box)

Same issue as recvmmsg. Very useful but likely buggy.

> set_robust_list
> set_thread_area
> set_tid_address

Only meaningful to the pthreads implementation, and already used
internally there. Any direct use of these by an application is likely
to cause dangerous breakage of implementation internals.

> sigaltstack

Already used.

> restart_syscall

This is a kernel implementation detail related to signal handling and
avoiding EINTR.

> tgkill

Used internally in pthread. Not sure if it's useful to provide to apps

> obsolete or unimplemented in Linux
> [...]


> unknown (eg no man page on my box, probably obsolete or should not be
> exported, but check)
> afs_syscall
> arch_prctl
> get_robust_list

arch_prctl is used internally for threads on x86_64. The others seem

> syscall differs in prototype etc (probably missing some of these):
> clone

We provide clone.

> only exposed as weak alias:
> getdents
> vfork

There's no "only" to it; the reason it's weak is so that we can use
the namespace-safe __-prefixed names for these functions without
polluting the external namespace.

> These are in libkeyutils even though they are syscalls:
> add_key
> request_key
> keyctl

Not even sure what they're for. But I don't think they're a priority
if glibc does not even have them internally.

> These are in libnuma, even though they are syscalls
> move_pages
> mbind
> get_mempolicy
> set_mempolicy


> naming differences (including 64), ignore this list:
> fadvise64 is posix_fadvise
> fstat
> fstatat, newfstatat
> lstat
> signalfd4
> syslog is klogctl

Indeed, these can be ignored.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.