Testing operating system (OS) kernel helper functions accessible through extended BPF (eBPF) filters

Abstract

A method for testing an OS kernel interface, such as an eBPF helper function. The interface has a grammar that defines the kernel interface. Testing is performed using eBPF code that invokes the interface and tests it using a fuzzing engine. To facilitate the process, additional user space code is configured to generate at least one kernel event that triggers execution of the eBPF code and to transform input from the fuzzing engine according to the grammar that defines the kernel interface. After loading the eBPF code into the OS kernel, the user space code issues a kernel event that causes the eBPF code to execute. In response, and when the fuzzing engine executes, the eBPF code records arguments sent to the OS kernel through the kernel interface. The arguments are passed through a data structure shared by the eBPF code and the user space code. By recording the arguments and other diagnostic information, the security of the kernel interface is evaluated.

Description

[Technical Field]

[0001] [Background of the invention] TECHNICAL FIELD This disclosure relates generally to extending an operating system (OS) kernel within a computing environment. [Background technology]

[0002] Berkeley Packet Filter (BPF) technology is a kernel-level feature that allows user-space code to modify the behavior of the operating system kernel while still running within user space. BPF does this through a verified DSL (Domain Specific Language) that ensures that BPF code cannot cause problems for the kernel, treating it as a trusted code base. BPF communicates with the kernel through a well-defined, specially crafted interface.

[0003] The Linux OS kernel provides an enhanced version of the BPF filtering mechanism, called enhanced BPF (eBPF). Typically, eBPF programs contain bytecode instructions provided by a toolchain technology such as LLVM, which compiles C (or other) code into BPF. When the kernel receives an eBPF program from user space, it invokes a verifier to analyze whether the program is safe. Although the verifier checks the activity of the eBPF code, it does not provide any protection once control flow is passed to the kernel. If the verifier indicates that the code is safe, the kernel invokes a just-in-time (JIT) compiler and attaches the resulting instructions to various hook points within the kernel; on the other hand, if the program is unsafe, the kernel rejects it.

[0004] The growing popularity of eBPF (as opposed to classic BPF) has led to the creation of a new interface between eBPF programs and the kernel. While the BPF paradigm ensures security through very strict guidelines, eBPF's extended kernel interface includes new helper functions and the ability to directly access specially exported kernel functions. Because eBPF has new access to kernel internals, methods are needed to test these aspects of the kernel while simultaneously still adhering to the domain-specific constraints imposed by the eBPF runtime environment. These constraints include, for example: the inability to directly invoke kernel code, an action that would normally bypass the eBPF verifier and thereby completely change the threat vector; and the inability to know the kernel state when an eBPF program is running, and therefore to know which parts of the kernel code are executing (this is due to the asynchronous nature of eBPF filters, which run only after a kernel event has occurred).

[0005] Known prior art techniques do not address this need. Kernel fuzzing is one such technique. Fuzz testing, or fuzzing, is an automated software testing method that injects invalid, malformed, or unexpected (e.g., semi-random) inputs into a system to reveal software defects and vulnerabilities. A fuzzing tool injects these inputs into the system and then monitors for exceptions, such as crashes or information leaks. However, kernel fuzzing does not adhere to the constraints imposed by eBPF verifiers. Other BPF verifier / JIT compiler security techniques are also inadequate because they do not check kernel code but instead check the verifier. While BPF fuzzing itself has been proposed in the academic literature, the proposals do not guarantee the generation of valid BPF programs, and the proposed techniques actually exhibit performance degradation.

[0006] There remains a need in the art to provide automated testing of the interface between the kernel and eBPF programs being developed and implemented. Summary of the Invention

[0007] According to a first aspect of the present disclosure, there is provided a method for testing an operating system (OS) kernel interface. The kernel interface has a grammar that defines the kernel interface. The method begins by receiving extended Berkeley Packet Filter (eBPF) code configured to invoke the OS kernel interface and test the OS kernel interface using a fuzzing engine. User space code is also received. The user space code is configured to generate at least one kernel event that triggers execution of the eBPF code and to transform input from the fuzzing engine according to the grammar that defines the kernel interface. After loading the eBPF code into the OS kernel, at least one kernel event is generated. In response to the generation of the at least one kernel event, and when the fuzzing engine is executed, arguments sent to the OS kernel through the kernel interface are recorded. The arguments are passed through a data structure shared by the eBPF code and the user space code.

[0008] Preferably, the OS kernel interface is an eBPF helper function and the data structure is an in-memory map. Further, preferably, a process identifier of the user space code is associated with the eBPF code so that only arguments generated by the user space code are recorded by the eBPF code.

[0009] According to a second aspect of the present disclosure, an apparatus configured as an intermediate device is described. The apparatus includes a processor and computer memory. The computer memory holds computer program instructions that are executed by the processor to test an operating system (OS) kernel interface. The kernel interface includes a grammar that defines the kernel interface. The computer program instructions include program code configured to perform operations such as the steps described above.

[0010] According to a third aspect of the present disclosure, there is provided a computer program product in a non-transitory computer-readable medium, the computer program product carrying computer program instructions for execution by a processor in a host processing system, the computer program instructions configured to test an operating system (OS) kernel interface, the kernel interface including a grammar defining the kernel interface, and the computer program instructions including program code configured to perform operations such as the steps described above.

[0011] The subject matter herein enables the construction of valid eBPF programs that utilize the specific kernel interface under test so as to pass the verifier's checks. Fuzzing of eBPF kernel interfaces is facilitated by including additional user-space code that knows how to transform input from the fuzzing engine according to the grammar that defines the engine. This enables grammar-based fuzzing decisions to be made. Furthermore, the preferred use of an in-memory map (a data structure shared by eBPF code and user-space code) ensures that tests react only to events triggered by user-space code. Another general benefit is that this approach enables testing of the kernel while still adhering to the domain-specific constraints imposed by the eBPF runtime environment.

[0012] The foregoing has outlined some of the more pertinent features of the disclosed subject matter. These features should be construed as merely exemplary. Many other beneficial results can be attained by applying the disclosed subject matter in a different manner or by modifying the subject matter, as will be explained below. [Brief explanation of the drawings]

[0013] Preferred embodiments of the present invention will now be described, by way of example only, and with reference to the following drawings: For a more complete understanding of the subject matter herein and its advantages, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

[0014] [Figure 1] 1 is an exemplary block diagram of a data processing system in which exemplary aspects of the illustrative embodiments may be implemented;

[0015] [Figure 2] 2 is an exemplary block diagram of a volatile memory of the data processing system of FIG. 1;

[0016] [Figure 3] FIG. 1 illustrates a computing system that runs a Linux operating system kernel and supports eBPF techniques.

[0017] [Figure 4] FIG. 1 illustrates a technique implemented during the development phase to generate a set of valid eBPF code and associated user space code that implements the fuzzing techniques of the present disclosure.

[0018] [Figure 5] FIG. 1 illustrates the runtime behavior of eBPF and user space code elements for fuzzing OS helper functions.

[0019] [Figure 6]FIG. 1 illustrates an end-to-end (development and runtime) process flow for automatically evaluating eBPF kernel helper functions, in accordance with the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0020] Various aspects of the present disclosure are described through text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of a computer program product (CPP). With respect to any flowchart, operations may be performed in an order different from that shown in a given flowchart, depending on the technology involved. For example, two operations shown in successive flowchart blocks may be performed in the reverse order, as a single integrated step, simultaneously, or in an at least partially overlapping manner, also depending on the technology involved.

[0021] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also called "mediums") collectively contained in one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing the computer operations set forth in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. Without limitation, the computer-readable storage medium may be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device (such as a punch card or pits / lands formed on a major surface of a disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, is not to be construed as storage in the form of a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media.As will be appreciated by those skilled in the art, data is typically moved at some infrequent time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but the above does not make a storage device transient, as data is not transient while it is stored.

[0022] Computing environment 100 includes an example environment for executing at least some of the computer code involved in implementing the methodology of the present invention, such as OS kernel interface driver code 200 facilitating automated testing of one or more kernel interfaces. In addition to block 200, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, computer 101 includes a processor set 110 (including processing circuitry 120 and cache 121), communications fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and the above-identified block 200), a peripheral device set 114 (including a user interface (UI) device set 123, storage 124, and an Internet of Things (IoT) sensor set 125), and network module 115. Remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a set of host physical machines 142, a set of virtual machines 143, and a set of containers 144.

[0023] Computer 101 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that can execute programs, access a network, or query a database, such as remote database 130. As is well understood in the field of computer technology, and depending on the technology, the performance of a computer-implemented method may be distributed among multiple computers and / or multiple locations. However, in this description of computing environment 100, for purposes of simplicity, the detailed discussion focuses on a single computer, specifically computer 101. Although computer 101 is not depicted in FIG. 1 within a cloud, it may be located within a cloud. However, computer 101 is not required to reside within a cloud except to any extent that may be indicated in the affirmative.

[0024] Processor set 110 includes one or more computer processors of any type now known or later developed. Processing circuitry 120 may be distributed across multiple packages, e.g., multiple linked integrated circuit chips. Processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on processor set 110. Cache memory is typically organized into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all of the cache for a processor set may be located “off-chip.” In some computing environments, processor set 110 may be designed to operate with qubits and perform quantum computing.

[0025] Computer-readable program instructions are typically loaded into computer 101 and cause processor set 110 of computer 101 to perform a series of operational steps, thereby performing a computer-implemented method; the instructions so executed will thus instantiate the methods set forth in the computer-implemented method flowcharts and / or descriptions contained in this document (collectively, the "methods of the present invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by processor set 110 to control and direct the performance of the methods of the present invention. In computing environment 100, at least some of the instructions for performing the methods of the present invention may be stored in block 200 of persistent storage 113.

[0026] Communications fabric 111 is the signal-conducting pathway that allows various components of computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as those that make up buses, bridges, physical input / output ports, and the like. Other types of signal communication pathways may be used, such as fiber optic and / or wireless communication pathways.

[0027] Volatile memory 112 may be any type of volatile memory now known or later developed. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory 112 is characterized by random access, although this is not required unless affirmatively indicated. In computer 101, volatile memory 112 is located in a single package and is internal to computer 101, although alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 101.

[0028] Persistent storage 113 is any form of non-volatile storage for a computer, now known or later developed. The non-volatility of this storage means that stored data is maintained regardless of whether power is supplied to computer 101 and / or directly to persistent storage 113. Persistent storage 113 may be read-only memory (ROM), but typically at least a portion of persistent storage allows data to be written, data to be deleted, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 122 may take several forms, such as Linux employing a kernel, various known proprietary operating systems, or open-source Portable Operating System Interface-type operating systems. The code contained in block 200 typically includes at least some of the computer code involved in implementing the methods of the present invention.

[0029] Peripheral device set 114 includes a set of peripheral devices of computer 101. Data communication connections between peripheral devices and other components of computer 101 may be implemented in various ways, such as Bluetooth connections, near field communication (NFC) connections, connections made by cables (such as universal serial bus (USB)-type cables), insertion-type connections (e.g., Secure Digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, UI device set 123 may include components such as display screens, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. Storage 124 may be external storage, such as an external hard drive, or insertable storage, such as an SD card. Storage 124 may be persistent and / or volatile. In some embodiments, storage 124 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (e.g., computer 101 stores and manages a large database locally), then this storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. IoT sensor set 125 consists of sensors that may be used in Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.

[0030] Network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers over WAN 102. Network module 115 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of network module 115 are implemented on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN)), the control and forwarding functions of network module 115 are implemented on physically separate devices, such that the control function manages several different network hardware devices. Computer-readable program instructions for implementing the methods of the present invention may be downloaded to computer 101, typically from an external computer or external storage device, through a network adapter card or network interface included in network module 115.

[0031] WAN 102 is any wide area network (e.g., the Internet) capable of communicating computer data over non-local distances by any technology for communicating computer data now known or later developed. In some embodiments, WAN 102 may be replaced and / or supplemented by a local area network (LAN) designed to communicate data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include copper transmission cables, optical fiber transmissions, wireless transmissions, and computer hardware such as routers, firewalls, switches, gateway computers, and edge servers.

[0032] End-user device (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating computer 101) and may take any of the forms discussed above in connection with computer 101. EUD 103 typically receives useful and useful data from the operation of computer 101. For example, in the hypothetical case where computer 101 is designed to provide recommendations to end users, the recommendations would typically be communicated from computer 101's network module 115 over WAN 102 to EUD 103. In this manner, EUD 103 can display or otherwise present the recommendations to the end user. In some embodiments, EUD 103 may be a client device such as a thin client, a heavy client, a mainframe computer, a desktop computer, etc.

[0033] Remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. Remote server 104 may be controlled and used by the same entity that operates computer 101. Remote server 104 represents a machine that collects and stores useful and useful data for use by other computers, such as computer 101. For example, in the hypothetical case where computer 101 is designed and programmed to provide recommendations based on historical data, then this historical data may be provided to computer 101 from remote database 130 of remote server 104.

[0034] A public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer capabilities, particularly data storage (cloud storage) and computing power, without direct active management by users. Cloud computing typically leverages resource sharing to achieve consistency and economies of scale. Direct active management of the computing resources of the public cloud 105 is performed by the computer hardware and / or software of a cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers comprising a host physical machine set 142, which is the universe of physical computers within and / or available to the public cloud 105. A virtual computing environment (VCE) typically takes the form of a virtual machine from a virtual machine set 143 and / or a container from a container set 144. It is understood that these VCEs may be stored as images and can be transferred among and between various physical machine hosts, either as images or after instantiation of the VCE. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCE, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that enables public cloud 105 to communicate over WAN 102.

[0035] We now provide some further explanation of virtualized computing environments (VCEs). A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from the image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system where the kernel allows multiple isolated user space instances, called containers, to exist. These isolated user space instances typically behave as actual computers from the perspective of programs running within them. A computer program running on a typical operating system can utilize all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and the devices assigned to that container; this feature is known as containerization.

[0036] A private cloud 106 is similar to a public cloud 105, except that the computing resources are available only for use by a single enterprise. While the private cloud 106 is illustrated as being in communication with the WAN 102, in other embodiments, the private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. While each of the multiple clouds remains a separate, discrete entity, the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of the larger hybrid cloud.

[0037] Figure 2 shows further details of the volatile memory of a computer system such as that shown in Figure 1 after various programs have been loaded from persistent storage. As shown, the volatile memory typically comprises a user space 202 and an OS space 204. As will be explained, user space 202 supports OS kernel interface driver code 200 that facilitates the automated testing methodology described below. OS space 204 supports an OS kernel 205, e.g., Linux, and various kernel support functions and services as will be described next. [eBPF technology]

[0038] By way of further background, and as described above, extended Berkeley Packet Filter (eBPF) technology provides a mechanism that allows sandboxed programs to run within an operating system kernel. eBPF originated in the Linux kernel and allows for safe and efficient extension of kernel capabilities without modifying kernel code or loading kernel modules. eBPF programs are event-driven and execute when the kernel or an application passes through defined hook points, such as system calls, function entry or exit, kernel trace points, networking, and others. FIG. 3 illustrates this basic event-driven operation. As shown, a Linux kernel 300 is running within a computing system 302, such as the computing system shown in FIG. 2 and described above. The kernel 300 has a scheduler component 304. In this example, which is not intended to be limiting, the hook point is a system call. When a process 306 running in user space 307 executes a system call (syscall) 308, an eBPF program 310 is loaded into the kernel. However, before an eBPF program 310 can be attached to a required hook point, it must first pass through a verifier 312 and, if verified, through a just-in-time compiler 314. The verifier 312 and the JIT compiler 314 are kernel services. The verifier 312 ensures that the execution of an eBPF program is safe, for example, that the process 306 that loads the program has the necessary privileges, that the eBPF program, when executed, will not crash, that the eBPF program, when executed, will run to completion instead of looping, and the like.If the eBPF program passes verification, the JIT compiler 314 translates the eBPF program into machine-specific instructions (for the underlying processor hardware) to ensure that the program executes as efficiently as other kernel or kernel module code. In particular, an eBPF program (or "filter") is typically bytecode. While such bytecode may be written directly, typically the program is developed in C code (or the like) and then compiled into eBPF bytecode by a compiler tool such as LLVM. As mentioned above, a JIT compiler converts the bytecode into machine-specific instructions. As also shown in FIG. 3 , the eBPF program 310 has the ability to share collected information and store state using a data structure called the eBPF map 316. The map 316 stores data in one or more map types, such as a hash table, array, ring buffer, stack trace, and the like. The eBPF map 316 is accessible from the eBPF program and from applications (such as the process 306) running in user space 307.

[0039] As also shown, and as described further below in the context of this disclosure, an eBPF program 310 makes function calls to one or more helper functions 318 that are provided as a kernel application programming interface (API). These helper functions are required because eBPF programs are not allowed to call into arbitrary kernel functions. The set of helper functions 318 varies, and new helper functions are constantly being added to the kernel API by developers. Thus, there is a need in the art to provide an approach for testing eBPF kernel interfaces. The techniques of this disclosure, described next, address this need. [Testing the eBPF kernel interface]

[0040] According to this disclosure, and for a particular kernel interface (e.g., a helper function) of interest, a valid eBPF program is constructed, i.e., a program that will later pass inspection by a kernel verifier. To further facilitate fuzzing, strict definitions defined by the kernel interface (helper function) are examined and used to define a grammar (or signature) for the interface. These definitions typically include argument types passed to the interface, the interface (symbolic) name, the interface's return type, how a set of argument types is mapped to return values, and the like. These definitions facilitate the creation of driver code intended to run in user space. The driver code is specialized code designed to cause one or more specific kernel events that trigger an eBPF program loaded into the kernel. The driver code also includes a grammar-based plugin, which is designed to invoke an in-process fuzzing engine (e.g., LibFuzzer) that is later used to test the interface. As will be explained, this grammar-based (or "structure-aware") plugin enables grammar-based ("structurally-aware") fuzzing.

[0041] Figure 4 illustrates the construction of eBPF program and driver code. Typically, these elements are constructed during development. In this exemplary embodiment, the code portions are constructed using technology such as LLVM 400. LLVM 400 is a set of compiler and toolchain technologies that can be used to develop front ends for any programming language and back ends for any instruction set architecture. LLVM is designed around a language-agnostic intermediate representation (IR) that serves as a portable high-level assembly language that can be optimized using various transformations over multiple passes. As shown, LLVM 400 receives several inputs: a user-space fuzzing program template 401, a configuration file 402, an eBPF program template 403, and a header file 404. The configuration file 402 contains the identification of the target helper function (the kernel interface in question), the helper function arguments for fuzzing, the helper properties for fuzzing, the eBPF program type, and event hooks. This information can be provided as an XML file. Additionally, LLVM 400 receives type information for each argument and the structure of the target interface (i.e., the data structure the interface needs to handle). A structure is a way to group several related variables, and each variable in a structure is known as a member of the structure. Unlike arrays, structures can contain many different data types (int, float, char, etc.). Typically, this information is specified by an include in vmlinuz.h header file 404. File 404 is generated code that contains all the type definitions the Linux kernel uses in its source code. After one or more passes through the identified input, LLVM 400 outputs eBPF bytecode 406, to which the calling process attaches and from which helper function calls are made, and user-space fuzzing code 408, which loads the eBPF program, has driver code, and includes a grammar-based plugin with one or more hooks into the fuzzing engine.This completes the development phase.

[0042] As will be explained next, the fuzzing code 408 drives the fuzzing procedure by generating specific kernel events that trigger the eBPF program 406 executing in the kernel during runtime operation. The user space code is the driver of the fuzzing procedure. In particular, because eBPF filters cannot contain specific loops, they must rely on the user space driver to derive new fuzzing inputs and generate events that trigger the eBPF filter to invoke the eBPF helper with those inputs (fuzzing iterations).

[0043] FIG. 5 illustrates the runtime behavior for the code elements described above developed for the problematic helper function 500 (kernel interface). While only one helper function 500 is shown in this diagram, the techniques herein may be practiced for many such helper functions and in an automated manner. As shown, here, user space code 501 comprises a fuzzing harness that drives the fuzzing procedure and provides randomly structured inputs to kernel space eBPF code 505 to test helper function 500 in each fuzzing iteration. In particular, the fuzzing code includes a first component 502 that opens, loads, and attaches to hook points (if the code is verified) in eBPF code 505. This process was generally described with respect to FIG. 3. User space code 501 also includes a second component 504, which is driver code that, among other things, generates one or more specific kernel events of interest that will trigger the eBPF program (after it has been loaded and verified). Additionally, the driver code interfaces with a third component 506, which is a structure-aware plugin to a fuzzing engine 508 (LibFuzzer in this example). Components 502, 504, and 506 are shown as separate, but this is not a requirement. As previously described, eBPF code 505 executes within kernel space (once loaded, verified, and attached to hook points). As shown and described, eBPF code 505 is constructed (operation A1) to be valid eBPF so that it can pass verification by a kernel verifier (not shown). Operation A2 illustrates how helper function definitions (grammars) enable a user to perform grammar-based fuzzing. Operation A3 illustrates how dedicated driver code (here, component 502) enables triggering of the eBPF code. Additional operation A4 illustrates the diagnostic capabilities enabled by this approach. In particular, operation A4 illustrates the eBPF code recording arguments as they are passed to helper functions. Diagnostics can also examine stack traces or other code behavior data.Operation A5 shows the eBPF code checking the driver code's Process IDentifier (PID) to verify that the driver code caused the specific kernel event that invoked eBPF. In this regard, and in accordance with the approach herein, the driver code's PID preferably serves as a key within the eBPF filter to ensure that the system only reacts to events and activities caused by the driver code. The user space code also passes the PID of the fuzzing process to the kernel.

[0044] According to another aspect, operations A4 and A5 as shown in Figure 5 utilize data structures shared by user space code 501 and eBPF code 505. These data structures are sometimes referred to herein as memory maps. The eBPF map shown in Figure 3 may be utilized for this purpose.

[0045] FIG. 6 shows an end-to-end process flow illustrating the development and runtime phases. In step 600, a configuration is created. As described, the configuration specifies the kernel interface to be tested, including, but not limited to, the argument types passed to the interface, the interface (symbol) name, and the interface's return type. In step 602, the kernel interface configuration is passed to the LLVM generate pass, along with a user-space fuzzing program template, an eBPF program template, and header files specifying kernel data structures. In step 604, the LLVM generate pass creates a valid eBPF filter that calls the specified kernel interface using the appropriate eBPF program type. In step 606, the LLVM generate pass also creates user-space code that, when executed, opens, loads, and attaches the eBPF filter. In step 608, the user-space code interfaces with a fuzzing library that handles input generation. As mentioned, the eBPF code is event-driven, and step 608 generates one or more events. In step 610, the user space code passes the process ID (PID) of the fuzzing process to the kernel. In step 612, the user space code converts the input from the fuzzing library into the appropriate type according to the grammar that defines the kernel interface. In step 614, the user space code passes those arguments to the eBPF code through a shared data structure (a memory map, such as the eBPF map described previously). In step 616, the user space code triggers a kernel event that causes the eBPF code to execute. In step 618, the verified, JIT-compiled, and hooked eBPF code records any arguments sent to the kernel through the interface and returns them to the user space code through the shared data structure. This completes the process.

[0046] Thus, according to the present disclosure, a valid eBPF program utilizing a particular kernel interface under test is constructed such that the program passes the verifier's inspection. To this end, the strict definition defined by that interface is examined and used as a grammar to inform the fuzzing decision. After the eBPF filter is loaded, dedicated driver code is used to cause specific kernel events that trigger the loaded eBPF filter into the kernel. When the kernel executes, arguments to the kernel interface are recorded as they are passed, so that even if the kernel crashes, the input that caused the crash can be recovered. In operation, and as mentioned above, the process ID (PID) of the driver code preferably serves as a key within the eBPF filter to ensure that the system only reacts to events caused by the driver code for the particular kernel interface.

[0047] This technique offers significant advantages. This approach makes it possible to construct valid eBPF programs that utilize the specific kernel interface under test so that they pass the verifier's checks. Fuzzing eBPF kernel interfaces is facilitated by including additional user-space code that knows how to transform input from the fuzzing engine according to the grammar that defines the engine. This allows grammar-based fuzzing decisions to be made even when coverage-based fuzzing is not available for use. Furthermore, the use of an in-memory map (a data structure shared by eBPF code and user-space code) ensures that tests only react to events triggered by user-space code. Another general advantage is that this approach makes it possible to test the kernel while still adhering to the domain-specific constraints imposed by the eBPF runtime environment.

[0048] In generalization, methods according to the present disclosure may be implemented as a stand-alone approach, as software-based functionality executed by a processor, or may be available as a managed service (including as a web service via a SOAP / XML interface). Details of specific hardware and software implementations described herein are for illustrative purposes only and are not intended to limit the scope of the described subject matter.

[0049] More generally, computing devices in the context of the disclosed invention are data processing systems (such as those shown in FIG. 2) each comprising hardware and software, and these entities communicate with each other over a network, such as the Internet, an intranet, an extranet, a private network, or any other communications medium or link. Applications on the data processing systems provide native support for Web and other known services and protocols, including, but not limited to, support for HTTP, FTP, SMTP, SOAP, XML, WSDL, UDDI, and WSFL, among others. Information about SOAP, WSDL, UDDI, and WSFL is available from the World Wide Web Consortium (W3C), which is responsible for developing and maintaining these standards; more information about HTTP, FTP, SMTP, and XML is available from the Internet Engineering Task Force (IETF). Familiarity with these known standards and protocols is assumed.

[0050] The schemes described herein can be implemented in or in conjunction with a variety of server-side architectures, including simple n-tier architectures, web portals, federated systems, and the like. The techniques herein can also be practiced in whole or in part in loosely coupled server (including "cloud"-based) environments. eBPF and user-space code generation and / or kernel interface testing can be hosted in the cloud.

[0051] More generally, the subject matter described herein may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements. In a preferred embodiment, functionality is implemented in software, including but not limited to firmware, resident software, microcode, and the like. Furthermore, as noted above, functionality of the analysis engine may take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in association with a computer or any instruction execution system. For purposes of this description, a computer-usable or computer-readable medium may be any apparatus that can contain or store a program for use by or in association with an instruction execution system, apparatus, or device. The medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device). Examples of computer-readable media include semiconductor or solid-state memory, magnetic tape, removable computer diskettes, random access memory (RAM), read-only memory (ROM), rigid magnetic disks, and optical disks. Current examples of optical disks include compact disk-read-only memory (CD-ROM), compact disk-read / write (CD-R / W), and DVD. A computer-readable medium is a tangible item.

[0052] In a representative embodiment, eBPF and user space code generation and kernel interface testing are implemented in a special-purpose computer, preferably in software executed by one or more processors. The software is maintained in one or more data stores or memories associated with the one or more processors, and the software may be implemented as one or more computer programs. Collectively, this special-purpose hardware and software comprise the system described above.

[0053] While the foregoing describes a particular order of operations performed by some embodiments of the disclosed subject matter, it should be understood that such orders are exemplary, as alternative embodiments may perform operations in a different order, combine some operations, overlap some operations, or do the like. Reference to a given embodiment herein indicates that the described embodiment may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include that particular feature, structure, or characteristic.

[0054] Finally, although certain components of the system have been described separately, those skilled in the art will understand that some of the functionality may be combined or shared among certain instructions, program sequences, code portions, and the like.

[0055] As previously mentioned, the techniques disclosed herein are not limited to any particular processing environment, which is an exemplary implementation. As noted, the functionality described above may be used in any system, device, portal, site, or the like where request query syntax may be changed, modified, updated, or otherwise altered.

[0056] The techniques herein provide improvements to another art or field, namely automated test systems, and when used in the manner described, provide improvements to the operational capabilities of such systems.

Claims

1. 1. A method for testing an operating system (OS) kernel interface, the kernel interface including a grammar that defines the kernel interface; receiving extended Berkeley Packet Filter (eBPF) code configured to invoke the OS kernel interface and test the OS kernel interface using a fuzzing engine; receiving user space code configured to generate at least one kernel event that triggers execution of the eBPF code and to transform input from the fuzzing engine according to the grammar that defines the kernel interface; generating the at least one kernel event after loading the eBPF code into the OS kernel; and recording arguments sent to the OS kernel through the kernel interface in response to the generation of the at least one kernel event and when the fuzzing engine is executed, wherein the arguments are passed through a data structure shared by the eBPF code and the user space code; A method comprising:

2. The method of claim 1 , wherein the OS kernel interface is a helper function.

3. The method of claim 1 , further comprising associating a process identifier of the user space code with the eBPF code such that only arguments generated by the user space code are recorded by the eBPF code.

4. The method of claim 1 , wherein the data structure is an in-memory map.

5. receiving a configuration file that specifies one or more argument types passed to the kernel interface, one or more interface symbol names, and one or more return value types of the kernel interface; and processing the configuration file together with a file defining kernel data structures by one or more passes through a compiler; The method of claim 1 , further comprising generating the eBPF code by:

6. The method of claim 1 , wherein the user space code is also configured to open, load, and attach to the eBPF code.

7. The method of claim 1 , further comprising using the recorded arguments to identify the input when a given event occurs.

8. processor; a computer memory holding computer program instructions that are executed by the processor to test an operating system (OS) kernel interface, the kernel interface including a grammar that defines the kernel interface, the computer program instructions comprising: receiving enhanced Berkeley Packet Filter (eBPF) code configured to invoke the OS kernel interface and test the OS kernel interface using a fuzzing engine; receiving user space code configured to generate at least one kernel event that triggers execution of the eBPF code and to transform input from the fuzzing engine according to the grammar that defines the kernel interface; generating the at least one kernel event after loading the eBPF code into the OS kernel; and In response to the generation of the at least one kernel event and when the fuzzing engine is executed, recording arguments sent to the OS kernel through the kernel interface, wherein the arguments are passed through a data structure shared by the eBPF code and the user space code. comprising program code configured to:

1. An apparatus configured as an intermediate device, comprising:

9. The apparatus of claim 8 , wherein the OS kernel interface is a helper function.

10. 9. The apparatus of claim 8, wherein the computer program instructions further include program code configured to associate a process identifier of the user space code with the eBPF code such that only arguments generated by the user space code are recorded by the eBPF code.

11. The apparatus of claim 8 , wherein the data structure is an in-memory map.

12. The computer program instructions include: receiving a configuration file that specifies one or more argument types passed to the kernel interface, one or more interface symbol names, and one or more return value types of the kernel interface; and processing the configuration file together with a file defining kernel data structures by one or more passes through a compiler; The apparatus of claim 8 , also comprising program code configured to generate the eBPF code by:

13. The apparatus of claim 8 , wherein the user space code is also configured to open, load, and attach to the eBPF code.

14. The apparatus of claim 8 , wherein the computer program instructions also include program code configured to use the recorded arguments to identify the input when a given event occurs.

15. 1. A computer program product in a non-transitory computer-readable medium, the computer program product carrying computer program instructions for execution by a processor in a host processing system configured to test an operating system (OS) kernel interface, the kernel interface including a grammar defining the kernel interface, the computer program instructions comprising: receiving enhanced Berkeley Packet Filter (eBPF) code configured to invoke the OS kernel interface and test the OS kernel interface using a fuzzing engine; receiving user space code configured to generate at least one kernel event that triggers execution of the eBPF code and to transform input from the fuzzing engine according to the grammar that defines the kernel interface; generating the at least one kernel event after loading the eBPF code into the OS kernel; and In response to the generation of the at least one kernel event and when the fuzzing engine is executed, recording arguments sent to the OS kernel through the kernel interface, wherein the arguments are passed through a data structure shared by the eBPF code and the user space code. a computer program product comprising program code configured to:

16. 16. The computer program product of claim 15, wherein the OS kernel interface is a helper function.

17. 16. The computer program product of claim 15, wherein the computer program instructions further include program code configured to associate a process identifier of the user space code with the eBPF code such that only arguments generated by the user space code are recorded by the eBPF code.

18. 16. The computer program product of claim 15, wherein the data structure is an in-memory map.

19. The computer program instructions include: receiving a configuration file that specifies one or more argument types passed to the kernel interface, one or more interface symbol names, and one or more return value types of the kernel interface; and processing the configuration file together with a file defining kernel data structures by one or more passes through a compiler; 16. The computer program product of claim 15, also comprising program code configured to generate the eBPF code by:

20. 16. The computer program product of claim 15, wherein the user space code is also configured to open, load, and attach to the eBPF code.

Images