lkml.org 
[lkml]   [2014]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [libseccomp-discuss] Making a universal list of syscalls?
From
Date
On Thu, 2014-02-27 at 12:40 -0800, 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.

userspace audit a 3rd.

> 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.

I know for audit it would be huge if userspace didn't try to organically
grow this knowledge on their own! So +1 from me!

>
> Issues here: some syscalls have different signatures on different
> architectures. Maybe we could require that a canonical syscall name
> would have the same signature everywhere, but architectures could
> specify alternate names. So, for things like clone (?), there could
> actually be a few syscalls that all have alternate names of "clone".
>
> More importantly, we could add a library in tools that exposes this
> information to userspace. Useful operations:
>
> - For a given (arch, nr), indicate, for each logical argument, which
> physical argument slot is used or, if the argument is split into a
> high and low part, which pair of slots is used.
>
> - For a given (nr, logical args), issue the syscall for the
> architecture that build the library.
>
> - For a given (arch, nr, logical args), issue the syscall if
> possible. An x86_32 build could issue x86_64 syscalls with some
> effort, and an x86_64 build could easily issue 32-bit syscalls.
>
> - For a given arch, map between name and nr, and give access to the signature.
>
> If this happened, presumably all architectures that supported it would
> have to have valid AUDIT_ARCH support. That means that someone would
> have to fix ARM OABI (sigh).
>
> Thoughts?



\
 
 \ /
  Last update: 2014-02-27 22:41    [W:0.120 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site