[lkml]   [2013]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [libseccomp-discuss] [PATCH v2] seccomp: not compatible with ARM OABI
On Thursday, November 07, 2013 11:05:26 AM Andy Lutomirski wrote:
> On Thu, Nov 7, 2013 at 10:56 AM, Eric Paris <> wrote:
> > Isn't x32 similarly screwy? Does it work because the syscall numbers
> > are different?
> Yes (from reading the code -- I haven't actually tried it).

I've got a x32 VM that I boot occasionally to test seccomp/libseccomp. For
the purposes of seccomp it looks exactly like x86_64, including sharing the
same AUDIT_ARCH_X86_64 value, the only difference being the syscall number
offset ... Assuming you're using kernel 3.9 or later. Previous kernels had a
bug which stripped the x32 syscall offset so it was impossible to distinguish
from x86_64 and x32 with seccomp. See the following commit for the details:

commit 8b4b9f27e57584f3d90e0bb84cf800ad81cfe3a1
Author: Paul Moore <>
Date: Fri Feb 15 12:21:43 2013 -0500

x86: remove the x32 syscall bitmask from syscall_get_nr()

Commit fca460f95e928bae373daa8295877b6905bc62b8 simplified the x32
implementation by creating a syscall bitmask, equal to 0x40000000, that
could be applied to x32 syscalls such that the masked syscall number
would be the same as a x86_64 syscall. While that patch was a nice
way to simplify the code, it went a bit too far by adding the mask to
syscall_get_nr(); returning the masked syscall numbers can cause
confusion with callers that expect syscall numbers matching the x32
ABI, e.g. unmasked syscall numbers.

This patch fixes this by simply removing the mask from syscall_get_nr()
while preserving the other changes from the original commit. While
there are several syscall_get_nr() callers in the kernel, most simply
check that the syscall number is greater than zero, in this case this
patch will have no effect. Of those remaining callers, they appear
to be few, seccomp and ftrace, and from my testing of seccomp without
this patch the original commit definitely breaks things; the seccomp
filter does not correctly filter the syscalls due to the difference in
syscall numbers in the BPF filter and the value from syscall_get_nr().
Applying this patch restores the seccomp BPF filter functionality on

I've tested this patch with the seccomp BPF filters as well as ftrace
and everything looks reasonable to me; needless to say general usage
seemed fine as well.

Signed-off-by: Paul Moore <>
Cc: <>
Cc: Will Drewry <>
Cc: H. Peter Anvin <>
Signed-off-by: H. Peter Anvin <>

> I've always interpreted the AUDIT_ARCH stuff as meaning that
> (audit_arch, nr) uniquely identifies a syscall and that (audit_arch,
> nr, argument registers) identifies a syscall and its arguments.

That matches my own experience working with seccomp.

> On x32, the syscall invocation instruction is identical to x86_64 and
> the mode of the process has nothing to do with which syscall is
> invoked, so having a different audit_arch is unnecessary (as long as
> the x32 bit in nr is preserved).

paul moore
security and virtualization @ redhat

 \ /
  Last update: 2013-11-08 18:01    [W:0.041 / U:1.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site