Linux System Call Table

These are the system call numbers (NR) and their corresponding symbolic names.

These vary significantly across architectures/ABIs, both in mappings and in actual name.

This is a quick reference for people debugging things (e.g. seccomp failures).

For more details on syscalls in general, see the syscall(2) man page.

Random Names

Depending on the environment you're in, syscall names might use slightly different naming conventions.

The kernel headers (e.g. asm/unistd.h) use names like __NR_xxx, but don't provide any other utility code. The C library headers (e.g. syscall.h & sys/syscall.h) use names like SYS_xxx with the intention they be used with syscall(...). These defines will be exactly the same -- so __NR_foo will have the same value as SYS_foo.

Which one a developer chooses to use is a bit arbitrary, and most likely belies their background (with kernel developers tending towards __NR_xxx). If you're writing userland C code and the syscall(...) function, you probably should stick to SYS_xxx instead.

The short name "NR" itself just refers to "number". You might see "syscall number" and "NR" and "syscall NR" used interchangeably.

Another fun difference is that some architectures namespace syscalls that are specific to their port in some way. Or they don't. It's another situation of different kernel maintainers making different choices and there not being a central authority who noticed & enforced things. For example, ARM has a few __ARM_NR_xxx syscalls that they consider "private", and they have a few __NR_arm_xxx syscalls to indicate that they have a custom wrapper around the xxx syscall!

Another edge case to keep in mind is that different architectures might use the same name for different entry points. It's uncommon, but can come up when looking at syscalls with variants. For example, an older architecture port might have setuid & setuid32 while newer ones only have setuid. The older port's setuid takes a 16-bit argument while the newer port's setuid takes a 32-bit argument and is equivalent to setuid32. There are many parallels with filesystem calls like statfs & statfs64.

Kernel Implementations

The cs/ links to kernel sources (used in the table below) are best effort. They focus on the common C entry point, but depending on your execution environment, that might not be the first place the kernel executes.

Every architecture may point a syscall from its initial entry point to custom trampoline code. For example, ARM's fstatfs64 implementation starts execution in sys_fstatfs64_wrapper which lives under arch/arm/ as assembly code. That in turn calls sys_fstatfs64 which is C code in the common fs/ tree. Usually these trampolines are not complicated, but they might add an extra check to overall execution. If you're seeing confusing behavior related to the C code, you might want to dive deeper.

When working with 32-bit ABIs on 64-bit kernels, you might run into the syscall compat layers which try to swizzle structures. This shows up a lot on x86 & ARM systems where the userland is 32-bit but the kernel is 64-bit. These will use conventions like compat_sys_xxx instead of sys_xxx, and COMPAT_SYSCALL_XXX wrappers instead of SYSCALL_XXX. They're responsible for taking the 32-bit structures from userland, converting them to the 64-bit structures the kernel uses, then calling the 64-bit C code. Normally this conversion is not a problem, but if the code detects issues with the data structures, it'll error out before the common implementation of the syscall is ever executed.

The Android/ARC++ container executes under the alt-syscall layer. This allows defining of a custom syscall table for the purpose of hard disabling any syscalls for all processes (without needing seccomp), or for adding extra checks to the entry/exit points of the common implementation, or stubbing things out regardless of any arguments. All of this code will run before the common implementation of the syscall is ever executed. Since the tables are hand maintained in our kernel (and not upstream), new syscalls aren't added to the list automatically, so you might see confusing errors like ENOSYS, but only when run inside of the container. If you're seeing misbehavior, you should check to see if alt-syscall is enabled for the process, and if so, look at the wrappers under security/chromiumos/.

Syscall Availability

Unfortunately, having a syscall number defined at compile time is not a guarantee that the syscall will exist at runtime. In other words, you can still see ENOSYS when using it. This can occur for many different reasons:

• The syscall depends on a kernel config setting that is not enabled.
• The program is running on a kernel that doesn't support the syscall.
• The seccomp filter forces ENOSYS for the syscall (uncommon).
• The alt-syscall layer does not have the syscall registered (uncommon).

While the kernel headers version is kept in sync with the oldest kernel version that we currently support, we sometimes backport userland API (UAPI) header changes so programs can rely on structures or defines existing without having to copy fallbacks into every project. We rarely however backport large new features in the kernel itself, especially syscalls/subsystems that can be disruptive & risky. The expectation is that programs using those APIs know they have to check at runtime whether the functionality is available, and if not, gracefully fallback.

This can also help people writing seccomp filters with minijail so that they can use the syscall constant even if the kernel doesn't support it -- the seccomp filter only cares about the number when checking things. We don't support different filters based on the device or kernel version.

Calling Conventions

Here's a cheat sheet for the syscall calling convention for arches supported by ChromeOS. These are useful when looking at seccomp failures in minidumps.

This is only meant as a cheat sheet for people writing seccomp filters, or similar low level tools. It is not a complete reference for the entire calling convention for each architecture as that can be extremely nuanced & complicated. If you need that level of detail, you should start with the syscall(2) notes, and then check out the respective psABI (Processor Specific Application Binary Interface) supplemental chapters.

*** note The arg0 names below match minijail's seccomp filter syntax. It's not uncommon for source code to count from 1 instead of 0, so be aware as you go spelunking into implementations.

Tables

x86_64 (64-bit)

Compiled from Linux 4.14.0 headers.

arm (32-bit/EABI)

Compiled from Linux 4.14.0 headers.