Linux kernel | EPFL Graph Search

The Linux kernel is a free and open-source, monolithic, modular, multitasking, Unix-like operating system kernel. It was originally written in 1991 by Linus Torvalds for his i386-based PC, and it was soon adopted as the kernel for the GNU operating system, which was written to be a free (libre) replacement for Unix. Linux is provided under the GNU General Public License version 2 only, but it contains files under other compatible licenses. Since the late 1990s, it has been included as part of a large number of operating system distributions, many of which are commonly also called Linux. Linux is deployed on a wide variety of computing systems, such as embedded devices, mobile devices (including its use in the Android operating system), personal computers, servers, mainframes, and supercomputers. It can be tailored for specific architectures and for several usage scenarios using a family of simple commands (that is, without the

Advancing the State of Network Switch ASIC Offloading in the Linux Kernel

Andy Roulin

Modern data-center network operating systems rely on proprietary user-space daemons wrapping SDKs from switch vendors. Linux-based variants of these operating systems have benefited from increasing and simplified dataplane offloading support in recent years: kernel resources such as routes and next hops are offloaded to hardware and the kernel can, e.g., learn new MAC entries seen from the hardware forwarding plane. However, the Linux kernel in these operating systems has to be extended and customized as it still lacks constructs (constructs exposed to user-space or in-kernel constructs) needed for complete control plane processing and dataplane offloading. Managing limited hardware resources and keeping the kernel and hardware forwarding planes equivalent are two examples of challenges where the lack of appropriate constructs forces switch operating systems to use user-space solutions coupled with proprietary SDKs and custom kernel modifications. Filling the gaps, i.e., designing and adding the missing constructs, would enable faster control plane processing (less user-kernel context switches) and faster dataplane configura- tion. It would also encourage in-tree kernel drivers from hardware vendors instead of the current closed-source user-space SDKs which would also improve performance while estab- lishing Linux as the standardized API for network switches. This thesis explores the different designs, performance challenges and trade-offs of completing the in-kernel switching API, starting from switch port configuration, faster control path packet processing and ending with in-kernel ASIC resource management. As most hardware vendors are not yet ready to open their drivers in the kernel, workarounds to still provide support for vendors’ SDKs through the same in-kernel API are presented as well. A user-space switch port driver for Mellanox switches was ported to kernel space in order to accelerate control plane processing and bootstrap the in-kernel switch port configuration design. A prefetching scheme which hides PCI latency was designed to manage limited and shared ASIC resources with synchronous feedback to user-space daemons in case of exhausted resources.

2018

USBFuzz: A Framework for Fuzzing USB Drivers by Device Emulation

Mathias Josef Payer, Hui Peng

The Universal Serial Bus (USB) connects external devices to a host. This interface exposes the OS kernels and device drivers to attacks by malicious devices. Unfortunately, kernels and drivers were developed under a security model that implicitly trusts connected devices. Drivers expect faulty hardware but not malicious attacks. Similarly, security testing drivers is challenging as input must cross the hardware/software barrier. Fuzzing, the most widely used bug finding technique, relies on providing random data to programs. However, fuzzing device drivers is challenging due to the difficulty in crossing the hardware/software barrier and providing random device data to the driver under test. We present USBFuzz, a portable, flexible, and modular framework for fuzz testing USB drivers. At its core, USBFuzz uses a software-emulated USB device to provide random device data to drivers (when they perform IO operations). As the emulated USB device works at the device level, porting it to other platforms is straight-forward. Using the USBFuzz framework, we apply (i) coverage-guided fuzzing to a broad range of USB drivers in the Linux kernel; (ii) dumb fuzzing in FreeBSD, MacOS, and Windows through cross-pollination seeded by the Linux inputs; and (iii) focused fuzzing of a USB webcam driver. USBFuzz discovered a total of 26 new bugs, including 16 memory bugs of high security impact in various Linux subsystems (USB core, USB sound, and network), one bug in FreeBSD, three in MacOS (two resulting in an unplanned reboot and one freezing the system), and four in Windows 8 and Windows 10 (resulting in Blue Screens of Death), and one bug in the Linux USB host controller driver and another one in a USB camera driver. From the Linux bugs, we have fixed and upstreamed 11 bugs and received 10 CVEs.

USENIX ASSOC2020

Can Who-Edits-What Predict Edit Survival?

Matthias Grossglauser, Victor Kristof, Lucas Maystre

As the number of contributors to online peer-production systems grows, it becomes increasingly important to predict whether the edits that users make will eventually be beneficial to the project. Existing solutions either rely on a user reputation system or consist of a highly specialized predictor that is tailored to a specific peer-production system. In this work, we explore a different point in the solution space that goes beyond user reputation but does not involve any content-based feature of the edits. We view each edit as a game between the editor and the component of the project. We posit that the probability that an edit is accepted is a function of the editor's skill, of the difficulty of editing the component and of a user-component interaction term. Our model is broadly applicable, as it only requires observing data about who makes an edit, what the edit affects and whether the edit survives or not. We apply our model on Wikipedia and the Linux kernel, two examples of large-scale peer-production systems, and we seek to understand whether it can effectively predict edit survival: in both cases, we provide a positive answer. Our approach significantly outperforms those based solely on user reputation and bridges the gap with specialized predictors that use content-based features. It is simple to implement, computationally inexpensive, and in addition it enables us to discover interesting structure in the data.

ACM2018

Advancing the State of Network Switch ASIC Offloading in the Linux Kernel

Andy Roulin

2018