Linux 系统调用的初学者指南
系统调用 容器
![A beginner's guide to Linux syscalls](/data/attachment/album/201705/29/223115moblccxqorxlcbe3.png "A beginner's guide to Linux syscalls")


在过去的几年中，我一直在做大量容器相关的工作。先前，我看到 [Julien Friedman](https://twitter.com/doctor_julz) 的一个很棒的演讲，它用几行 Go 语言写了一个容器框架。这让我突然了解到容器只是一个受限的 Linux 进程中的机器。


构建这个受限视图涉及到 [Golang 系统调用包](https://golang.org/pkg/syscall/)中的很多调用。最初，我只是用到了表面的那些，但过了一段时间，我想剥下洋葱的下一层，看看这些系统调用是什么，以及它们的工作原理。我将在 OSCON 的演讲中分享我所学到的东西。


顾名思义，[syscalls](http://man7.org/linux/man-pages/man2/syscalls.2.html) 即系统调用，它们是你从用户空间请求进入 Linux 内核的方式。内核为你做一些工作，例如创建一个进程，然后再回到用户空间。


有一个常见的机制使所有的系统调用转换到内核，这是由 **libc** 库处理的。 用户空间代码设置一些寄存器，包括其想要的系统调用的 ID 以及需要传递给系统调用的所有参数。它触发一个 “陷阱” 将控制转换到内核。


这就是用户空间代码如何向内核请求的，而 Linux 也有一个伪文件系统，它允许内核将信息传递给用户空间，其内容看起来像普通的目录和文件。


`/proc` 目录是一个很好的例子。看看里面，你会发现有关机器上运行的进程的各种有趣的信息。在某些情况，像 **cgroups**（控制组）那样，用户空间可以通过写入这些伪文件系统下的文件来配置参数。


当你在使用容器时，特别有趣的是，主机的 `/proc` 包含了所有有关容器化的进程的信息。这包括环境变量，它们也保存在 `/proc` 伪文件系统中，这意味着你的主机可以访问所有正在运行的容器的环境。如果你通过环境变量将诸如凭证或数据库密码这类秘密传递到容器中，则可能会产生安全性后果。


许多编写常规程序的程序员可能不觉得他们经常使用系统调用。但实际上他们会经常调用，因为每天的活动比如制作文件或者更改目录都涉及 Linux 的系统调用。


你不必是一位系统程序员才能享受系统调用的乐趣！


*如果你想要了解更多*，Liz 会在 Austin，Texas 举办的 OSCON 2017 上演讲 [*Linux 系统调用的初学者指南*](https://conferences.oreilly.com/oscon/oscon-tx/public/schedule/detail/56840)。


（题图： opensource.com）




---


作者简介：


Liz Rice - Liz Rice 是一位技术传播者，也是 Aqua Security 的容器安全专家。此前，她共同创立了 Microscaling Systems，并开发了其实时伸缩引擎，以及流行的图像元数据网站 MicroBadger.com。她拥有丰富的从网络协议和分布式系统，以及数字技术领域，如 VOD，音乐和 VoIP 软件的开发、团队和产品管理经验。




---


via: <https://opensource.com/article/17/5/beginners-guide-syscalls>


作者：[Liz Rice](https://opensource.com/users/lizrice) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
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](https://twitter.com/doctor_julz) 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](https://golang.org/pkg/syscall/). 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](http://man7.org/linux/man-pages/man2/syscalls.2.html) 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](http://www.oreilly.com/pub/cpc/44407?sc_cid=701600000012BzSAAU%20target=%22_blank%22)*:* **PCOS***.*

## Comments are closed.