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

This is a major pain point for libseccomp, what we have now is passable, and
it works, but I cringe each time I look at it because I worry about
maintaining it. I would be very happy if the kernel had some
header/file/whatever that could be used by userspace applications to map
syscall names/numbers for each architecture.

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

I remember looking into this with libseccomp, around the ARM time frame with
Andy, and I believe I managed to reassure myself - not well, mind you - that
we were *ok* with seccomp/libseccomp. However, having a argument mapping
document/header/etc. would go a long way here.

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

Closely related to item #1. Also a major pain for libseccomp for the same
reasons.

> 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've actually been sitting on some of Andy's libseccomp code for this for a
while now because the solution is very fiddly. Improvements here could make
life much easier for us and remove a lot of my hesitation in merging Andy's
code.

--
paul moore
security and virtualization @ redhat



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