Interfaces hardening in mixed code operating system kernels

Résumé du projet

We propose to design and implement a hybrid hardening approach for software interfaces in legacy operating system kernels implemented with a mix of safe and unsafe programming languages. The approach is based on types in a memory-safe, strongly-typed programming language and fine-grained hardware compartmentalization features expected in near-future CPUs. The main use case considered is ioctl handlers written in C in the Linux kernel with the Rust safe programming language [1] and CHERI-enabled CPUs (ARM Morello or a RISC-V IP) [2]. The results should pave the way for secure compartmentalization [3] inside legacy operating system kernels.

Description des objectifs et originalité de la thèse

A major part of the Linux kernel attack surface is hidden behind the ioctl system call [4]. This system call is used by many drivers to expose custom services to userspace programs. However, the highly driver-dependent semantics of these services make it difficult to ensure the robustness of this interface. First, driver code is more likely to have vulnerabilities because of less peer-reviewing and scrutiny from the community than core kernel code. Second, the exposed interfaces and their semantics differ between drivers, mandating driver-specific expertise for manual reviewing. This variety makes it difficult to automate bug finding [5].

The Rust-for-Linux project [1] progressively integrates support for Rust-coded drivers in the mainline Linux kernel [6]. It aims at improving the quality of drivers, especially reducing the number of vulnerabilities. However, Rust-for-Linux is mostly effective at preventing memory safety bugs and does not address higher-level semantics-violations [7]. In the context of Rust-for-Linux, ongoing work in the SUSHI team has proposed wrapper types for driver developers to specify  input data checks and prevent access to actual data before all checks are validated. Since the specifications on input data are declared as types in the source code, they can be close to the types of the driver’s interface. Thus, they are more explicit than traditional checks spread in the call graph of the handlers. The design of these wrapper types extends and transposes to Rust the types introduced in RLBox for C++ [8]. The typestate design pattern [9] and its easy applicability with high assurance in safe Rust [10] are leveraged to let the Rust compiler guarantee that the specified checks are done.

Description des principaux verrous et techniques envisagées

Challenge 1: Identify patterns of input validation in the huge diversity of ioctl handlers. A comprehensive set of elementary checks should be identified as well as common sequences of checks and how they are spread in the call graph. The huge amount of ioctl handlers (thousands) makes it mandatory to automate the analysis, for example with taint analysis techniques and semantic pattern matching tools like Coccinelle [11].

Challenge 2: Interpose a mandatory Rust-based input-validation layer. Hardening ioctl handlers using wrapper types involves three sub-challenges. (i) Intermediate stages along the validation paths access already validated parts of the input, which requires identifying valid patterns of access to partially validated values in wrapper types. (ii) The interposition adaptation process should scale and thus be automated and guaranteed to not affect the correctness of the handlers. Interposition patterns could be written as Coccinelle semantic patches [11]. (iii) Using the input-validation layer should be enforced at build time by combining types and lightweight static analysis.

Challenge 3: Make the input-validation layer lightweight and robust despite mixed code. To keep the safety guarantees of the Rust compiler although Rust and C code are executed in the same address space of the kernel, ioctl handlers and the input-validation layer could be isolated from each other using fine-grained hardware compartmentalization. CHERI capabilities [2] could protect the integrity of the input-validation layer and prevent ioctl handlers from accessing unvalidated input. This isolation should be set automatically and add a negligible performance overhead.

Challenge 4: Make the input-validation layer user-friendly enough to promote adoption.  The integration of the Rust-based wrappers of the input-validation layer into common software engineering practice will have to be evaluated. To favor easy adoption by developers, user friendliness must be kept in mind when designing the wrappers. Integration in the most used development environments [12] [13] will be explored.

Approche méthodologique et critères de qualité des résultats obtenus

To start addressing the four challenges early in the project, the problem could be first simplified in two ways before gradually adding automation: by only considering a small set of ioctl handlers and only handlers which check their input in a single place of their call graph.

The CHERI Alliance maintains mature CHERI-enabled versions of the Linux kernel [14] and the LLVM toolchain. However, combining Rust and CHERI is only work in progress [15] [16] [17]. This can be worked around using wrappers managing CHERI capability changes at the boundary between handlers and the input-validation layer. Evaluations requiring real execution can use QEMU/RISC-V as well as ARM Morello boards, one of which will be lent by the CHERI Alliance.

Evaluation criteria will consider performance impact, code quality metrics as well as past CVEs that the approach could have prevented. The results should be submitted in major operating system conferences like EuroSys, ASPLOS, ATC, OSDI, DSN and workshops like HotOS, APSys, KISV and PLOS, as well as security conferences like USENIX Security, NDSS, CCS, AsiaCCS, ACSAC, S&P, EuroS&P and workshops like SysTEX and EuroSec.

Etat de l'art s’appuyant sur un choix de publications importantes liées au sujet

Because of the huge size of the Linux kernel, static-analysis-based techniques to secure system calls must scale and thus be kept simple. The Linux kernel source tree features the ad-hoc sparse tool to annotate pointers to userspace memory and detect unwanted access to such memory [18]. Its use is, however, not mandatory, and it does not enforce any control on the actual input. Coccinelle has been used for years to automatically detect and often fix Linux bugs based on descriptions of C source code patterns and semantic patches [11]. Its potential use to enforce input validation from userspace has not been studied though.

The most popular dynamic-analysis techniques to secure the system call interface are based on fuzzing, typically with syzkaller [19]. However, most ioctl operate on device drivers and testing them requires the actual devices to be present or to have a model allowing to simulate the device.

DIFUZE [20] and later SyzDescribe [21] fuzz device drivers by first using static analysis to automate the description of ioctl data structures and API. Similar static analysis techniques could help interposing an input validation layer and thus secure ioctl handlers without requiring the hardware.

Ongoing work in the Rust-for-Linux project introduces an untrusted data API like RLBox [8] for drivers written in Rust [22]. Although this work is close to the basis of the wrapper types under work in the SUSHI team, it only targets Rust code and does not allow to specify the validations to be made beyond a single validation function to provide.