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 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
