lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 5 Mar 2014 16:13:25 -0800
From:	Andy Lutomirski <>
To:	"H. Peter Anvin" <>
Cc:	"" <>,
	linux-arch <>,
Subject: Re: Making a universal list of syscalls?

On Tue, Mar 4, 2014 at 11:27 AM, H. Peter Anvin <> wrote:
> On 02/27/2014 12:40 PM, Andy Lutomirski wrote:
>> Currently, dealing with Linux syscalls in an architecture-independent
>> way is a mess.  Here are some issues:
>>  1. There's no clean way to map between syscall names and numbers on
>> different architectures.  The kernel contains a number of tables (that
>> work differently for different architectures).  strace has some arcane
>> mechanism.  libseccomp has another.
>>  2. There's no clean way to map between syscall argument registers and
>> logical syscall arguments.  Each architecture knows how to do it, as
>> do strace and glibc, but I suspect that *everyone* else gets it wrong.
>>  Especially on ARM.
>>  3. Determining which architectures have which syscalls is a mess.
>> Recent kernel builds love to warn me that finit_module is missing on
>> x86_64.  This is simply not true.  I have no idea why.
>>  4. Actually issuing a nontrivial syscall is annoying.  syscall(2) can
>> do it for the native architecture (only).
>>  5. Decoding ucontext from SIGSYS is a mess.  I have prototype code
>> for libseccomp that can do it, but it gets the arguments wrong due to
>> ABI issues.  See (2).
>> I'd like to see a master list in the kernel that lists, for every
>> syscall, the name, the number for each architecture that implements it
>> (using the AUDIT_ARCH semantics, probably), and the signature.  The
>> build process could parse this table to replace the current per-arch
>> mess.
> Hi Andy,
> I have brought that up a lot of times, originally dating back from my
> work on klibc.  I have tried to keep the klibc syscall list in a sane
> format with architecture annotations, but it doesn't contain all the
> syscalls in the system.
> Extending that work and making it encompass everything the kernel
> exports would be highly useful, but it would take a lot of work.

I think that SYSCALLS.def won't work as is -- SYSCALLS.def
references unistd, which ought to be autogenerated from the syscalls
list.  But a somewhat less magical variant should work.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists