acm-header
登录

ACM通信

研究突出了

为操作系统的心脏设置配置:论操作系统内核脱壳的实用性


卷尺、剪刀和计算机代码

信贷:盖蒂,Kindpng

本文研究了操作系统内核去核化的可行性,即减少目标应用程序不需要的内核代码。尽管它们在安全性(减少攻击面)和性能(快速引导时间和减少内存占用)方面有显著的好处,但最先进的OS内核脱壳技术在实践中并没有被广泛采用,特别是在生产环境中。我们发现了现有内核去泡技术的局限性,这些局限性阻碍了它们的实际应用,例如偶然的和必要的。为了理解这些限制,我们构建了一个名为Cozart的高级降级框架,它使我们能够在不同类型的操作系统内核(如Linux和L4微内核)上与各种各样的应用程序(如HTTPD、Memcached、MySQL、NGINX、PHP和Redis)上进行大量的实验。我们的实验结果揭示了实现操作系统内核去核化的挑战和机遇。我们分享这些见解和我们的经验,以阐明在未来的研究和开发工作中解决内核去泡技术的局限性。

回到顶部

1.简介

商用操作系统(os),如Linux和FreeBSD,多年来在复杂性和规模上都有所增长。然而,应用程序通常只需要操作系统特性的一小部分22凸显了存在于OS内核中的臃肿。操作系统内核中的这种膨胀会导致攻击面增加、引导时间延长和内存使用量增加。面向应用程序的操作系统内核剥离——减少目标应用程序不需要的内核代码——据报道可以有效地缓解上述问题。例如,以前的工作报告称,通过为服务器软件拆除Linux内核,可以减少50%-85%的攻击面16通过只包含目标应用程序所需的内核模块,可以在Linux内核中消除34%-74%的已知安全漏洞。4

功能即服务(function as a service)和微服务(许多内核经常打包并运行在虚拟机(vm)中)的最新趋势进一步加强了内核降级的重要性。在这些场景中,vm运行小型应用程序,每个应用程序往往是“微型”的,内核占用空间很小。3.11一些最近的虚拟化技术(例如LightVM18)要求使用者提供简约用于目标应用程序的Linux内核。

由于现成商品(COTS)操作系统的复杂性,通过手工挑选内核特性来分解操作系统内核是不切实际的。92324例如,Linux有超过14000个配置选项(从v4.14开始),每年还会引入数百个新选项。内核配置器(例如KConfig)不能帮助释放内核,而只能提供一个用户界面来选择配置选项。考虑到糟糕的可用性和不完整的文档,9用户很难选择最小的内核配置。

最近,几个自动化内核去泡技术和工具已经被提出和构建。12151617182125尽管现有的内核去内核技术各不相同,但它们具有相同的工作原理,即以下三个步骤:(1)运行目标应用程序工作负载并跟踪在应用程序运行期间执行的内核代码;(2)分析跟踪并确定目标应用程序所需的内核代码,以及(3)组装只包含应用程序所需代码的降级内核。

配置驱动(也称为特性驱动)的内核降级实际上是OS内核降级的一种方法。6131617182125大多数现有的工具都使用配置驱动的卸载技术,因为它们是少数能够产生稳定内核的技术之一。配置驱动的内核降级减少了内核代码基于特性:一个内核配置选项对应一个内核特性。debloated内核只有包括支持目标应用程序工作负载的特性。

然而,尽管在安全性和性能方面具有诱人的好处,但在实践中,特别是在生产用例中,并没有广泛采用自动化内核剥离技术。这并不是因为缺乏需求——我们观察到许多云供应商(例如Amazon AWS、Microsoft Azure和谷歌cloud)手工编写Linux内核代码以减少代码,这不如自动内核降级技术(第2.4节)有效。我们的目标是了解内核去内核方法的限制,这些限制阻碍了它们的实际采用,并分享我们的经验,以阐明解决这些限制的方法。

*1.1.偶然的和本质的限制

根据我们自己使用现有工具的经验以及我们与从业者的交互,我们确定了现有内核去核化技术的五个主要限制。

  • 在引导阶段没有可见性。现有的技术只能在内核引导之后启动,因此无法观察在引导阶段加载了什么内核代码(主要是由于它们依赖于ftrace).因此,被现有技术削弱的内核常常无法引导6因为衰竭的内核中可能缺少关键模块。我们的实验表明,多达79%的内核特征只能通过观察引导阶段来捕获。此外,现有的技术可能会错过重要的性能和安全特性,同样,这些特性只在启动时加载(例如,CONFIG_SCHED_MC对于多核支持和CONFIG_SECURITY_NETWORK),导致性能和安全性降低。
  • 缺乏对快速应用程序部署的支持。使用现有的工具,在废弃的内核上部署新应用程序需要完成跟踪、分析和组装这三个步骤。这个过程很耗时(可能需要数小时甚至数天),因此阻碍了敏捷应用程序的部署,因为启动一个新的应用程序需要等到内核生成完成。
  • 粗粒度。现有技术使用ftrace的内核代码函数的水平。函数级跟踪粒度太粗,无法跟踪影响函数内代码的配置选项。
  • 内核占用的不完全覆盖。因为内核降级使用动态跟踪,它需要应用程序工作负载(编码为基准测试)来驱动内核代码执行,以最大化覆盖范围。然而,要让基准测试覆盖目标应用程序的完整内核占用是很有挑战性的,并且被分解的内核可能会在运行时崩溃,特别是当应用程序到达在跟踪过程中没有观察到的内核代码时。
  • 不区分执行的内容和需要的内容。现有的技术包括在应用程序工作负载期间达到的内核特性,即使执行的代码可能实际上并不需要,例如,可能初始化了第二个文件系统,但从来不需要。

为了分析上述限制,我们将其分为精华(内核虚化的本质和假设所固有的局限性)和事故(存在于当前内核脱空技术中,但不是进程固有的)。我们认为,前三个限制是偶然的,可以通过改进去泡工具的设计和实现来解决,而后两个是必要的,需要在特定的去泡技术本身之外的努力。

*1.2.结果和发现

我们关注部署在云环境中的操作系统内核,这些内核通常用作客户操作系统,以运行具有高性能需求的不可信应用程序。

我们在QEMU的基础上开发了COZART,一种新的操作系统内核开发框架。COZART使用来自QEMU的指令级跟踪来实现对引导阶段的可见性。COZART跟踪内核代码并将其映射到内核配置选项。COZART将内核跟踪移出关键路径—使用我们的框架,可以生成configlet(一组配置选项)离线特定于应用程序或部署环境。我们称前者为applet,后者为BASELETS。给定一组目标应用程序,COZART可以通过以下方式直接生成一个降级内核作曲applet和BASELET离线生成为完整的内核配置。这种可组合性使COZART能够增量通过重用configlet(节省重复的跟踪工作)和以前构建的文件(例如,目标文件和lkm)来构建新的内核。

我们使用COZART作为载体,对不同类型的操作系统内核(如Linux, L4微内核)进行了大量的实验研究1,以及Amazon爆竹内核2)和各种各样的应用程序(如HTTPD, Memcached, MySQL, NGINX, PHP和Redis)。我们的研究得出以下结果和发现:

  • 现有技术初始化内核跟踪的时间过晚,无法观察引导阶段,而引导阶段对于生成可引导的内核至关重要。COZART使用管理程序提供的跟踪特性来获得端到端可观察性和产生稳定的内核。COZART分解的内核没有性能下降,同时,它实现了引导时间减少了13%以上,并为系统节省了超过4MB的内存。
  • 如果知道目标应用程序的配置,可以在几十秒内完成内核卸载。COZART的可组合性允许applet离线准备。要将新应用程序部署到已降级内核上,COZART可以将目标应用程序的applet与当前内核的configlet组合在一起,以生成新的已降级内核。
  • 使用指令级跟踪(而不是ftrace)可以处理控制内部功能特性的内核配置选项。指令级跟踪的开销对于运行测试套件和性能基准测试来说是可以接受的。
  • 使用基于动态跟踪的技术的一个基本限制是测试套件和基准的不完善。具体来说,许多开源应用程序的官方测试套件都有代码覆盖率低。结合不同的工作负载(例如,同时使用测试套件和性能基准)来驱动应用程序可以在一定程度上减轻这种限制。
  • 通过删除在基线内核中执行但在实际部署过程中不需要的内核模块,可以使用特定于领域的信息进一步释放内核。以Xen和KVM为例。我们可以使用COZART来进一步减少内核大小(减少40+%和39+%)xenconfig而且kvmconfig分别配置模板。
  • 面向应用程序的内核降级可以进一步减少微内核(如L4)的内核代码,甚至是广泛定制的内核(如爆竹内核)。《L4》减少了47.0%,《爆竹》减少了19.76%。

回到顶部

2.内核配置

我们首先以Linux为例概述内核配置生态系统。

*2.1.配置选项

内核配置由一组配置组成选项。一个内核模块可以有多个选项,每个选项都控制将在最终的内核二进制文件中包含哪些代码。配置选项控制内核代码的不同粒度,比如由C预处理器实现的语句和函数,以及基于Makefiles条目实现的目标文件。

C预处理器选择代码块# ifdef / #如果未定义指令配置选项被用作宏来确定是否在编译的内核中包含这样的条件组。图1一个而且b展示了两种配置选项的C预处理器示例,分别具有语句粒度和函数粒度。

f1.jpg
图1。控制Linux内核中内核代码不同粒度的内核配置。这些模式在其他内核中也很常见,比如FreeBSD、L4和eco。

Makefiles用于确定是否在编译的内核中包含某些目标文件。例如,在图1 cCONFIG_CACHEFILES_HISTOGRAM而且CONFIG_CACHEFILES都是Makefile中的配置选项。以前已经研究过内核配置模式的详细特征。719

语句级配置选项(例如图1一个)不能被现有内核去泡工具使用的函数级跟踪识别。121316事实上,我们发现Linux 4.18中31%的C预处理器是语句级选项。

随着内核代码和特性的快速增长,现代单片操作系统内核中配置选项的数量正在迅速增加。以Linux为例,内核版本5.0、4.0和3.0分别有16,527、14,406和11,328个配置选项。

*2.2.配置语言

不同的操作系统内核使用不同的配置语言来指示编译器在编译的内核中包含哪些代码。例如,Linux和L4/Fiasco使用KConfig, eCos使用CDL, FreeBSD使用键-值格式。这些语言允许定义配置选项和它们之间的依赖关系。在本文的其余部分中,我们使用KConfig作为内核配置语义的示例,但不会失去通用性。

配置选项类型。KConfig中的一个选项是bool,三态,或常数。一个保龄球选项意味着代码将是静态编译为内核二进制或排除,而三态允许将代码编译为可加载内核模块(LKM)——一个可以在运行时加载的独立对象。一个常数选项可以具有作为内核代码变量提供的字符串或数值。一个选项可能依赖于另一个选项。KConfig使用递归过程来加强配置依赖性14通过递归地选择依赖选项和取消选择不满足依赖关系的选项。最终的内核配置具有有效的依赖关系,但可能与用户输入不同(例如,如果输入配置违反了依赖关系需求)。

*2.3.配置模板

Linux内核附带了许多手工制作的配置模板。但是,由于配置模板的硬编码性质和需要人工干预,因此它并不是解决内核去层挑战的解决方案——它们不能适应不同的硬件平台,而且不了解应用程序需求。例如,一个内核从tinyconfig无法在标准硬件上启动,20.更不用说支持其他应用程序了。一些工具1213治疗localmodconfig作为一个最小化的构型。但是,localmodconfig它有静态配置模板相同的一组限制:它不释放控制语句或函数级C预处理器的配置选项,也不处理可加载的内核模块。

的模板kvmconfig而且xenconfig是为在KVM和Xen设置上运行的内核定制的。它们提供底层虚拟化和硬件环境的领域知识。在第6.5节中,我们将使用这些模板中编码的信息来研究特定于领域的降级。

*2.4.云中的Linux内核

Linux仍然是云服务提供的虚拟机的主要操作系统内核。我们关注Ubuntu和Amazon Linux 2作为云计算中的代表性内核。我们分析了由厂商VM映像提供的Linux内核。我们发现云供应商都在某种程度上抛弃了普通的Linux内核。然而,去泡工作是手工的,有时是临时的。所示表1,云供应商的定制通常是通过直接删除可加载内核模块(lkm)来完成的。表1显示了内核构建期间LKM文件的实际数量与编译时记录的LKM数量之间的不一致。它表明内核最初是用更多的lkm构建的,这些lkm稍后会被删除。手工裁剪LKM二进制文件的一个缺点是可能违反依赖性(一个LKM可能依赖于多个可能已经手工裁剪过的其他LKM)。

t1.jpg
表1。Ubuntu、谷歌、AWS和Azure提供的Linux内核的配置选项和大小。

重要的是,有很大的改进潜力,即根据应用程序需求进一步分解内核。下半部分表1将云供应商提供的内核与COZART为官方的Ubuntu和Amazon Linux 2(基线)生产的内核进行比较。我们使用Apache Web Server (HTTPD)作为目标应用程序。总的来说,COZART可以使Ubuntu的内核代码减少34.91%,亚马逊Linux 2的内核代码减少40.72%。

我们还研究了Amazon鞭炮使用的最小化内核,这是一个专门用于函数即服务(AWS Lambda)的微型虚拟机。炮竹的内核是基于Linux的手工内核配置(910配置选项)。表1表明,使用HTTPD作为目标应用程序时,内核下垂可以进一步减少这样一个最小化的内核17.69%。

回到顶部

3.Cozart

COZART是一个新的操作系统内核开发框架。它集成了我们的解决方案来处理设计中的意外限制,并支持分析本质限制。COZART与最先进的内核脱空技术共享高级原理——跟踪(目标)应用程序工作负载的内核占用空间,以确定所需的内核。降级的内核将只包含这些内核特性,而不是所有可用的内核特性或默认配置中启用的内核特性。COZART区别于其他最先进的内核脱除技术61617182125在以下几个方面:

  • 端到端可见性。COZART利用管理程序的可见性来实现端到端观察,可以跟踪内核引导阶段和应用程序工作负载。我们在QEMU的基础上构建COZART。COZART针对云虚拟机的操作系统内核。
  • 可组合性。COZART的一个关键原则是进行内核配置可组合的,将它们划分为一组configlet。CONFIGLET是一组配置选项,用于(A)在给定的部署环境(如VM)上引导内核,或(b)目标应用程序(如HTTPD)所需的选项。前者被命名为BASELETS,后者被命名为applet。BASELET不一定是在特定硬件上引导所需的最小配置集,而是COZART在引导阶段跟踪的一组配置选项。BASELET可以与一个或多个applet组合在一起,以生成最终的内核配置。
  • 可重用性。只要部署环境和应用程序二进制文件不变,configlet就可以存储在数据库中并被重用。COZART将内核跟踪和应用程序工作负载移出内核衰减的关键路径。这种可重用特性避免了重复跟踪和工作负载运行,使CONFIGLET生成成为一次性工作。
  • 支持快速应用程序部署。可重用性和可组合性支持快速部署。给定一个部署环境和目标应用程序,COZART可以有效地检索BASELET和APPLETS,并将它们组合到所需的内核配置中,然后使用生成的配置构建分离的内核。
  • 细粒度的跟踪配置。COZART使用QEMU提供的基于程序计数器的跟踪来识别基于底层代码模式的配置选项图1

图2介绍了COZART的架构。它需要三种类型的输入:(1)内核源代码,(2)基线配置,以及(3)驱动内核执行的应用程序工作负载。

f2.jpg
图2。COZART概述:配置跟踪器记录目标应用程序使用的配置选项。Configlet生成器将这些选项处理成Configlet并将它们存储在Configlet DB中。内核编写器生成最终的配置。内核构建器构建已降级的内核。

COZART分为以下两个阶段(见图2):

  • 离线阶段。Config Tracker用于跟踪部署环境和目标应用程序所需的配置选项cacm6505_f.gif;CONFIGLET Generator生成CONFIGLET(比如BASELETS和applet),并将它们存储在CONFIGLET DB中cacm6505_g.gif
  • 在线阶段。给定目标部署环境和应用程序,COZART使用Kernel Composer通过组合相应的BASELET和applet来生成配置cacm6505_h.gif然后使用Kernel Builder构建内核cacm6505_i.gif

*3.1.跟踪配置选项

COZART跟踪由目标应用程序驱动的内核执行期间的配置选项。COZART将单独跟踪应用程序以生成applet。它以后可以在线组合多个applet。配置跟踪通过以下三个步骤完成。

跟踪程序计数器。COZART使用PC寄存器捕获正在执行的指令的地址。我们的实现使用exec_tb_blockQEMU提供的。为了确保跟踪的pc属于目标应用程序,而不是其他进程(例如,后台服务),COZART使用定制的初始化不启动任何其他应用程序的脚本。这个脚本挂载文件系统(/ tmp / proc,/ sys),启用网络接口(而且eth0),最后,在内核引导后直接启动应用程序。

我们禁用内核地址空间布局随机化(KASLR),以便能够正确地将地址映射到源代码。注意,这只在跟踪阶段执行-衰竭的内核仍然可以使用KASLR。

将pc映射到源代码语句。COZART使用addr2line将PC映射到源代码中的相应语句,以识别运行时使用的内核模块。addr2line使用内核二进制文件中的调试信息。

可加载内核模块(lkm)需要额外的处理。LKM是一个独立的二进制文件,可以在运行时加载到内核中。因为lkm没有加载到固定地址的内存中,addr2line不能直接应用。在COZART中,我们使用/proc/modules获取每个加载LKM的起始地址,然后将pc映射到LKM二进制中的语句。另一种选择是利用杠杆localmodconfig,这是一个输出当前加载的lkm的内核实用程序。然而,localmodconfig只提供模块粒度的信息,不能帮助释放细粒度的lkm内部配置选项。

将语句归为配置。中给出的三种模式,COZART将源代码语句属性为配置选项图1.关于基于C预处理器的模式(参见图1一个而且b), COZART分析C源文件来提取预处理器指令(例如,# ifdef),然后检查这些指令中的语句是否被执行。关于基于makefile的模式(参见图1 c), COZART确定是否应该在目标文件的粒度上选择一个配置选项。例如,在图1 cCONFIG_CACHEFILES如果任何对应的文件(bind.ocachefiles.o,或daemon.o使用)。

*3.2.生成CONFIGLETS

BASELETS和applet是在跟踪配置选项的(脱机)阶段生成的。COZART标志引导阶段的结束具有里程碑意义的项目-a我们创建的C语言程序mmap将一个空存根函数映射到一个预定义的“魔法地址”(我们分别使用0x333333333000和0x222222222000作为起始地址和结束地址)并调用存根函数。的初始化分段描述的脚本跟踪程序计数器在运行目标应用程序之前调用地标。因此,COZART可以根据PC跟踪中的魔法地址识别引导阶段(结束)。

COZART从应用程序中获取配置选项,并过滤掉在引导阶段观察到的与硬件相关的选项。这些硬件特性是根据它们在内核源代码中的位置来定义的(例如,位于/拱门,/驱动程序,/声音).我们不排除只有在应用程序执行期间才能观察到与硬件相关的选项的可能性,例如,它按需加载一个新的设备驱动程序(在这种情况下,应用程序是特定于硬件的)。

*3.3.作曲CONFIGLETS

COZART将BASELET与一个或多个applet组合在一起,以生成用于构建内核的最终配置。COZART首先将所有configlet中的选项联合创建到初始配置中,然后使用SAT求解器解析它们之间的依赖关系。它将配置依赖关系建模为一个布尔可满足性问题,并使用SAT求解器生成最终配置—有效配置是满足配置选项之间所有指定依赖关系的配置。这是必需的,因为KConfig并不确保包含所有选中的选项,而是取消选择不满意的依赖项。我们遵循文献中描述的基于sat的内核配置建模7在科扎特使用PicoSAT。5SAT求解器有可能返回多个有效解。在本例中,我们的实现使用从求解器返回的第一个解。

*3.4.内核构建器

COZART使用标准内核构建系统(用于Linux的KBuild)基于使用configlet组成的配置来构建分解的内核。由于构建处于内核卸载的关键路径上,COZART通过利用现代工具(例如make)的增量构建支持来优化构建时间。COZART缓存以前的构建结果(例如,目标文件和lkm),以避免冗余编译和链接。当配置发生更改时,只需要重新构建具有内部配置选项更改的模块,而其他文件可以重用。当一个废弃的内核需要支持一个新的应用程序时,我们发现这个特性特别有用,因为大多数应用程序共享许多模块,但只在少数模块上有所不同。

回到顶部

4.研究方法

我们使用了六个流行的开源服务器应用程序,它们通常部署在云环境中,即HTTPD (v2.4)、NGINX (v1.15)、Memcached (v1.5)、MySQL (v5.7)、PHP (v7.2)和Redis (v4.0)。对于每个应用程序,我们都使用它的官方测试套件和性能基准来驱动内核,并在此基础上使用COZART生成configlet。

我们使用官方基准测试来度量在降级内核上运行的应用程序性能,并验证降级没有引入任何回归。所有性能实验都是在一个基于kvm的虚拟机上进行的,该虚拟机上有4个vcpu和8GB RAM,运行在运行于2.10 GHz的Intel Xeon Silver 4110 CPU上。我们将基准测试结果报告为20次运行的平均值。

我们的基准内核是来自最新版Ubuntu 18.10 Cloud Image的Linux内核v4.18.0。我们还在Fedora 30的Linux内核v5.1.9上重复了所有的实验,并观察到类似的结果。因此,我们只将Ubuntu 18.10 Cloud Image的结果作为基线。

回到顶部

5.Debloating有效性

我们使用COZART来释放目标应用程序的基线内核。COZART实现了80%以上的核还原(参见表3).我们验证了所有分离的内核不仅可以引导,而且可以成功地运行应用程序工作负载,比如性能基准测试和测试套件。

t3.jpg
表3。基于CONFIGLET组合的COZART生成的虚化核的特征。

减少启动时间。第二列表2显示每个应用程序的废弃内核的引导时间(以及相对于基线内核的减少量)。我们通过读取来测量启动时间/proc/uptime它记录了系统自上一次重新启动以来处于打开状态的持续时间。COZART脱除的籽粒时间缩短接近14%。减少的原因是加载更小的内核映像节省了时间,并且跳过了被删除模块的初始化和设备注册(例如,Fuse文件系统和Hot Plug PCI控制器)。

t2.jpg
表2。内核的引导时间、应用程序性能和内存减少。

应用程序的性能。我们对运行在COZART生成的分解内核上的应用程序的性能进行基准测试,并将结果与基线进行比较。我们不期望有任何性能改进。我们也不期望性能回归,因为COZART没有删除性能优化代码。

表2(第三列)显示了在去层内核上运行的应用程序性能相对于基线的改进。没有性能回归;相反,分离的内核显示出少量的性能改进(对于所有应用程序),主要是因为应用程序加载更快,内存开销更小。

记忆的储蓄。我们将内存节省定义为托管加载的内核二进制文件所需的内存区域的减少,用MemTotal为已读的/proc/meminfo.的数字表2与页面大小对齐。我们观察到,对于单个应用程序,在拆分内核之间节省了大约4MB的内存。应用程序也有类似的简化结果(在第6.1节中讨论)。

摘要:COZART生成的分离内核都是稳定的——它们可以直接引导并支持预期的应用程序工作负载。它们的启动速度比基线内核快13+%,并在运行时节省超过4MB的内存。

回到顶部

6.结果和影响

本节有选择地介绍我们的发现。完整的讨论请参考原文。

*6.1.启动阶段的可见性

使用最先进的工具。现有的工具没有解决启动阶段的自动解决方案,因为它们使用ftrace对于内核跟踪,它只能在引导过程完成后启动。

为了克服这个限制,承办人16打开ftrace尽早,即在内存盘初始化时(initrd).然而,我们发现它仍然不够早,因为硬件检测发生在挂载RAM磁盘之前。因此,一些磁盘驱动程序(例如SCSI磁盘支持)不会被Undertaker捕获,甚至磁盘支持本身也必须被列入白名单。为了使分解的内核可引导,Undertaker最终要求用户设置一个小的白名单,以确保包含某些配置选项。然而,正如最近的文献所述,6“这会让用户回到最初的配置问题上。”

LKTF13尝试使用基于搜索的方法解决引导阶段的不可见性问题。它将配置选项填充到Undertaker生成的不可引导内核中,直到内核最终引导。LKTF大约需要5个小时才能生成一个可引导的内核。6我们无法运行LKTF,因为它的实现是硬编码到一些旧内核版本的。另外,LKTF生成的降级内核并不保证包含所有原始的安全和性能配置。

使用COZART启动阶段可见性。COZART使用较低级别的跟踪(在管理程序级别)解决了可见性限制。这带来了COZART的一个关键优势:每个衰弱的内核COZART能启动,运行稳定。

COZART为Ubuntu 18.10生成BASELET,它包含1212个(2443个)静态链接模块和7个(5001个)lkm。与基线内核(Ubuntu 18.10)相比,我们减少了1231个静态链接模块和4994 lkm。以司机为例。普通内核旨在支持各种硬件,因此包含针对不同设备的驱动程序。COZART只包括在跟踪中观察到的一个(即应用程序使用的那些),例如Acpi, scsi, cpufreq, tty, char而且直接存储器存取驱动程序。

摘要:引导阶段的可见性对于生成可引导的内核至关重要。COZART利用管理程序提供的跟踪特性来支持端到端可观察性(例如完整的引导阶段和应用程序工作负载),并生成能够始终稳定地引导和运行应用程序的稳定内核。

*6.2.可组合性

我们用以下三种情况评估COZART的可组合性:(1)个人申请:对于每个应用程序,我们使用COZART来组成一个APPLET和BASELET来生成一个定制的去内核;(2)容器中的单个应用程序:对于每个应用程序,我们使用COZART与Docker运行时的CONFIGLET一起组成APPLET(dockerd)结合BASELET;(3)多个应用程序:我们使用COZART来组成一个内核来支持LAMP堆栈。我们使用一个单独的应用程序,phpMyAdmin(一个带有PHP接口的MySQL管理工具),以验证LAMP堆栈以及单个应用程序的工作。

表3显示前两种类型的组合的消泡结果,并与基线内核进行比较。所有缩减数看起来相似的原因是96%-99%的配置选项是从同一个VM生成的BASELET中提取的。COZART将BASELET与目标APPLET组合在一起,分别为静态链接的内核二进制文件和lkm减小了17+%和86+%的大小。

接下来我们使用COZART来生成CONFIGLET码头工人运行时(dockerd)使用标准的hello world开始的例子dockerd,把hello world映像,并启动一个容器。我们通过组合多个applet(例如目标应用程序和dockerd)和BASELETS。的下半部分表3显示了通过在Docker容器中运行应用程序的Linux内核所实现的减少。我们发现dockerdCONFIGLET已经包含了大部分的applet。脱去的核具有相似的还原率。

对于LAMP堆栈,我们使用COZART来组成每个应用程序(HTTPD、MySQL和PHP)的configlet,并使用BASELET为整个堆栈生成一个分解的内核。我们部署phpMyAdmin并确保所有组件的功能都能正常工作。对于静态链接的内核二进制文件,去掉内核的大小减小了17.13%,对于lkm则减小了86.80%。

摘要:COZART的可组合性使用户能够在applet中维护特定于应用程序的内核配置,在BASELETS中维护特定于部署的内核配置。通过组合applet和BASELET可以生成完整的内核配置。

*6.3.快速应用程序部署

当一个人想要将一个新的应用程序部署到一个废弃的内核(例如,为不同的应用程序定制)上时,现有技术的一个限制是必须重复从跟踪到重新编译的整个过程。因此,不支持快速应用程序部署。

我们认为,前面提到的限制是由现有技术的设计造成的,这些技术使跟踪成为卸载过程的一个组成部分,也就是说,工具必须首先通过运行应用程序工作负载跟踪内核,然后根据结果编译内核。我们的工作表明,跟踪需要比编译多得多的时间。具体来说,跟踪时间取决于应用程序工作负载(测试套件或基准测试)—更完整的工作负载将导致更高的跟踪开销。使用COZART,跟踪可以与编译解耦,因此,只要保留生成的configlet,就可以脱机完成。如果我们有CONFIGLETS对于目标应用程序,在从头编译时,释放内核所需时间少于2分钟。

我们也探讨从以前分解的内核进行增量构建,这里我们加上a在现有内核上的应用程序。这种增量构建是有效的,因为许多应用程序共享公共配置选项,只有轻微的不同。因此,COZART只需要(重新)编译这些少量的额外模块。它重用了以前构建的大部分二进制文件。重构内核以支持新应用程序只需要几十秒(在存在冷缓存的情况下),如果缓存是热的(通常在使用专用构建服务器时)则只需要几秒。

摘要:如果知道目标应用程序的配置选项,那么可以在几十秒内完成内核卸载。COZART的可组合性允许applet离线准备。事实上,部署一个新的应用程序也可以在几十秒内就在一个废弃的内核上完成。

*6.4.报道

应用现有技术的一个基本问题是完整性衰弱的内核。如果目标应用程序到达了未包含在降级版本中的代码,内核可能会崩溃或导致错误。

以前关于去泡技术的研究隐含地假设运行基准测试可以覆盖目标应用程序的内核占用空间。以Web服务器为例。先前的研究使用简单的基准测试来访问静态文档,以生成降级内核。16

表4显示在运行官方性能基准测试套件时每个目标应用程序的覆盖率(以语句的数量表示)gcov.官方基准达到的覆盖率很低,在6%到26%之间。通常,基准测试只执行目标应用程序的稳定状态,而忽略了应用程序的其他部分(例如,其他特性、错误处理和恢复过程)。

t4.jpg
表4。与官方测试套件相比,官方性能基准测试所达到的目标应用程序的语句覆盖率和配置选项的数量。

测试套件可以潜在地补充基准测试;它们被设计用于应用程序软件的不同部分。所示表4,与基准测试相比,测试套件提供了更高的代码覆盖率。然而,测试套件的代码覆盖率也不完美——覆盖率从29%到73%不等。一个我们得出的结论是,缺乏高覆盖率的测试是基于动态跟踪的脱泡技术的一个基本限制。自动化测试技术,如模糊测试和共colic测试,可以提高覆盖率,减轻限制。另一方面,它们不是银弹。注意,代码覆盖率不等于内核覆盖范围。具有100%覆盖率的测试套件可以覆盖应用程序调用的所有可能的系统调用,但不能覆盖所有可能的内核状态。

基准测试发现的配置选项并不总是包含在测试套件的APPLETS中。例如,在Memcached中,CONFIG_PROC_SYSCTL当Memcached读取最大数量的文件描述符来检查是否可以在过载的情况下分配更多的连接时,只存在于基准测试生成的applet中。

摘要:基于动态跟踪的去潜技术的一个基本限制是测试套件和基准的不完善。具体来说,许多开源应用程序的官方测试套件的代码覆盖率很低。

*6.5.使用特定于域的信息

现有内核降级技术的另一个基本限制是无法区分内核代码执行在跟踪和代码之间需要的。代码可能不需要,但恰好在执行路径上。例如,在虚拟机中,执行BIOS、热控和电源管理的内核代码,但不需要启动虚拟机。

我们还研究了基于领域知识进一步释放内核以删除代码的机会。我们同时研究了基于kvm的虚拟机和Xen虚拟机。我们利用配置模板,kvmconfig而且xenconfig,在Linux源代码树中作为特定于领域的信息。例如,kvmconfig使用virtio作为网络和块设备的I/O接口xenconfig使用Xen前端(Dom0))作为主I/O接口;原始的BASELET还使用了KVM或Xen虚拟机不需要的其他I/O接口(如SCSI磁盘驱动程序)。

我们使用这两个模板来替换原始的BASELETS,以进一步释放KVM和Xen已经释放的内核。我们观察到40+%,39 +%的内核大小,分别比原来的KVM和XenBASELET结果是40岁+%和41+分别减少KVM和Xen的配置选项的数量%。减少的原因是许多内核模块(例如,分区类型、处理器特性、BIOS、热控制、电源管理、ACPI和输入设备)在引导时由基线内核执行;但是,如果部署在KVM或Xen上,则不需要这些模块。

SUMMARY:特定于领域的信息可以用于有效地删除在基线内核中执行但在部署时不需要的内核代码。

回到顶部

7.普遍性

我们移植COZART来去除L4微核18以及AWS的爆竹内核。23.L4/Fiasco微内核也像Linux一样使用KConfig作为配置语言。对于爆竹,我们修改了从MMIO到PCI的内核总线,以启用QEMU跟踪,并在爆竹上启动前将总线更改回。

L4微核。对L4应用COZART的结果1令人惊讶的是,与默认的内核相比,去掉的内核变小了47%。显著减少的原因是默认的L4/Fiasco配置启用了一个沉重的内核调试器,CONFIG_JDB,这在很大程度上决定了最终内核的大小。已降级的内核不再包含此模块。尽管删除调试器会使内核变小听起来很简单,但是如果没有像COZART这样的自动工具,手动检查和选择每个配置选项是非常重要的。

爆竹。尽管仍然基于Linux,但Amazon爆竹内核是一个特例,因为内核被广泛最小化,以优化功能即服务的工作负载。我们使用目标应用程序(第4节)在爆竹内核上应用COZART,以了解特定于应用程序的内核去内核化的空间,特别是对于像爆竹这样经过广泛优化的内核。

总的来说,COZART将内核配置选项的数量从910减少到729(减少了20%),导致内核大小减小了19.76%,引导时间缩短了11%(从104秒减少到92.5秒)。

摘要:面向应用程序的内核降级可以用于进一步减少内核代码,甚至可以用于微内核和广泛定制的内核。

回到顶部

8.结论

由于去内核的不稳定性、速度不足、完整性问题以及需要人工干预,OS内核去内核技术还没有得到广泛采用。本文研究了这种脱空技术,目的是使它们在实际部署中具有实用性。我们发现现有技术的局限性阻碍了它们的实际应用。我们开发了COZART,这是一个自动内核卸载框架,它使我们能够在不同类型的操作系统和各种各样的应用程序上进行大量的实验。我们分享了解决操作系统内核去内核的意外限制的解决方案,也讨论了解决实际去内核技术的本质限制的挑战和机会。我们已经将COZART和实验数据公之于众:https://github.com/hckuo/Cozart

回到顶部

致谢

莫汉项目部分由海军研究办公室(ONR) N00014-17-S-B010拨款支持。徐的部分资助来自美国国家科学基金会CCF-1816615、CCF-2029049、CNF-1956007和Facebook分布式系统研究奖。

回到顶部

参考文献

1.FIASCO: L4Re微内核。http://os.inf.tu-dresden.de/fiasco.检索于2019年10月。

2.爆竹:用于无服务器计算的安全、快速的微型虚拟机。https://firecracker-microvm.github.io/.检索于2019年10月。

3.阿加切,布鲁克,M.,伊奥尔达切,A.,利果里,A.,诺格鲍尔,R.,皮旺卡,P.,波帕,d -M。用于无服务器应用程序的轻量级虚拟化。在第十七届会议的会议记录th网络系统设计与实现USENIX研讨会(NSDI’20)(加利福尼亚州圣克拉拉,2020年2月)。

4.Alharthi M., Hu H., Moon H., Kim T.基于编译时配置的内核去泡的有效性。在会议记录1软件去层和去层研讨会(2018年7月,荷兰阿姆斯特丹)。

5.Biere, A. Picosat精华。J.可满足性,布尔模型计算, 2-4(2008), 75-97。

6.一种不同的内核配置方法,2016。https://lwn.net/Articles/733405/

7.C. Dietrich, Tartler, R., Schröder-Preikschat, W., Lohmann, D.一种从linux构建系统中提取可变性的鲁棒方法。在16届会议记录th国际软件产品线会议(SPLC'12)(萨尔瓦多,巴西,2012年9月)。

8.从L3到seL4, L4微核20年来我们学到了什么?在二十四人会议记录th操作系统原理研讨会(SOSP'13)(法明顿,宾夕法尼亚州,2013年11月)。

9.Hubaux, Xiong, Y, Czarnecki, K. Linux和eCos中配置挑战的用户调查。在6学报》th软件密集型系统变异性建模国际研讨会(VaMoS'12)(2012年1月,德国莱比锡)。

10.伊凡科维奇,M,彼得罗维奇,G,贾斯特,R,弗雷泽,G,谷歌覆盖范围。在2019年会议记录12th软件工程基础联席会议(ESEC/FSE 2019)(爱沙尼亚塔林,2019)。

11.乔纳斯,E.,施莱尔-史密斯,J.,斯里坎蒂,V.,蔡,c . c。,Khandelwal, A., Pu, Q., Shankar, V., Menezes Carreira, J., Krauth, K., Yadwadkar, N., Gonzalez, J., Popa, R.A., Stoica, I., Patterson, D.A. Cloud programming simplified: A Berkeley view on serverless computing. Technical Report UCB/EECS-2019-3. EECS Department, University of California, Berkeley, 2019.

12.一种实用的Linux内核裁剪方法。在Linux基金会北美开源峰会(加州洛杉矶,2017年9月)。

13.一种先进内核裁剪框架的实证研究。在Linux基金会开源峰会(2018年8月,加拿大卑诗省温哥华)。

14.kernel.org。Kconfig, 2018年。https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt

15.Kuo, H., Gunasekaran, A., Jang, Y., Mohan, S., Bobba, r.b., Lie, D., Walker, J. MultiK:一个编排多个专门内核的框架。arXiv: 1903.06889(2019)。

16.库尔穆斯,塔尔特勒,多尔内努,D., Heinloth, B., Rothberg, V., Ruprecht, A., Schröder-Preikschat, W., Lohmann, D., Kapitza, R.攻击表面度量和自动编译时os内核裁剪。在20国会议记录th年度网络和分布式系统安全研讨会(NDSS'13)(2013年2月,美国加利福尼亚州圣地亚哥)。

17.李,C.-T。,Lin, J.-M., Hong, Z.-W., Lee, W.-T. An application-oriented Linux kernel customization for embedded systems.j . Inf。科学。Eng。20, 6(2004), 1093-1107。

18.Manco, F., Lupu, C., Schmidt, F., Mendes, J., Kuenzer, S., Sati, S., yasata, K., Raiciu, C., Huici, F.我的VM比你的容器更轻(也更安全)。在二十六届会议的议事录th操作系统原理研讨会(SOSP’17)(2017年10月,中国上海)。

19.L. Passos, Queiroz, R., Mukelabai, M., Berger, T., Apel, S., Czarnecki, K., Padilla, J. Linux内核中特征散射的研究。IEEE反式。软件中。(TSE) 47, 1(2021), 146-164。

20.用斧头缩小果仁,2018年。https://lwn.net/Articles/746780/

21.Stengel, K. Schmaus, F. Kapitza, R. EsseOS:基于haskell的云定制服务。在12人会议记录th自适应和反射中间件国际研讨会(ARM'13)(2013年12月,中国北京)。

22.蔡,c c。,Jain, B., Abdul, N.A., Porter, D.E. A study of modern Linux API usage and compatibility: What to support when you're supporting. In十一届会议记录th欧洲计算机系统会议(EuroSys'16)(2016年4月,英国伦敦)。

23.Xu, T, Jin, L, Fan, X, Zhou, Y., Pasupathy, S., Talwadker, R.嘿,你给我的球太多了!理解和处理系统软件中过度设计的配置。在十人会议记录th欧洲软件工程会议和ACM SIGSOFT软件工程基础研讨会联席会议(ESEC/FSE'15)(贝加莫,意大利,2015年8月)。

24.徐、涛、张、俊、黄、鹏、郑、俊、盛、泰、袁、德、周、宇、Pasupathy、S.不要因为配置错误而责怪用户。在二十四人会议记录th操作系统原理研讨会(SOSP'13)(法明顿,宾夕法尼亚州,2013年11月)。

25.Youseff, l.m., Wolski, R., Krintz, C.科学应用性能的Linux内核专业化。技术报告2005 - 29。加州大学圣巴巴拉分校,2005年。https://www.cs.ucsb.edu/research/tech-reports/2005-29

回到顶部

作者

Hsuan-Chi郭hckuo2@illinois.edu),伊利诺伊大学,厄巴纳-香槟,美国。

Jianyan陈jianyan2@illinois.edu),伊利诺伊大学,厄巴纳-香槟,美国。

Sibin汉sibin@illinois.edu),伊利诺伊大学,厄巴纳-香槟,美国。

Tianyin徐tyxu@illinois.edu),伊利诺伊大学,厄巴纳-香槟,美国。

回到顶部

脚注

a.然而,据报道,用于工业软件的测试套件有更高的代码覆盖率。10

要查看附带的技术透视图,请访问doi.acm.org/10.1145/3524299

这篇论文的原始版本发表在计算系统测量与分析ACM论文集, 2020年5月。


版权归所有者/作者所有。
向所有者/作者请求(重新)发布权限

数字图书馆是由计算机协会出版的。版权所有©2022 ACM, Inc.


没有发现记录

Baidu
map