Are system calls the only way to interact with the Linux kernel from user land?

Question

Are there any other interfaces, e.g. the /proc filesystem?

Answer 1

The Linux kernel syscall API is the the primary API (though hidden under libc, and rarely used directly by programmers), and most standard IPC mechanisms are heavily biased toward the everything is a file approach, which eliminates them here as they ultimately require read/write (and more) calls.

However, on most platforms (if you exclude all the system calls to get you there) there is a way: VDSO. This is a mechanism where the kernel maps one (or more) slightly magic pages into each process (usually in the form of an ELF .so). You can see this as linux-vdso.so or similar with ldd or in /proc/PID/maps. This is effectively memory-mapped IPC between the kernel and a user process (albeit one-way in its current implementation).

It's used to speed up syscalls in general and was originally implemented (linux-gate.so) to address x86 performance issues, but it may also contain kernel data and access functions. Calls like getcpu() and gettimeofday() may use these rather than making an actual syscall and a kernel context switch. The availability of these optimised calls is detected and enabled by the glibc startup code (subject to platform availability). Current implementations contain a (read-only) page of shared kernel variables known as the "VVAR" page which can be read directly.

You can check this by inspecting the output of strace -e trace=clock_gettime date to see if your date command makes any clock_gettime() syscalls, with a working VDSO it will not (the time will be read from the VVARS page by a function in the VDSO page, see arch/x86/vdso/vclock_gettime.c).

There's a useful technical summary here: http://blog.tinola.com/?e=5 a more detailed tutorial: http://www.linuxjournal.com/content/creating-vdso-colonels-other-chicken , and the man page: http://man7.org/linux/man-pages/man7/vdso.7.html

Answer 2

No.

Trivial counter example, this will interact with the kernel:

int main() {
    volatile char *silly = 0;
    *silly = 'a';
}

That'll call the kernel's page fault handler, ultimately resulting in your process getting a SIGSEGV (presuming the compiler doesn't "optimize" that code to do something other than the obvious, since that's undefined behavior by the C standard, make sure to compile with -O0)