Automatic OS Kernel TCB Reduction by Leveraging Compile-Time Configurability Reinhard Tartler1, Anil Kurmus2, Bernhard Heinloth1, Valentin Rothberg1, Andreas Ruprecht1, Daniela Dorneanu2, Rudiger¨ Kapitza3, Wolfgang Schroder-Preikschat¨ 1, and Daniel Lohmann1 1Friedrich-Alexander University Erlangen-Nurnberg¨ 2IBM Research - Zurich 3TU Braunschweig Abstract and needs to be repeated at each kernel update. There- The Linux kernel can be a threat to the dependability of fore, maintaining such a custom-configured kernel entails systems because of its sheer size. A simple approach considerable maintenance and engineering costs. to produce smaller kernels is to manually configure the This paper presents a tool-assisted approach to auto- Linux kernel. However, the more than 11;000 configura- matically determine a kernel configuration that enables tion options available in recent Linux versions render this only kernel functionalities that are actually necessary in a a demanding task. We report on designing and implement- given scenario. We quantify the security gains in terms of ing the first automated generation of a workload-tailored reduction of the Trusted Computing Base (TCB) size. The kernel configuration and discuss the security gains such evaluation section (Section 3) focuses on an appliance- an approach offers in terms of reduction of the Trusted like virtual machine that runs a web server similar to those Computing Base (TCB) size. Our results show that the ap- used to power large distributed web services in the cloud. proach prevents the inclusion of 10% of functions known Our approach exhibits promising security improvements to be vulnerable in the past. for this use case: Compared with a default distribution kernel, 10% of the kernel functions (i.e., 17 out of 179), for which in total 31 vulnerabilities have been reported, 1 Introduction are removed from the tailored kernel. The remainder of this paper is structured as follows: The Linux kernel is a commonly attacked target. In 2011, Section 2 presents the design and implementation of the 1 148 Common Vulnerabilities and Exposures (CVE) en- first automated workload-specific kernel-build generation tries for Linux have been recoded, and this number is tool. Section 3 evaluates the usability of such an ap- expected to grow every year. This is a serious prob- proach in a real-world scenario. Security benefits of the lem for system administrators who rely on a distribution- tailored Linux kernel are discussed in Section 4. Sec- maintained kernel for the daily operation of their systems. tion 5 presents the related work. The paper concludes in On the Linux distributor side, kernel maintainers can Section 6. make only very few assumptions on the kernel configura- tion for their users: Without a specific use case, the only option is to enable every available configuration option 2 Kernel-Configuration Tailoring to maximize the functionality. The ever-growing kernel The goal of our approach is to compile a Linux kernel code size, caused by the addition of new features, such as with a configuration that has only those features enabled drivers, file systems and so on, indicates that the risk of which are necessary for a given use case. This section undetected vulnerabilities will constantly increase in the shows the fundamental steps of our approach to tailor foreseeable future. such a kernel. The six necessary steps are depicted in If the intended use of a system is known at kernel com- Figure 1. pilation time, an effective approach to reduce the kernel’s Ê Enable tracing. The first step is to prepare the ker- attack surface is to configure the kernel to not compile nel so that it records which parts of the kernel code are unneeded functionality. However, finding a fitting con- executed at run time. We use the Linux-provided ftrace figuration requires extensive technical expertise about feature, which is enabled with the KCONFIG configuration currently more than 11;000 Linux configuration options, option CONFIG_FTRACE. Enabling this configuration op- 1http://cve.mitre.org/ tion modifies the Linux build process to include profiling 1 1 2 3 4 5 6 Makefile B00 <-> CONFIG_X86 CONFIG_X86=y arch/x86/init.c:59 && CONFIG_NUMA=y _______ B1 <-> CONFIG_NUMA CONFIG_SCSI=m _______ arch/x86/entry32.S:14 _______ arch/x86/... && ... _______ lib/Makefile B2 <-> ! B1 ... kernel/sched.c:723 && ... ... enable run workload correlate to establish a derive a kernel tailored tracing & store trace source line locations propositional configuration Linux Kernel formula Figure 1: Workflow of the approach code that can be evaluated at runtime. Î Derivation of a tailored kernel configuration. A In addition, our approach requires a kernel built with SAT checker proves the satisfiability of this formula and debugging information so that any function addresses returns one concrete configuration that fulfills all these in the code segment can be correlated to functions and constraints. Note that finding an optimal solution to this thus source file locations in the source code. For Linux, problem is an NP-hard problem and was not the focus this is configured with the KCONFIG configuration option of our work. Instead, we rely on heuristics and config- CONFIG_DEBUG_INFO. urable search strategies in the SAT checker to obtain a Ë Run workload. In this step, the system administra- sufficiently small configuration. tor runs the targeted application after enabling ftrace. As the resulting kernel configuration will contain some The ftrace feature now records all addresses in the text additional unwanted code, such as the tracing functional- segment that have been instrumented. For Linux, this ity itself, whitelists and blacklists are employed, allowing covers most code, except for a small amount of critical the user to specify additional constraints in order to force code such as interrupt handling, context switches and the the selection (or deselection) of certain KCONFIG features. tracing feature itself. This results in additional constraints being conjugated to To avoid overloading the system with often accessed the formula just before invoking the SAT checker. kernel functions, ftrace’s own ignore list is dynamically Ï Compiling the kernel. The resulting solution to the being filled with functions when they are used. This propositional formula, obtained as described above, can prevents such functions from appearing more than once in only cover KCONFIG features of code that has been traced. the output file of ftrace. We use a small wrapper script As the KCONFIG feature descriptions declare non-trivial for ftrace to set the correct configuration before starting dependency constraints [25], special care must be taken to the trace, as well as to add functions to the ignore list ensure that as many KCONFIG features as possible are not while tracing and to parse the output file, printing only selected while still fulfilling all dependency constraints. addresses that have not yet been encountered. We therefore use the KCONFIG tool itself to process this Correlation to source lines. A system service trans- feature selection to a KCONFIG configuration that is both lates the raw address offsets to source line locations using consistent and selects as few features as possible. the ADDR2LINE tool from the binutils tool suite. This identifies the source files and the #ifdef blocks that are actually being executed during the tracing phase. Techni- 3 Practical Application cally, the tool stores its result to a text file with source-file names and line numbers on each line. We evaluate the usefulness of our approach by setting up Í Establishment of the propositional formula. This a Linux, Apache, MySQL and PHP (LAMP)-based web step translates the source-file locations into a proposi- presence in a manner that is suited for deployment in a tional formula. The propositional variables of this for- cloud environment. The system serves static webpages, mula are the variation points the Linux configuration tool the collaboration platform DOKUWIKI [7] and the mes- KCONFIG controls during the compilation process. This sage board system PHPBB3 [19] as an example for typical means that every C Preprocessor (CPP) block, KCONFIG real-world applications. We use the distribution-provided item and source file can appear as a propositional variable packages from the Debian distribution without further spe- in the resulting formula. This formula is constructed with cific configuration changes or optimization. Evaluation the variability constraints that have been extracted from results are summarized in Table 1. #ifdef blocks, KCONFIG feature descriptions and Linux Makefiles. The extractors we use have been developed, 3.1 Kernel Tailoring described and evaluated in previous work [5, 21, 22]. The resulting formula holds for every KCONFIG configuration To derive a minimized kernel configuration, the first that enables all source lines simultaneously. step consists of compiling a tracing-enabled Linux ker- 2 nel. We use the standard Linux kernel source and Kernel Shipped by Debian Loaded Code 5;465;602 Bytes configuration from the Debian distribution (version Total Loadable Code 42;188;538 Bytes 2.6.32-41squeeze2) as a template for our tracing kernel Loaded Kernel Modules 29 (Step Ê in Figure 1). On this kernel, we enable the fea- Kconfig options set to y 1;093 tures CONFIG_FTRACE and CONFIG_DEBUG_INFO to include Kconfig options set to m 2;299 Functions with CVE entries 179 the ftrace tracing infrastructure and compile with debug- Intermediary kernel used for tracing ging symbols. As our current prototype is not able to Loaded Code 36;341;888 Bytes resolve functions from loadable kernel modules (LKMs) Total Loadable Code 36;341;888 Bytes yet, we disable module support in the kernel configura- Loaded Kernel Modules 0 Kconfig options set to y 3;298 tion, which causes all compiled code to be loaded into the Kconfig options set to m 0 system at boot time. Functions with CVE entries 207 Resulting application-tailored kernel Furthermore, a number of drivers cause compilation Loaded Code 3;990;153 Bytes and linking errors when not compiled as LKMs.