Re: Making a universal list of syscalls?

[Andy Lutomirski]

On Tue, Mar 4, 2014 at 11:27 AM, H. Peter Anvin <hpa@xxxxxxxxx> 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.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/