LWN: 利用address space隔离来改善container方案安全性

Containers and address space separation

By Jake Edge， May 1, 2019，LSFMM

在2019 Linux Storage, Filesystem, and Memory-Management Summit (LSFMM)上，James Bottomley开始演讲之前，先说明了一下，Peter Zijlstra和Ingo Molnar都对Bottomley的同事Mike Rapoport提出的方案有一些反对意见。他们三个人碰巧都没有来参会。他们争论的核心观点，是关于是否用address space来减少对virtual machines (VMs) 和containers（容器）的攻击面。

Bottomley跟Rapoport一直在改善container的使用场景，而听说Google和Oracle也在VMs上试图解决类似问题。Address space （地址空间）方案是一个经久不衰的最安全的机制，能够把多个用户（多个VM或者多个container）给独立开，避免它们互相影响。例如在多用户系统上，多个进程之间就会用不同的地址空间，这已经大概沿用了50年了。这也证明address space是个古老但非常安全的方案，因此现在VMs和containers也应该可以利用这个功能。

在KVM系统里，guest OS的安全很依赖与调用host kernel的的hypercall要尽量少。在Spectre和Meltdown攻击之前，只要限制好这些hypercall的list就够了。不过自从有了Meltdown等大杀器之后就不一样了，每个program可以看到并行在运行的其他program的信息。KVM开发者就在找一些方法能确保guest OS无法访问到host kernel的其他任何地址（哪怕利用speculatively方法也不行），这样就需要unmap host kernel相关的代码，禁止访问host的address space的data。

关于container，所面临的一个主要安全问题是它所用到的kernel服务。在最简单的场景下，container可以访问所有system-call interface，也就是拥有全部功能。VM爱好者就经常抨击container如果能访问所有360左右个syscall，那当然要比VM的安全性差太多了。不过，经过检查那些container真正用到了哪些syscall，就会知道那不是事实。如果用所调用到的kernel代码的数量来衡量的话，container大概比hypervisors方式多访问2~5倍的kernel代码，也就是说可以简单的认为是面临2~5倍的安全风险。并不是VM拥护者所吹嘘的几百倍那么多。

其实，guest VM 有能力 调用到的syscall，和它们 真正调用 过的，是两个不同概念。VMs的安全很大程度上来自于它的syscall都会经过hypercall调用到host kernel去，这个过程很难被攻击。也就是说guest OS这边有安全风险的代码可能很多，但是host OS这边不太会被攻击波及到，因为hypervisor interface限制了guest对host的影响。Container开发者就也想能够得到类似的改进，能让container只调用到kernel的少部分API。

gVisor和Nabla Containers这两个项目做了沙盒来在user space处理一些kernel工作。例如gVisor会用 Go 语言来实现了一些kernel系统调用，而Nabla Containers就是采取了限制container只能够调用少数kernel system call，其他的system call就在user space模拟实现出来。

这些方案提供了更高的security级别，但是会引入不少memory management问题。他认为，理想方案应该是用独立的address spaces（地址空间）来运行各个container或者VM。如果每个kernel name space都能拥有一些私有的object，那么长远来说就容易解决这个安全性问题了。而且这个功能主要用于那些多系统的环境（例如container, VMs），不需要在所有平台上都打开。

Trond Myklebust问道，这个方案跟microkernel架构有什么区别呢？Bottomley回答：在microkernel（微内核）系统力，文件系统和块设备驱动程序都会运行在它们各自独立的address space，所以container之间公用文件系统就很难实现，因为两个container实际上是在访问“同一个”文件系统地址空间。他期望看到的方案是能够让两个vm（或者container）拥有完全独立的地址空间，而不能让他们共用同一个空间的file system子系统。

另一位听众也讲了一下microkernel的问题，如果文件系统驱动程序出现了一个fault，那么就只有文件系统子模块受到影响，系统的其他模块不会受损。可是这个架构里面，一个公共的文件系统和它的各个数据结构很难分离开。所以要用这种方案的话，一定要想清楚你想保护的是什么资源。

Bottomley认为两个不相干的container共用同一个filesystem是一个挺有意思的技术点。不过大多数人在构建cloud服务的时候不会这么做，所以哪怕我们的方案对这种场景有损害，大家估计也还能接受。在microkernel里面，发生fault的时候，kernel只是简单重启那个出错的driver。而VM或者container应用场景里面，是应该把出错的VM or container给杀掉。我们应该惩罚这个导致问题的VM or container，而不是某个kernel driver。microkernel里面每个子系统提供一个address space，而他想要实现的是每个VM or container拥有一个address space。两个应用场景里面设计目标和相应的安全防护点都很不一样。

有人问performance如何，用address space隔离的话肯定会损失一些性能，有什么办法弥补吗？Bottomley认为这是硬件设计问题了。virtualization起初发展很慢，所以硬件厂商就站出来想了各种新的硬件设计架构来让virtualization变快。那我们现在面临的性能损失，今后也应该会有相应的硬件架构来搞定这个问题。此外，他半开玩笑的说：这个功能毕竟是为了更好的安全性，为了安全，什么损失都是可以接受的！

Matthew Wilcox提到他不太接受“guest只访问host的少数API就能更安全”的说法。早先，他做 Java 开发的时候，有个同事写的Java程序居然就能把BIOS给搞坏了。Bottomley认为，有两条路可以改善container的安全性，要么加固那些系统调用，要么在user space模拟system call。

Ted Ts'o 提起了刚才提到的shared-filesystem的问题。在RHEL等系统上，container的base  image通常就是公用的，如何用不同的address space来保护？Bottomley说，这些image可以都配置成read-only，就能解决这个问题了。在Page cache里面，Read-only pages可以是shared，而在cloud-container应用里，read-write page通常都不会是shared。