Over the last couple of years, I've been doing a lot of work with containers. Early on I saw a fascinating talk by Julien Friedman where he wrote a bare-bones container in a few lines of Go. It gave me that "a-ha" moment where I grasped that containers are nothing more than Linux processes with a restricted view of the machine they're running on.
Building this restricted view involved quite a few calls in Golang's syscall package. Initially, I just took that at face value, but after a while, I wanted to peel away the next layer of the onion to see what these syscalls are all about and how they work. I'll share what I learned in my talk at OSCON.
As the name suggests, syscalls are system calls, and they're the way that you can make requests from user space into the Linux kernel. The kernel does some work for you, like creating a process, then hands control back to user space.
There is a common mechanism for making all system calls transition into the kernel, which is handled by the libc library. Userspace code sets up some registers including an ID of the system call it wants to make and any parameters it needs to pass to the system call. It triggers a "trap" to transition control to the kernel.
That's how userspace code makes requests of the kernel, but Linux also has pseudo filesystems that allow the kernel to communicate information to user space. The contents look like ordinary directories and files.
The /proc directory is a great example. Look inside, and you'll find all sorts of interesting information about the processes running on a machine. In some cases, like cgroups (control groups), user space can configure parameters by writing into files under these pseudo filesystems.
It's particularly interesting when you're using containers because the host's /proc holds information about all the containerized processes. This includes environment variables, which are also stored in the /proc pseudo-filesystem, meaning that your host machine has access to the environment for all your running containers. This potentially has security consequences if you're passing secrets like certificates or database passwords into your containers through environment variables.
Many programmers working on normal applications may not feel that they're using syscalls very often. In practice, they are, because even everyday activities like making files or changing directories involve syscalls on Linux.
You don't have to be a systems programmer to have fun with syscalls!
If you’d like to learn more, Liz will be presenting A Beginner's Guide To Syscalls at OSCON 2017 in Austin, Texas. If you’re interested in attending the conference, use this discount code when you register: PCOS.
Comments are closed.