Testing of operating system (OS) kernel help functions accessible by extended BPF (EBPF) filters

Abstract

A method of testing an OS kernel interface, such as an eBPF assistant function. The interface has a grammar defining a kernel interface. The test is performed using eBPF code that calls and tests the interface using a fuzzy engine. To facilitate the process, the additional user space code is configured to generate at least one kernel event that triggers execution of the eBPF code, and transform input from the fuzzy engine according to syntax defining a 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 run. In response, and when the obfuscation engine is executed, the eBPF code records parameters sent to the OS kernel through the kernel interface. The parameters are communicated over a data structure shared by the eBPF code and the user space code. And evaluating the security of the kernel interface by recording parameters and other diagnostic information.

Description

Background Art Technical Field

[0001] The present disclosure generally relates to extending an operating system (OS) kernel in a computing environment.

[0002] Related technical background

[0003] 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 in user space. BPF does this through a verified DSL (Domain Specific Language) that ensures that BPF code does not cause problems for the kernel, which is treated as a trusted code base. BPF communicates with the kernel through a well-defined, specially crafted interface.

[0004] The Linux OS kernel provides an extended version of the BPF filtering mechanism, called extended BPF (eBPF). Typically, an eBPF program includes 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 calls a verifier to analyze whether the program is safe. Although the verifier verifies eBPF code activity, it does not provide any protection once the control flow is passed to the kernel. If the verifier indicates that the code is safe, the kernel calls the just-in-time (JIT) compiler and attaches the resulting instructions to various hook points in the kernel; however, if the program is unsafe, the kernel rejects it.

[0005] The rise in popularity of eBPF (as opposed to classic BPF) has created 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, a way to test these aspects of the kernel while still complying with the domain-specific constraints imposed by the eBPF runtime environment is needed. These constraints include, for example, the following: kernel code cannot be called directly, otherwise the actions will bypass the eBPF verifier, completely changing the threat vector; and the state of the kernel cannot be known when the eBPF program is executed, and therefore it is impossible to know which pieces of kernel code are exercised (this is because eBPF filters are inherently asynchronous, as they only run after kernel events occur).

[0006] Known prior art does 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. The fuzzing tool injects these inputs into the system and then monitors for anomalies such as crashes or information leaks. However, kernel fuzzing does not obey the constraints imposed by the eBPF verifier. Other BPF verifier / JIT compiler security techniques are also insufficient because they do not check the kernel code but the verifier. BPF fuzzing itself has been proposed in the academic literature, but the proposal does not guarantee the generation of valid BPF programs, and the proposed technique will show performance degradation in practice.

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

[0008] According to a first aspect of the present disclosure, a method for testing an operating system (OS) kernel interface is provided. The kernel interface has a syntax defining the kernel interface. The method begins by receiving an extended Berkeley packet filter eBPF code configured to call and test the OS kernel interface using a fuzzy engine. A user space code is also received. The user space code is configured to generate at least one kernel event that triggers the eBPF code to run, and transforms the input from the fuzzy engine according to the syntax defining the kernel interface. After the eBPF code is loaded into the OS kernel, at least one kernel event is generated. In response to generating the at least one kernel event, and when the fuzzy engine is executed, the parameters sent to the OS kernel through the kernel interface are recorded. The parameters are passed through a data structure shared by the eBPF code and the user space code.

[0009] Preferably, the OS kernel interface is an eBPF helper function, and the data structure is an in-memory mapping. In addition, preferably, the process identifier of the user space code is associated with the eBPF code so that only parameters caused by the user space code are recorded by the eBPF code.

[0010] According to a second aspect of the present disclosure, a device configured as an intermediate device is described. The device includes a processor and a computer memory. The computer memory stores computer program instructions executed by the processor to test an operating system (OS) kernel interface. The kernel interface has a syntax defining the kernel interface. The computer program instructions include program code configured to perform operations such as the above steps.

[0011] According to a third aspect of the present disclosure, a computer program product in a non-transitory computer readable medium is provided. The computer program product stores computer program instructions executed by a processor in a host processing system, and the host processing system is configured to test an operating system (OS) kernel interface. The kernel interface has a syntax defining the kernel interface. The computer program instructions include program code configured to perform operations such as the above steps.

[0012] The subject matter of this article enables the construction of valid eBPF programs that utilize specific kernel interfaces under test so as to pass verifier checks. Fuzzing of eBPF kernel interfaces is facilitated by including additional userspace code that knows how to transform inputs from the fuzzing engine according to the syntax that defines the engine. This enables syntax-based fuzzing decisions to be made. In addition, the preferred use of in-memory mappings (data structures shared by eBPF code and userspace code) ensures that tests react only to events caused by userspace code. Another general advantage is that this method enables testing of kernels while still obeying domain-specific constraints imposed by the eBPF runtime environment.

[0013] Some of the more relevant features of the disclosed subject matter have been summarized above. These features should be interpreted as being merely illustrative. As will be described below, many other beneficial results can be obtained by applying the disclosed subject matter in different ways or by modifying the subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Preferred embodiments of the present invention will now be described by way of example only and with reference to the following drawings, in order to more fully understand the subject matter herein and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

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

[0016] Figure 2 yes Figure 1 An exemplary block diagram of a volatile memory of a data processing system in;

[0017] Figure 3 A computing system running a Linux operating system kernel and supporting eBPF technology is shown;

[0018] Figure 4 depicts techniques implemented during the development phase for generating efficient eBPF code and the associated set of userspace code that implements the obfuscation techniques of the present disclosure;

[0019] Figure 5Describes runtime operations on eBPF and userspace code elements to obfuscate OS helper functions; and

[0020] Figure 6 An end-to-end (development and runtime) process flow for automatically evaluating eBPF kernel helper functions according to the present disclosure is shown. DETAILED DESCRIPTION

[0021] Various aspects of the present disclosure are described by narrative text, flow charts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flow chart, depending on the technology involved, the operations may be performed in an order different from the order shown in a given flow chart. For example, again depending on the technology involved, two operations shown in consecutive flow chart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.

[0022] Computer program product embodiments ("CPP embodiments" or "CPP") are terms used in this disclosure to describe any collection of one or more storage media (also referred to as "media") collectively included in a collection of one or more storage devices that collectively include machine-readable code corresponding to instructions and / or data for performing the computer operations specified 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, a 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: magnetic disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), static random access memories (SRAM), compact disk read-only memories (CD-ROM), digital versatile disks (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punch cards or pits / land formed in 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, should not be construed as storing in the form of transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, light pulses transmitted 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 certain occasional points in time during normal operation of the storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device transient because the data is not transient while it is stored.

[0023] The computing environment 100 includes an example of an environment for executing at least some of the computer codes involved in performing the method of the present invention, such as OS kernel interface driver code 200 that facilitates automated testing of one or more kernel interfaces. In addition to the block 200, the computing environment 100 includes, for example, a computer 101, a wide area network (WAN) 102, an end-user device (EUD) 103, a remote server 104, a public cloud 105, and a private cloud 106. In this embodiment, the computer 101 includes a processor set 110 (including a processing circuit 120 and a cache 121), a communication structure 111, a volatile memory 112, a permanent storage device 113 (including an operating system 122 and a block 200, as described above), a peripheral device set 114 (including a user interface (UI) device set 123, a storage device 124, and an Internet of Things (IoT) sensor set 125) and a network module 115. The remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140 , a cloud coordination module 141 , a host physical machine set 142 , a virtual machine set 143 , and a container set 144 .

[0024] Computer 101 may take the form of a desktop computer, laptop computer, tablet computer, smart phone, smart watch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device now known or developed in the future that is capable of running programs, accessing a network, or querying a database such as remote database 130. As is well known in the art of computer technology, and depending on the technology, the performance of computer-implemented methods may be distributed among multiple computers and / or among multiple locations. On the other hand, in this presentation of computing environment 100, the detailed discussion focuses on a single computer, particularly computer 101, to keep the presentation as simple as possible. Computer 101 may be located in the cloud, even though it is not yet fully understood. Figure 1 1 is not shown in the cloud, on the other hand, computer 101 need not be in the cloud except to any extent that can be positively indicated.

[0025] Processor set 110 includes one or more computer processors of any type known now or to be developed in the future. Processing circuit 120 may be distributed over multiple packages, such as multiple cooperating integrated circuit chips. Processing circuit 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is a memory located in the processor chip package and is typically used for data or code that should be quickly accessed by threads or cores running on processor set 110. Cache memory is typically organized into multiple levels based on relative proximity to the processing circuit. Alternatively, some or all of the caches of the processor set may be located "off chip". In some computing environments, processor set 110 may be designed to work with qubits and perform quantum computing.

[0026] Computer-readable program instructions are typically loaded onto the computer 101 to cause the processor set 110 of the computer 101 to perform a series of operating steps to implement a computer-implemented method, so that the instructions so executed will instantiate the method specified in the flowchart and / or narrative description of the computer-implemented method included in this document (collectively referred to as the "method 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 related data are accessed by the processor set 110 to control and direct the execution of the computer-implemented method. In the computing environment 100, at least some of the instructions for performing the method of the present invention may be stored in a block 200 in a permanent storage device 113.

[0027] The communication fabric 111 is the signal conduction paths that allow the various components of the computer 101 to communicate with each other. Typically, the fabric is made up of switches and conductive paths, such as those that make up a bus, a bridge, physical input / output ports, etc. Other types of signal communication paths may be used, such as fiber optic communication paths and / or wireless communication paths.

[0028] The volatile memory 112 is any type of volatile memory now known or developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Typically, the volatile memory 112 is characterized by random access, but this is not required unless affirmatively indicated. In the computer 101, the volatile memory 112 is located in a single package and is internal to the computer 101, but, alternatively or additionally, the volatile memory can be distributed in multiple packages and / or located externally relative to the computer 101.

[0029] Permanent storage 113 is any form of non-volatile storage for computers known now or developed in the future. The non-volatility of the memory means that the stored data is maintained regardless of whether power is supplied to the computer 101 and / or directly to the permanent storage 113. Permanent storage 113 can be a read-only memory (ROM), but usually at least a portion of the permanent storage allows the writing of data, the deletion of data, and the rewriting of data. Some common forms of permanent storage include disks and solid-state storage devices. Operating system 122 can take several forms, such as Linux, various known proprietary operating systems, or operating systems of the open source portable operating system interface type using a kernel. The code included in block 200 generally includes at least some computer codes involved in executing the method of the present invention.

[0030] The peripheral device set 114 includes a set of peripheral devices of the computer 101. The data communication connection between the peripheral device 114 and other components of the computer 101 can be implemented in various ways, such as a Bluetooth connection, a near field communication (NFC) connection, a connection made by a cable (such as a universal serial bus (USB) type cable), a plug-in type connection (e.g., a secure digital (SD) card), a connection made through a local area communication network, and even a connection made through a wide area network such as the Internet. In various embodiments, the UI device set 123 may include components such as display screens, speakers, microphones, wearable devices (such as goggles and smart watches), keyboards, mice, printers, touchpads, game controllers, and tactile devices. The storage device 124 is an external storage device, such as an external hard drive, or a pluggable storage device, such as an SD card. The storage device 124 can be permanent and / or volatile. In some embodiments, the storage device 124 can take the form of a quantum computing storage device for storing data in the form of quantum bits. In embodiments where the computer 101 needs to have a large amount of storage (e.g., where the computer 101 locally stores and manages a large database), the 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. The IoT sensor set 125 consists of sensors that can be used in IoT applications. For example, one sensor may be a thermometer, while another sensor may be a motion detector.

[0031] The network module 115 is a collection of computer software, hardware, and firmware that allows the computer 101 to communicate with other computers via the WAN 102. The network module 115 may include hardware such as a modem or a Wi-Fi signal transceiver, software for packetizing and / or depacketizing data transmitted over a communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control function and the network forwarding function of the network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software defined networks (SDN)), the control function and the forwarding function of the network module 115 are performed on physically separated devices, so that the control function manages several different network hardware devices. Computer-readable program instructions for executing a computer-implemented method can typically be downloaded to the computer 101 from an external computer or an external storage device via a network adapter card or a network interface included in the network module 115.

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

[0033] End-user device (EUD) 103 is any computer system used and controlled by an end-user (e.g., a customer of an enterprise operating computer 101), and may take any of the forms discussed above in connection with computer 101. EUD 103 typically receives useful and usable data from the operation of computer 101. For example, in the hypothetical case where computer 101 is designed to provide recommendations to an end-user, the recommendations would typically be transmitted from network module 115 of computer 101 to EUD 103 via WAN 102. In this manner, EUD 103 may 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.

[0034] 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 usable 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, the historical data may be provided to computer 101 from remote database 130 of remote server 104.

[0035] The 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 capabilities, without direct active management by users. Cloud computing typically utilizes the sharing of resources to achieve consistency and economy of scale. The direct and active management of the computing resources of the public cloud 105 is performed by computer hardware and / or software of the cloud coordination module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers that constitute the host physical machine set 142, which is the universe of physical computers in and / or available for the public cloud 105. Virtual computing environments (VCEs) typically take the form of virtual machines from a virtual machine set 143 and / or containers from a container set 144. It should be understood that these VCEs can be stored as images and can be transferred between various physical machine hosts as images or after instantiation of the VCEs. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that allows public cloud 105 to communicate over WAN 102 .

[0036] Some further explanation of a virtualized computing environment (VCE) will now be provided. A VCE can be stored as an "image". A new active instance of the VCE can be instantiated from the image. Two common types of VCEs are virtual machines and containers. Containers are VCEs that use operating system-level virtualization. This refers to an operating system feature in which the kernel allows the existence of multiple isolated user space instances, called containers. From the perspective of the programs running in them, these isolated user space instances typically behave like actual computers. Computer programs running on a normal operating system can utilize all of the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running within a container can only use the contents of the container and the devices assigned to the container, a feature known as containerization.

[0037] The private cloud 106 is similar to the public cloud 105, except that the computing resources are only available to a single enterprise. Although the private cloud 106 is depicted as communicating with the WAN 102, in other embodiments, the private cloud can be completely disconnected from the Internet and can only be accessed through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), typically implemented by different vendors. Each of the multiple clouds remains an independent and discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable coordination, management, and / or data / application portability between the multiple constituent clouds. In this embodiment, the public cloud 105 and the private cloud 106 are both part of a larger hybrid cloud.

[0038] Figure 2 Describes the process of loading various programs from permanent storage, such as Figure 1 200. Further details of the volatile memory of the computer system shown. As shown, the volatile memory generally includes a user space 202 and an OS space 204. As will be described, the user space 202 supports the OS kernel interface driver code 200, which facilitates the automated testing method described below. The OS space 204 supports the OS kernel 205 (e.g., Linux), as well as various kernel support functions and services as will now be described.

[0039] EBPF Technology

[0040] As further background, and as described above, the extended Berkeley Packet Filter (eBPF) technology provides a mechanism that enables sandboxed programs to run in an operating system kernel. eBPF, which originated in the Linux kernel, enables kernel capabilities to be safely and efficiently extended without changing kernel code or loading kernel modules. eBPF programs are event-driven and run when the kernel or application passes through defined hook points (such as system calls, function entry or exit, kernel tracepoints, network, etc.). Figure 3 This basic event-driven operation is described. As depicted, the Linux kernel 300 is executed in a computing system 302, such as Figure 2300 and described above. The kernel 300 has a scheduler component 304. In this example, the hook point is a system call, but this is not limiting. 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 being attached to the requested hook point, the eBPF program 310 must first pass a verifier 312 and, if verified, a just-in-time compiler 314. The verifier 312 and the JIT compiler 314 are kernel services. The verifier 312 ensures that the eBPF program is safe to run, for example, that the process 306 that loads the program has the required privileges, that the eBPF program will not crash when executed, that the eBPF program will run to completion instead of looping when executed, and so on. 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 runs as efficiently as other kernel or kernel module code. In particular, in the general case, eBPF programs (or "filters") are bytecodes. Such bytecodes can be written directly, but typically programs are developed in C code (or similar) and then compiled into eBPF bytecodes by a compiler tool such as LLVM. As mentioned above, the JIT compiler converts the bytecodes into machine-specific instructions. Similarly, Figure 3 As shown, eBPF programs 310 have the ability to share collected information and store state using a data structure called an eBPF map 316. Map 316 stores data in one or more map types, such as hash tables, arrays, ring buffers, stack traces, etc. eBPF map 316 is accessible from eBPF programs and from applications executing in user space 307, such as process 306.

[0041] As described above, and as will be further described below in the context of the subject disclosure, the eBPF program 310 makes function calls to one or more helper functions 318, which are provided as kernel application programming interfaces (APIs). These helper functions are needed because eBPF programs are not allowed to call arbitrary kernel functions. The set of helper functions 318 is changing, and developers are constantly adding new helper functions to the kernel API. As such, there is a need in the art to provide methods for testing eBPF kernel interfaces. The techniques of the present disclosure now described address this need.

[0042] Testing the eBPF kernel interface

[0043] According to the present disclosure, and with respect to a specific kernel interface of interest (e.g., a helper function), a valid eBPF program is constructed—that is, a program that will later pass the check of the kernel verifier. In addition, in order to facilitate fuzziness, a strict definition defined by the kernel interface (helper function) is checked, and the strict definition is used to define the syntax (or signature) of the interface. These definitions generally include parameter types passed to the interface, interface (symbol) names, return types of the interface, how parameter type sets are mapped to return values, etc. These definitions facilitate the creation of driver code intended to run in user space. Driver code is a dedicated code that is designed to cause one or more specific kernel events that will trigger the eBPF program loaded into the kernel. The driver code also includes a grammar-based plug-in that is designed to call an in-process fuzzy engine (e.g., LibFuzzer), which is later used to test the interface. As will be described, this grammar-based (or "structure-aware") plug-in enables grammar-based (structure-aware) fuzziness.

[0044] Figure 4The construction of eBPF program and driver code is shown. Usually, these elements are built in development. In this example embodiment, the code segment is constructed by a technology such as LLVM 400. LLVM 400 is a set of compilers and tool chain technologies that can be used to develop a front end for any programming language and a back end for any instruction set architecture. LLVM is designed around a language-independent intermediate representation (IR), which is used as a portable high-level assembly language that can be optimized with various transformations on multiple passes. As shown in the figure, LLVM 400 receives several inputs: user space fuzzy program template 401, configuration file 402, eBPF program template 403 and header file 404. Configuration file 402 contains the identification of the target helper function (kernel interface discussed), the helper function parameters that are fuzzy, the helper attributes that are fuzzy, the eBPF program type and the event hook. This information can be provided as an XML file. In addition, LLVM 400 receives the type information of each parameter and structure (that is, the data structure that the interface needs to process) in the target interface. A structure is a way of grouping several related variables, and each variable in the structure is referred to as a member of the structure. Unlike an array, a structure can contain many different data types (integer, floating point, character, etc.). Typically, this information is specified by the inclusion of a vmlinuz.h header file 404. File 404 is a generated code that contains all type definitions used by the Linux kernel in its own source code. After one or more passes to the identified input, LLVM 400 outputs eBPF bytecode 406 and user space fuzzy code 408, wherein the calling process will be attached to eBPF bytecode 406 and the call to the helper function will be carried out from eBPF bytecode 406, user space fuzzy code 408 loads an eBPF program, has a driver code, and contains a grammar-based plug-in that contains one or more hooks to the fuzzy engine. This completes the development phase.

[0045] As will be described, while the fuzzing code 408 drives the fuzzing process by generating specific kernel events that trigger the eBPF program 406 executed within the kernel during runtime operation, as now described. The userspace code is the driver for the fuzzing process. In particular, because eBPF filters cannot contain certain loops, they need to rely on the userspace driver to derive new fuzzing inputs and generate events that will trigger the eBPF filter to invoke (fuzz iteration) on the eBPF helper with those inputs.

[0046] Figure 5Runtime operations are described with respect to the above-mentioned code elements, which have been developed for the helper function 500 (kernel interface) in question. In the figure, only one helper function 500 is depicted, but the techniques of the present invention can be practiced for many such helper functions and in an automated manner. As shown in the figure, here, the user space code 501 includes a fuzzing harness, which drives the fuzzification process and provides randomly structured inputs to the kernel space eBPF code 505 so as to test the helper function 500 at each fuzzing iteration. In particular, the fuzzified code includes a first component 502, which opens, loads and (if the code is verified) attaches the eBPF code 505 to a hook point. The process generally refers to Figure 3 As described, 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). In addition, the driver code interfaces with a third component 506, a structure-aware plugin, to a fuzzing engine 508 (LibFuzzer in this example). Components 502, 504, and 506 are shown as distinct, but this is not required. The eBPF code 505 (once loaded, verified, and attached to a hook point) runs in kernel space as previously described. As depicted, and as already described, the eBPF code 505 is code that has been constructed as valid eBPF (operation A1) so as to be able to pass verification by a kernel verifier (not shown). Operation A2 describes how helper function definitions (syntax) enable user-based fuzzing based on syntax. Operation A3 describes how dedicated driver code (here component 502) implements the triggering of eBPF code. Additional operation A4 describes the diagnostic functions enabled by this method. Specifically, operation A4 describes the eBPF code recording parameters (when parameters are passed to helper functions). Diagnostics can also examine stack traces or other code behavior data. Operation A5 depicts the eBPF code checking the process identifier (PID) of the driver code to confirm that the driver code caused a specific kernel event that called eBPF. At this point, and in accordance with the methods herein, preferably, the PID of the driver code is used as a keyword in the eBPF filter to ensure that the system reacts only to events and activities caused by the driver code. The user space code also passes the PID of the fuzzy process to the kernel.

[0047] According to another aspect, such as Figure 5 Operations A4 and A5 shown in utilise data structures shared by user space code 501 and eBPF code 505. These data structures are sometimes referred to herein as memory maps. Figure 3 The eBPF map depicted in can be used for this purpose.

[0048] Figure 6 An end-to-end process flow describing the development and runtime phases is depicted. In step 600, a configuration is created. As described above, the configuration specifies the kernel interface under test, including but not limited to the parameter types passed to the interface, the interface (symbol) name, and the return type of the interface. In step 602, the kernel interface configuration is passed to the LLVM generation process along with the userspace fuzzing program template, the eBPF program template, and the header file specifying the kernel data structure. In step 604, the LLVM generation pass creates a valid eBPF filter that will call the specified kernel interface using the appropriate eBPF program type. In step 606, the LLVM generation pass also creates userspace code that opens, loads, and attaches the eBPF filter when executed. In step 608, the userspace code interfaces with the fuzzy library to handle input generation. As described, the eBPF code is event-driven, and step 608 generates one or more events. In step 610, the userspace code passes the process ID (PID) of the fuzzy process to the kernel. In step 612, the userspace code converts the input from the fuzzy library into the appropriate type according to the syntax defining the kernel interface. At step 614, the userspace code passes those parameters to the eBPF code via a shared data structure (a memory map, such as the eBPF map described previously). At step 616, the userspace code triggers a kernel event that causes the eBPF code to run. At step 618, the verified, JIT-compiled, and hooked eBPF code – records any parameters sent to the kernel over the interface, and passes them back to the userspace code via the shared data structure. This completes the process.

[0049] Therefore, according to the present disclosure, a valid eBPF program that utilizes a specific kernel interface under test is constructed so that the program passes the verifier's inspection. To this end, the strict definition defined by the interface is checked and used as the syntax for informing fuzzy decisions. After loading the eBPF filter, a dedicated driver code is used to cause the specific kernel event that triggers the eBPF filter to be loaded into the kernel. When the kernel executes, the parameters to the kernel interface are recorded as they are passed in, so that even if the kernel crashes, the input that caused the crash can be recovered. In operation, and as described above, preferably, the process ID (PID) of the driver code is used as a keyword in the eBPF filter to ensure that the system only reacts to events caused by the driver code of the specific kernel interface.

[0050] This technique provides significant advantages. The method enables the construction of valid eBPF programs that utilize the specific kernel interface under test, thereby passing the verifier check. The fuzzification of the eBPF kernel interface is facilitated by including additional user space code that knows how to transform the input from the fuzzification engine according to the syntax that defines the engine. This enables syntax-based fuzzification decisions to be made, even if coverage-based fuzzification is not available. In addition, the use of in-memory mappings (data structures shared by eBPF code and user space code) ensures that the test only reacts to events caused by user space code. Another general advantage is that the method enables the kernel to be tested while still obeying the domain-specific constraints imposed by the eBPF runtime environment.

[0051] In summary, the methods according to the present disclosure can be implemented as stand-alone methods, such as software-based functions executed by a processor, or they can be available as managed services (including as web services via SOAP / XML interfaces). The specific hardware and software implementation details described herein are for illustrative purposes only and are not meant to limit the scope of the described subject matter.

[0052] More generally, computing devices within the context of the disclosed invention are each a data processing system including hardware and software (such as a Figure 2 The data processing system may be a data processing system that provides 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. Information about SOAP, WSDL, UDDI, and WSFL may be obtained from the World Wide Web Consortium (W3C), which is responsible for developing and maintaining these standards; further information about HTTP, FTP, SMTP, and XML may be obtained from the Internet Engineering Task Force (IETF). Familiarity with these known standards and protocols is assumed.

[0053] The solutions described here can be implemented in or in combination with various server-side architectures, including simple n-tier architectures, portals, federated systems, etc. The technology 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.

[0054] More generally, the subject matter described herein can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment comprising both hardware and software elements. In a preferred embodiment, the function is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. In addition, as described above, the analysis engine function can take the form of a computer program product accessible from a computer-available or computer-readable medium, which provides a program code used by a computer or any instruction execution system or used in combination with a computer or any instruction execution system. For the purpose of this specification, a computer-available or computer-readable medium can be any device capable of containing or storing a program used by an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. The medium can be an electrical, magnetic, optical, electromagnetic, infrared or semiconductor system (or device or device). Examples of computer-readable media include semiconductor or solid-state memory, magnetic tape, removable computer disk, random access memory (RAM), read-only memory (ROM), hard disk and optical disk. Current examples of optical disks include compact disk-read-only memory (CD-ROM), compact disk-read / write (CD-R / W) and DVD. Computer-readable media are tangible items.

[0055] In a representative embodiment, eBPF and user space code generation and kernel interface testing are implemented in a dedicated 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 can be implemented as one or more computer programs. Collectively, the dedicated hardware and software comprise the above-described system.

[0056] Although a particular order of operations performed by certain embodiments of the disclosed subject matter is described above, it should be understood that such an order is exemplary, as alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc. References in the specification to a given embodiment indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include that particular feature, structure, or characteristic.

[0057] Finally, while given components of the system have been described separately, those of ordinary skill in the art will understand that some functionality may be combined or shared in given instructions, program sequences, code portions, and the like.

[0058] As already mentioned, the technology disclosed herein is not limited to any particular processing environment, but this will be a typical implementation. As mentioned above, the above functionality can be used in any system, device, portal, site, etc., where the request query syntax can be changed, modified, updated or otherwise altered.

[0059] The techniques herein provide improvements to another technology or technical field, namely, automated testing systems, and improvements to the operational capabilities of such systems when used in the manner described.

Claims

1. A method for testing an operating system (OS) kernel interface, wherein the kernel interface has a syntax defining the kernel interface, the method comprising: receiving an extended Berkeley packet filter (eBPF) code configured to call and test the OS kernel interface using a fuzzing engine; receiving user space code configured to generate at least one kernel event that triggers the eBPF code to run, and transform input from the fuzzing engine according to the grammar defining the kernel interface; After loading the eBPF code into the OS kernel, generating the at least one kernel event; as well as In response to generating the at least one kernel event, and while the fuzz engine is executing, recording parameters sent to the OS kernel through the kernel interface, wherein the parameters are passed through a data structure shared by the eBPF code and the user space code.

2. The method according to claim 1, wherein: The OS kernel interface is a helper function.

3. The method according to claim 1, further comprising: Associating a process identifier of the user space code with the eBPF code such that only parameters caused by the user space code are recorded by the eBPF code.

4. The method according to claim 1, wherein: The data structure is a memory map.

5. The method according to claim 1, further comprising: The eBPF code is generated by: receiving a configuration file specifying one or more parameter types passed to the kernel interface, one or more interface symbolic names, and one or more return types of the kernel interface; as well as The configuration file is processed through one or more passes of the compiler along with a file specifying kernel data structures.

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

7. The method according to claim 1, further comprising: The recorded parameters are used to identify the input at a given event.

8. An apparatus configured as an intermediate device, comprising: processor; A computer memory storing computer program instructions, the computer program instructions being executed by the processor to test an operating system (OS) kernel interface, the kernel interface having a syntax defining the kernel interface, the computer program instructions comprising program code configured to: receiving an extended Berkeley packet filter (eBPF) code configured to call and test the OS kernel interface using a fuzzing engine; receiving user space code configured to generate at least one kernel event that triggers the eBPF code to run, and transform input from the fuzzing engine according to the grammar defining the kernel interface; After loading the eBPF code into the OS kernel, generating the at least one kernel event; as well as In response to generating the at least one kernel event, and while the fuzz engine is executing, recording parameters sent to the OS kernel through the kernel interface, wherein the parameters are passed through a data structure shared by the eBPF code and the user space code.

9. The device according to claim 8, wherein: The OS kernel interface is a helper function.

10. The device according to claim 8, wherein: The computer program instructions also include program code configured to associate a process identifier of the user space code with the eBPF code such that only parameters caused by the user space code are recorded by the eBPF code.

11. The device according to claim 8, wherein: The data structure is a memory map.

12. The device according to claim 8, wherein: The computer program instructions also include program code configured to generate the eBPF code by: receiving a configuration file specifying one or more parameter types passed to the kernel interface, one or more interface symbolic names, and one or more return types of the kernel interface; as well as The configuration file is processed through one or more passes of the compiler along with a file specifying kernel data structures.

13. The device according to claim 8, wherein: The user space code is also configured to open, load and append the eBPF code.

14. The device according to claim 8, wherein: The computer program instructions also include program code configured to use the recorded parameters to identify the input at a given event.

15. A computer program product in a non-transitory computer readable medium storing computer program instructions for execution by a processor in a host processing system, the host processing system being configured to test an operating system (OS) kernel interface, the kernel interface having a syntax defining the kernel interface, the computer program instructions comprising program code configured to: receiving an extended Berkeley packet filter (eBPF) code configured to call and test the OS kernel interface using a fuzzing engine; receiving user space code configured to generate at least one kernel event that triggers the eBPF code to run, and transform input from the fuzzing engine according to the grammar defining the kernel interface; After loading the eBPF code into the OS kernel, generating the at least one kernel event; as well as In response to generating the at least one kernel event, and while the fuzz engine is executing, recording parameters sent to the OS kernel through the kernel interface, wherein the parameters are passed through a data structure shared by the eBPF code and the user space code.

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

17. The computer program product of claim 15, wherein: The computer program instructions also include program code configured to associate a process identifier of the user space code with the eBPF code such that only parameters caused by the user space code are recorded by the eBPF code.

18. The computer program product of claim 15, wherein: The data structure is a memory map.

19. The computer program product of claim 15, wherein: The computer program instructions also include program code configured to generate the eBPF code by: receiving a configuration file specifying one or more parameter types passed to the kernel interface, one or more interface symbolic names, and one or more return types of the kernel interface; as well as The configuration file is processed through one or more passes of the compiler along with a file specifying kernel data structures.

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

Images