Hardware-assisted isolated execution of eBPF programs

Abstract

This invention proposes a hardware-assisted isolated execution method for eBPF programs, comprising: acquiring the eBPF program to be executed; setting all data pages accessed in the eBPF program to non-privileged pages; issuing all memory access instructions in the eBPF program as non-privileged access instructions through just-in-time (JIT) compilation to obtain the program to be executed; running the program to be executed in kernel mode EL1 of the server operating system to obtain the execution result; and during the execution of the program to be executed, the non-memory access instructions in the program to be executed run at the kernel mode EL1 privilege level, and the memory access instructions in the program to be executed are non-privileged access instructions, which are run at the user mode EL0 non-privileged level. By setting the memory of the eBPF program to non-privileged pages, the eBPF program still runs at a privileged level, but is issued with non-privileged memory access instructions. Since the kernel memory is set to privileged pages, the eBPF program cannot access them, thereby ensuring kernel memory safety.

Description

Technical Field

[0001] This invention relates to the field of operating system security technology in computer technology, and particularly to a hardware-assisted isolated execution method and apparatus for eBPF programs. Background Technology

[0002] The operating system is the core software of a computer system, supporting the operation of various services and applications. After more than sixty years of development, the industry has gradually formed a general architecture for operating system security. In recent years, the Linux kernel has proposed a new extended kernel technology, eBPF (extended Berkeley Packet Filter), based on the existing Berkeley Packet Filter (BPF). This allows users to run custom code in kernel space, generating eBPF programs without modifying the kernel source code or loading kernel modules. This application is already widespread in the kernel and is used to extend kernel functionality in various ways. When an eBPF program is loaded, the kernel performs static verification to ensure kernel security.

[0003] The eBPF verifier is used to ensure that eBPF programs do not compromise the kernel's main security mechanisms. The verifier is responsible for checking whether a program to be loaded will harm the operating system kernel. However, some bugs have been found in the verifier's verification logic, which allows problematic programs to pass verification, thus harming the kernel. Figure 1 The verifier's workflow is presented. It consists of three consecutive phases, with the verification logic becoming increasingly complex with each phase. The preprocessing phase relocates all relocations in the eBPF program using a linear scan method, while also checking the legality of instruction formats, such as the presence of illegal opcodes (e.g., indirect calls). The control flow graph inspection phase traverses the eBPF program's control flow graph using a depth-first search method, disabling all out-of-bounds jumps and unreachable code. However, due to its design and implementation complexity, it exposes numerous security vulnerabilities. Statistics show that since 2014, over 60% of vulnerabilities in the eBPF subsystem stem from the verifier's failure to detect security vulnerabilities in eBPF programs, making it a significant source of risk in the kernel.

[0004] Academics have attempted to enhance the execution environment of eBPF programs within the kernel, for example, by using hardware to isolate eBPF programs or by constructing this execution environment based on software error isolation methods. However, on the one hand, due to the lack of comprehensive memory partitioning and fine-grained protection of kernel objects, their methods cannot solve the kernel's memory safety problem; on the other hand, in addition to memory safety, information leakage and kernel availability are also security attributes that need to be considered, which are also issues that related work has not yet addressed. Therefore, there is an urgent need to provide a secure, low-overhead isolated execution environment for eBPF. To protect kernel security, this invention proposes a secure eBPF program execution environment that guarantees kernel integrity, confidentiality, and availability. Summary of the Invention

[0005] The purpose of this invention is to dynamically isolate eBPF programs using hardware, thereby achieving security attributes equivalent to static analysis and solving the security problems of eBPF programs. Furthermore, static analysis suffers from the problem of state explosion, making it impossible for legitimate programs to pass verification, which is a significant obstacle to the development of eBPF programs. This obstacle is eliminated after this invention replaces static analysis. The number of states is related to the complexity of the program code. For example, a simple program, such as the "helloworld" program, has only one execution path, so it has only one state. A complex program, such as one containing if-else statements, has two execution paths, so it has two states. As the number of if statements increases, the number of program states grows accordingly. Generally, if there are n branches, there will be 2^n states. If the program contains loops, the number of states will be even greater, because each loop creates a new state. Static verification needs to ensure that every state of the program is problem-free, so it needs to enumerate all states. When the number of states reaches a certain point, it requires a lot of time and memory, making static analysis difficult to continue, i.e., state explosion. This means that static analysis cannot handle programs containing loops or a large number of branches.

[0006] The design of this invention is based on AArch64 (a 64-bit instruction set architecture for ARM architecture), particularly driven by the increasing popularity of ARM-based processors in the mobile, personal computer, and server markets, but is also applicable to other instruction set architectures (ISAs), such as the x86 instruction set.

[0007] Specifically, such as Figure 12 As shown, this invention proposes a hardware-assisted isolated execution method for eBPF programs, including:

[0008] Step S1: Obtain the eBPF program to be executed. After setting all data pages accessed in the eBPF program to non-privileged pages, issue all memory access instructions in the eBPF program as non-privileged access instructions through just-in-time compilation to obtain the program to be executed.

[0009] Step S2: Run the program to be executed in kernel mode EL1 of the server operating system and obtain the running result; and during the running of the program to be executed, the non-memory access instructions in the program to be executed are run at the kernel mode EL1 privilege level, and the memory access instructions in the program to be executed are non-privileged access instructions, which are run at the user mode EL0 non-privileged level.

[0010] The hardware-assisted isolated execution method for the eBPF program, wherein the just-in-time compilation process in step 1 includes: creating a mapping of the eBPF data in the kernel-mode EL1 application of the eBPF program, mapping the eBPF data to an independent address space to obtain eBPF shadow data, and setting the eBPF shadow data as a privileged page.

[0011] Step 2 includes: the program to be executed directly accesses the eBPF shadow data by calling the helper function provided by the server operating system kernel.

[0012] The hardware-assisted isolated execution method for the eBPF program decouples the accessible and inaccessible data in the eBPF data by allocating a dedicated stack space for each eBPF function in the eBPF program; when the server operating system loads the program to be executed, a dedicated memory region is allocated for the program to be executed as the stack space, and registers are set to point to the stack space in the code of the program to be executed generated by just-in-time compilation.

[0013] The hardware-assisted isolated execution method for the eBPF program includes maintaining a timetable for the program to be executed to record the execution time of each program. The timetable is used to check whether the program has been executed for too long and to forcibly unload the program that has timed out. In addition, when the program is running, the exception handling function in the server operating system kernel is used to monitor whether an exception occurs. If an exception occurs, the program that has timed out is forcibly unloaded.

[0014] The hardware-assisted isolation execution method for the eBPF program, wherein step 2 includes: running the program to be executed in the kernel mode EL1 of the server operating system, and using non-privileged access isolation hardware to create bidirectional isolation between the user-mode application in the server operating system and the program to be executed, and / or using the non-privileged access isolation hardware to create a multi-domain isolated execution environment for the program to be executed loaded by multiple users.

[0015] The hardware-assisted isolated execution method for the eBPF program, wherein step 1 includes: preventing non-privileged access instructions in the program to be executed from accessing illegal memory through a hardware patch on the processor of the server operating system.

[0016] This invention also proposes a hardware-assisted isolated execution device for eBPF programs, comprising:

[0017] Module 1 is used to obtain the eBPF program to be executed. After setting all data pages accessed in the eBPF program to non-privileged pages, all memory access instructions in the eBPF program are issued as non-privileged access instructions through just-in-time compilation to obtain the program to be executed.

[0018] Module 2 is used to run the program to be executed in kernel mode EL1 of the server operating system and obtain the running result; and during the running of the program to be executed, the non-memory access instructions in the program to be executed are run at the kernel mode EL1 privilege level, and the memory access instructions in the program to be executed are non-privileged access instructions, which are run at the user mode EL0 non-privileged level.

[0019] The hardware-assisted isolated execution device for the eBPF program, wherein the just-in-time compilation process of module 1 is as follows: by creating a mapping of the eBPF data in the kernel-mode EL1 application of the eBPF program, the eBPF data is mapped to an independent address space to obtain eBPF shadow data, and the eBPF shadow data is set as a privileged page.

[0020] Module 2 is used for: the program to be executed to directly access the eBPF shadow data by calling the helper function provided by the server operating system kernel;

[0021] By allocating dedicated stack space for each eBPF function in the eBPF program, the accessible data and inaccessible data in the eBPF data are decoupled; when the server operating system loads the program to be executed, a dedicated memory area is allocated for the program to be executed as the stack space, and registers are set to point to the stack space in the code of the program to be executed generated by just-in-time compilation.

[0022] When running the program to be executed, a timetable is maintained to record the execution time of each program to be executed. Based on the timetable, it is checked whether the program has taken too long to execute and the program that has timed out is forcibly unloaded. When running the program to be executed, the exception handling function in the server operating system kernel is used to monitor whether an exception occurs. If an exception occurs, the program that has timed out is forcibly unloaded.

[0023] Module 2 is used to: run the executable program in the kernel mode EL1 of the server operating system, and use the non-privileged access isolation hardware to create bidirectional isolation between the user-mode application in the server operating system and the executable program, and / or use the non-privileged access isolation hardware to create a multi-domain isolated execution environment for the executable program loaded by multiple users;

[0024] Module 1 is used to prevent non-privileged access instructions in the program to be executed from accessing illegal memory through hardware patches on the processor in the server operating system.

[0025] The present invention also proposes an electronic device, including a hardware-assisted isolated execution device for the aforementioned eBPF program, the electronic device being connected to an information display device for displaying the evaluation results using user-set display parameters, attributes, or through an artificial intelligence model.

[0026] The present invention also proposes a storage medium for storing a computer program of a hardware-assisted isolated execution method for executing the eBPF program.

[0027] As can be seen from the above solutions, the advantages of the present invention are:

[0028] This invention proposes an eBPF privilege reduction and isolation technique based on unprivileged memory access isolation. The invention sets the memory of eBPF programs as unprivileged pages (U-pages). The eBPF programs still run at privileged level, but are issued using unprivileged load / store (LSU) instructions. Because kernel memory is set as privileged pages, eBPF programs cannot access them, thus ensuring kernel memory safety. Furthermore, this invention utilizes unprivileged access isolation hardware (Preventing EL0 access to halves of address maps, EOPD) to create bidirectional isolation between user-space applications and eBPF programs, and creates a multi-domain isolated execution environment for multi-user loaded eBPF programs.

[0029] This invention proposes an eBPF pointer de-information technology based on an independent address space. This invention maps eBPF memory to an independent address space (called the eBPF space), ensuring that pointers to this space do not contain any kernel layout information. This effectively maps eBPF memory, originally belonging to privileged pages, to non-privileged pages. Even if these pointers are leaked, attackers cannot deduce the kernel layout. For side-channel attacks, this invention utilizes non-privileged access to transform a Spectre attack at the same privilege level into a Meltdown attack across privilege levels, and uses hardware patches to prevent it, such as using a hardware patch for CSV3 in the processor to prevent Meltdown attacks. Spectre attacks, also known as ghost attacks, exploit processor speculative execution to access illegal memory. Specifically, eBPF programs can only access eBPF data and specific fields of specific kernel objects; all other memory pairs are considered illegal. Simultaneously, this invention proposes a descriptor table to specifically address pointer leaks of pointers to specific kernel objects and the Spectre problem.

[0030] This invention proposes a system availability assurance method that combines active and passive approaches. eBPF programs lack any monitoring mechanism during execution, meaning that if an eBPF program crashes, the entire kernel crashes as well. Furthermore, because the kernel disables preemption during eBPF program execution, if the program fails to terminate or takes too long to execute, the kernel will be unable to respond to other service requests, rendering it unavailable. Existing static analysis indirectly controls the program's potential execution time by controlling the number of analyzed instructions and prevents eBPF program crashes by predicting all execution states. Finally, this invention captures exceptions and monitors the execution time of eBPF programs. Once an eBPF program triggers an exception or times out, it rolls back its state and unloads the eBPF program, thereby ensuring kernel availability.

[0031] Through the above design, this invention, based on hardware isolation, ensures that the program runs regardless of its legitimacy. However, illegal operations are captured by hardware, achieving complete equivalence to the security attributes of static analysis. This provides a low-overhead, isolated execution environment, resolving the security issues of eBPF programs. Furthermore, static analysis suffers from state explosion, preventing legitimate programs from passing verification, a significant obstacle to eBPF program development. This obstacle is eliminated by this invention replacing static analysis. This invention supports running kernel modules as eBPF programs and securely executes system-call-intensive logic from user-space applications within the kernel, improving application performance and further demonstrating its practical value. Attached Figure Description

[0032] Figure 1 Here is a flowchart of the validator's workflow;

[0033] Figure 2 This is a schematic diagram illustrating the operating principle of the present invention;

[0034] Figure 3a , Figure 3b and Figure 3c This is a schematic diagram of the eBPF program structure;

[0035] Figure 4a A diagram of the code generated by the compiler;

[0036] Figure 4b and Figure 4c These are schematic diagrams of the decoupled eBPF stack and kernel stack, respectively.

[0037] Figure 5 This is a schematic diagram of the eBPF memory access isolation process;

[0038] Figure 6 This is a diagram illustrating the execution of a user-mode application.

[0039] Figure 7 This is the eBPF memory mapping diagram of the present invention;

[0040] Figure 8 Here is a diagram of the EL1 system register structure;

[0041] Figure 9 This is a schematic diagram of the memory space from low address to high address;

[0042] Figure 10a and Figure 10b The images show code examples of prolog and pilog in an eBPF program, respectively.

[0043] Figure 11a and Figure 11b These are, respectively, the program diagram and register structure diagram for monitoring the eBPF program execution time of this invention;

[0044] Figure 12 This is a flowchart of the method of the present invention;

[0045] Figure 13 This is a block diagram of the device of the present invention;

[0046] Figure 14 This is a schematic diagram of the structure of the first electronic device of the present invention;

[0047] Figure 15 This is a schematic diagram of the application environment structure of the first electronic device of the present invention;

[0048] Figure 16 This is a schematic diagram of the structure of the second electronic device of the present invention.

[0049] Figure label:

[0050] A - First electronic device;

[0051] Hardware-assisted isolated execution device for B-eBPF program;

[0052] C-Data acquisition equipment;

[0053] D-Information display device;

[0054] 1000 - Second electronic device;

[0055] Ⅰ-Computational Unit;

[0056] II-ROM;

[0057] III-RAM;

[0058] N-bus;

[0059] V-Interface;

[0060] VI - Input Unit;

[0061] VII - Output Unit;

[0062] VIII - Storage medium;

[0063] IX - Communication Unit. Detailed Implementation

[0064] It should be noted that, in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0065] In the absence of further restrictions, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0066] The processor described in this invention is the control center of an electronic device. It can be a single processor or a collective term for multiple processing elements. For example, it can be one or more central processing units (CPUs), application-specific integrated circuits (ASICs), or one or more integrated circuits configured to implement embodiments of this invention, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).

[0067] Alternatively, the processor can perform various functions of the electronic device by running or executing software programs stored in memory and by calling data stored in memory.

[0068] In a specific implementation, as one example, the processor may include one or more CPUs. Each of these processors may be a single-core processor or a multi-core processor. Here, "processor" can refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions). Electronic devices may include servers, desktop computers, laptops, smartphones, tablets, embedded computers, etc., where the embedded computer includes vehicles and robots, etc.

[0069] The memory is used to store the software program that executes the solution of the present invention, and the execution is controlled by the processor. For specific implementation methods, please refer to the above method embodiments, which will not be repeated here.

[0070] It should be noted that the structure of the electronic device shown in the accompanying drawings of this invention does not constitute a limitation thereof. The actual knowledge structure recognition device may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0071] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0072] It should also be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0073] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0074] It should also be understood that, in various embodiments of the present invention, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0075] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0076] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0077] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0078] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0079] To make the above-mentioned features and effects of the present invention clearer and easier to understand, specific embodiments are described below in conjunction with the accompanying drawings. This specification discloses one or more embodiments incorporating the features of the present invention. The disclosed embodiments are merely illustrative. The scope of protection of the present invention is not limited to the disclosed embodiments, but is defined by the appended claims.

[0080] This invention argues that, from the perspective of user-defined code, eBPF programs cannot be simply viewed as kernel extensions. Unlike user-mode applications that request kernel services via system calls, eBPF programs request kernel services via helper function calls. Like eBPF programs, user-mode applications also require isolation to ensure kernel memory safety, and they employ hardware-based dynamic checking methods rather than purely software-based static verification. In the ARM architecture, EL-based memory isolation mechanisms prohibit user-mode applications running on EL0 from accessing kernel memory because kernel memory pages are set as privileged pages. Therefore, if a similar hardware-assisted method can be used to create an isolated execution environment for eBPF programs, some of the arduous checking tasks in static verification can be replaced by hardware-assisted dynamic checking, which is the core idea of ​​this invention.

[0081] Specifically, such as Figure 2 As shown, this invention first sets all data pages accessible to the eBPF program as unprivileged pages (U-pages). Then, during JIT compilation, this invention issues all memory access instructions in the eBPF program as unprivileged access instructions (LSUs). Since the eBPF program runs in kernel mode (EL1), according to the hardware characteristics of LSUs in AArch64, these LSU instructions are considered to be executed in user mode (EL0). Therefore, the eBPF program can access eBPF data on U-pages, but cannot access other kernel memory, because the kernel's original memory is still privileged pages (P-pages). It is worth noting that because the eBPF program's code is not readable or writable by itself, the page containing its code is still a P-page. Non-memory access instructions in the eBPF program (such as function calls) are unaffected and still run at the EL1 privilege level. This invention refers to this instruction-level execution difference brought about by LSUs as instruction-level memory isolation technology. This technology allows the eBPF program to interact with the kernel without switching privilege modes, thus avoiding the overhead of domain switching.

[0082] Besides directly accessing eBPF data, eBPF programs also call kernel-provided helper functions, passing pointers to eBPF data as parameters. However, the Privileged Access Forbidden (PAN) mechanism under AArch64 prevents these helper functions from accessing eBPF data. This is because helper functions are kernel code, and their memory access instructions are still ordinary LS instructions. Furthermore, since helper functions also access kernel data, their memory access instructions cannot be translated into LSU instructions like those in the eBPF program. To address this issue, this invention creates an additional mapping for eBPF data, which we call eBPF shadow data. These pages are set as P-pages, allowing helper functions to access them directly. Before the eBPF program calls a helper function, the corresponding parameter pointer is relocated to point to the shadow data region. The eBPF data is declared within the eBPF program and is also the data the eBPF program needs to access.

[0083] eBPF memory decoupling

[0084] In eBPF, because all eBPF objects are not contiguous, each object may be of different sizes, and only the data area, not the metadata area, can be accessed within an object, existing static security checks can only determine whether each pointer is out of bounds by using more precise subtypes. This fragmented accessible memory poses a challenge to privilege-level-based memory isolation. This invention proposes decoupling accessible data from inaccessible memory in eBPF data objects, allowing these accessible data to be checked using a unified data type, thus matching the capabilities of exception-level-based memory isolation. The specific decoupling method is described below using an eBPF stack frame as an example.

[0085] eBPF programs use the eBPF stack frame, located at the top of the current kernel stack, to store local variables. The eBPF stack pointer register (R10) is mapped to a physical general-purpose register (such as the x25 register on AArch64), and all local variables are accessed through this register or its derived pointers. Additionally, the return address and callee-saved registers are also stored in the stack frame, but these contents can only be accessed through the physical stack pointer register (the sp register on AArch64).

[0086] like Figure 3a As shown, suppose an eBPF program contains two functions—bar() and foo(). After the program is loaded into the kernel, the kernel's run() function calls the program's entry point function, bar(), and subsequently, bar() internally calls foo(). (See above.) Figure 3bAs shown, for each function in an eBPF program, the code generated by the JIT compiler consists of three parts: prolog, function body, and epilog. The first part, prolog, mainly includes three steps: 1) saving the callee-saved register on the kernel stack (line 2), which is required by the calling convention; 2) initializing the eBPF stack register (line 3), i.e., assigning a value to the eBPF stack register x25 using the current kernel stack pointer register sp, after which both registers point to the kernel stack; 3) expanding the eBPF stack (line 4), by subtracting the required memory size from the kernel stack, thus completing the allocation of space for the eBPF stack. The second part, function body, is translated from the bytecode in the eBPF function. eBPF bytecode is relatively simple, mostly corresponding one-to-one with native instructions. Finally, the function's epilog first reclaims stack space (line 11), its size corresponding to the size allocated in the prolog, and then restores the callee-saved register to ensure stack balance. Finally, there is a return instruction, which is responsible for popping the return address from the stack and returning control flow to the caller function.

[0087] superior Figure 3c The diagram illustrates the kernel call stack layout during the execution of the `foo()` function. At the top are the local variables of the kernel's `run()` function. When `run()` calls the `bar()` function, the calling convention pushes the return address onto the stack. Then, during the execution of `bar()`, the callee-saved register is first saved, followed by initialization of the eBPF stack frame register x25, and then stack expansion to save the local variables of the `bar()` function. The process of `bar()` calling `foo()` is similar, saving the return address and caller-saved register respectively, and setting the stack registers. Finally, the kernel's `sp` register points to the top of the kernel stack, while the eBPF stack register x25 points to the bottom of the eBPF stack.

[0088] From the current layout, the local variables of the eBPF program are coupled with other data on the kernel stack. Static verification ensures that memory accesses on the stack are always within the local variables of the eBPF stack by tracing the range of the stack pointer and its derived pointers. However, without static verification, the LSU mechanism alone cannot guarantee the safety of other data on the stack (such as the return address). Therefore, the eBPF stack must be decoupled from the kernel stack.

[0089] This invention observes that in the code generated by JIT, only the function bodies are controllable by eBPF functions, while the instructions in prolog and epilog are not. Furthermore, all local variables within the function bodies are generated from the x25 register, which is also controlled by instructions in prolog. Based on these observations, this invention employs a secure stack—placing safe data (i.e., return addresses and callee-saved registers) on the original kernel stack, while isolating unsafe data (i.e., applied local variables) onto a new stack.

[0090] To achieve this, during application loading, this invention allocates a dedicated memory region as the eBPF stack (one for each CPU core) and sets the x25 register to point to this space in the prolog code generated by JIT. Since there is no static verification, this invention cannot determine the size of the stack frame in each function; therefore, it uses the upper limit of the allowed eBPF stack size (512 bytes) as the fixed size of each stack frame. The total size of the eBPF stack is set to 8MB by default. During application loading, this invention only allocates memory for the two memory pages at the bottom of the stack; the remaining pages are allocated delayed through page fault exceptions.

[0091] As above Figure 4a As shown, for each eBPF function, in the prolog of the code generated by the JIT compiler, the eBPF stack register x25 is no longer set via the sp register, but instead set to the stack address specific to this function (line 3). Since eBPF programs do not allow recursion, there is no need to consider the case where the same function appears twice on the call stack. Furthermore, since the eBPF stack has already been allocated, the original stack allocation instructions (lines 4 and 9) can be optimized away. Apart from this, other code generated by the JIT compiler remains unaffected, and the code within the eBPF program itself does not require adjustment.

[0092] superior Figure 4b and Figure 4cThe decoupled eBPF stack and kernel stack are shown separately, with each eBPF function having its own dedicated stack space. It's important to note that metadata generated by the calling convention is inaccessible to the eBPF program and can only be accessed via push / pop instructions generated in the prolog and epilog by the JIT (just-in-time) compiler; therefore, it is retained on the kernel stack. Furthermore, another advantage of this design is that it eliminates the need for stack switching when calling helper functions; the kernel's helper functions still use the kernel stack. Simultaneously, the control flow security of the eBPF program ensures that these instructions cannot be abused by attackers. Finally, to prevent attackers from causing kernel stack overflow through continuous function calls, this invention places an unmapped protection page at the lowest position of the kernel stack. Any exceptions triggered after an overflow will be captured by this invention, thereby unloading the eBPF program.

[0093] eBPF access isolation

[0094] After decoupling, the memory associated with eBPF data object pointers is completely decoupled from their metadata. Figure 5 middle Subsequently, this invention sets up these memories as U-pages and aggregates them together (maximum 1TB), storing them according to the eBPF stack, map values ​​(maps are arranged in the order of their creation), and the slab order specific to network packets. Figure 5 middle For eBPF programs, this invention modifies the eBPF JIT compiler to issue all memory access instructions in the eBPF program as LSU instructions during JIT.

[0095] by Figure 5 middle The code shown, for example, contains an 8-byte local variable `time`, which is initialized by calling the helper function `bpf_get_time()`. The corresponding eBPF bytecode for this program is as follows: Figure 5 middle As shown, register R10 is the stack register in the eBPF instruction set. Therefore, R1 is initialized as a pointer to the time variable. After calling the bpf_get_time() function, according to the calling convention, the return value is in register R0. Then, the contents of this register are written to the memory pointed to by R1, i.e., the time variable.

[0096] The code generated by the untuned JIT compiler is as follows Figure 5 middle As shown, the R0, R1, and R10 registers of eBPF correspond to the x7, x0, and x25 registers in AArch64, respectively. After the helper function returns, this code uses the str instruction to write the return value register x7 to the memory location pointed to by register x0 at offset 0. The code generated by the adjusted JIT compiler is as follows. Figure 5 As shown. After the helper function returns, it accesses memory using the sttr instruction, a non-privileged access instruction provided by the LSU hardware features; other instructions within the function body remain unchanged. If an attacker maliciously modifies the kernel memory pointed to by the x0 register, the program will crash because non-privileged access instructions cannot access privileged pages. This will allow the program to be captured and uninstalled by this invention. In this way, eBPF data object pointers no longer require object-level range checks, but only utilize exception-level memory isolation mechanisms. It is worth noting that an attacker can modify x0 to point to any non-privileged page, such as changing a pointer that originally pointed to the stack to a value in the map. However, since this memory is already freely accessible to the program, it will not pose any security risks.

[0097] Furthermore, this degraded privilege method introduces a new attack surface: because eBPF memory is downgraded to the user privilege level, eBPF programs cannot be isolated from user-space applications; that is, eBPF code and user code can access both eBPF memory and user-space memory simultaneously. To address this issue, this invention utilizes E0PD hardware functionality to establish bidirectional isolation between eBPF memory and user-space memory.

[0098] like Figure 6 As shown, during user-mode application execution, due to the isolation caused by different exception levels, user-mode code cannot access P-pages in the kernel, but can access eBPF memory because they are U-pages. This invention addresses this by additionally setting the E0PD0 bit in the TCR_EL1 register to 0 and the E0PD1 bit to 1, indicating that access to the lower address space (i.e., user space) is possible, but access to the higher address space (i.e., kernel space) is blocked. Therefore, user-mode applications can execute normally but cannot access eBPF-related memory.

[0099] Conversely, when the CPU switches to kernel mode, this invention enables E0PD0 and disables E0PD1 by setting the TCR_EL1 register, thus allowing access only to the high address space (i.e., kernel space). Since all memory in the kernel except for eBPF memory is P-page, non-privileged access instructions in eBPF programs can only access eBPF memory and cannot access user space. It is worth noting that push / pop instructions in the prolog / epilog of eBPF programs normally access the kernel stack (P-page), but these accesses are safe because they are generated by the JIT compiler, not the eBPF program. All E0PD-related settings require only one instruction to change the corresponding bit in the TCR_EL1 register. This overhead is negligible compared to the overall context switch time.

[0100] Helper functions have memory access isolation.

[0101] In addition to direct memory access, eBPF data object pointers can also be passed as parameters to helper functions. To prevent obfuscation attacks, static verification performs out-of-bounds checks on the parameters when encountering helper function calls during the examination of eBPF programs. Therefore, this invention also needs to provide equivalent security guarantees.

[0102] Furthermore, since the eBPF data object pointers used in eBPF programs all point to U-pages, even if the eBPF program passes the correct pointer, the helper function cannot access it. This is because the memory access instructions in the helper function are regular LS instructions, and because the kernel has PAN enabled by default, LS instructions in the kernel cannot access eBPF memory with U-page attributes. Although temporarily disabling PAN when calling the helper function can solve this problem, it will reduce kernel security and increase the performance overhead of the eBPF program.

[0103] To solve this problem, such as Figure 7As shown, this invention double-maps the aggregated U-page attribute eBPF memory to P-pages, placing this region within the highest 1TB range of the kernel space. Based on this design, before the helper function call, this invention iterates through the parameter list of the called function. If a parameter containing an eBPF data object pointer exists, an instruction `orrxn,xn,0xffffff0000000000` is inserted before the function call instruction. During eBPF program execution, this instruction sets the high 24 bits of the parameter register to 1, leaving the low 40 bits unchanged. Therefore, the offset of the pointer relative to the eBPF memory (set to 1TB) is preserved, and the pointer is then directed to the corresponding location in the eBPF shadow memory. In this way, the helper function in the kernel can indirectly access eBPF memory. Simultaneously, this logical OR instruction also controls pointer out-of-bounds access. Even if the pointer is tampered with by an attacker, after adjustment by this instruction, the actual pointer will always point to the shadow memory region, which contains no other kernel memory besides the memory accessible by the eBPF program.

[0104] Multi-domain isolation:

[0105]

[0106] Since different eBPF programs may be loaded by multiple users, these applications also need to be isolated. To provide a multi-domain isolated execution environment, this invention audited all available hardware features in AArch64 to find suitable solutions. As shown in the table above, this invention summarizes all available hardware features and their available domains and domain switching overhead. Among them, the LSU used in this invention can create two isolation domains to isolate eBPF programs from the kernel. Combined with E0PD, it can further create bidirectional isolation between user-space applications and eBPF programs. Among the remaining available hardware, HPD or E1PD can only provide two domains, which is difficult to meet the requirements, and E1PD conflicts with the LSU usage method in this invention and cannot be used. TxSz can adjust the size of the kernel space to make some of its contents inaccessible, but this adjustment is unidirectional and cannot meet the flexible isolation requirements. The Watchpoint mechanism uses the debug register to monitor the reading and writing of specific contents. By modifying the value of the debug register, the monitoring range can be adjusted, thereby switching between different isolation domains. However, since there are only 4 debug registers in AArch64, only 4 efficient isolation domains can be created. That is, domain switching only requires modifying the debug register once (42 cycles). Although up to 16 domains can be combined by overlapping the monitoring ranges of different debug registers, this will increase the overhead of domain switching.

[0107] Based on the above analysis, this invention utilizes kernel page table switching to switch between different eBPF program executions. On one hand, this mechanism has no limit on the number of isolation domains and is compatible with the usage of LSU and E0PD in this invention. On the other hand, the domains created by this mechanism have the lowest overhead during switching. Specifically, this invention creates a kernel page table for each eBPF program. These page tables share the same kernel memory but only contain the memory of the eBPF program itself. During eBPF program execution, this invention switches the corresponding page table by setting the TTBR1_EL1 system register.

[0108] like Figure 8 As shown, the TTBR1_EL1 system register is divided into two parts: the high 16 bits are the address space identifier (ASID), and the low 48 bits are the specific page table base address (BADDR). To avoid frequent TLB shootdowns, this invention assigns an ASID to each eBPF program, and switches the corresponding ASID simultaneously when switching page tables. Finally, to avoid unnecessary page table switching, this invention merges eBPF programs of the same type and capability from the same user into a single page table, and switches the page table only when different eBPF programs switch execution.

[0109] Independent address space

[0110] To address the pointer leakage problem of eBPF data objects, this invention creates an independent address space for each eBPF program, which stores the eBPF data objects decoupled from the kernel, including eBPF stack frames, all map values, and dedicated slab memory. For example... Figure 9 As shown, from low address to high address, they are user space (256TB), memory reserved area (nonlinear addressing space), kernel space (254TB), BPF space (1TB), and BPF shadow space (1TB).

[0111] Specifically, during operating system startup, this invention adjusts the kernel randomization process, excluding up to 2TB of space from the kernel address space randomization process, thus completely decoupling the BPF space from the kernel space. During eBPF program loading, all pointers to eBPF data objects are relocated to point to the BPF space upon creation. In this way, eBPF programs can arbitrarily leak pointers to eBPF data objects, because even if they are leaked, attackers cannot deduce any kernel layout information from the values ​​of these pointers.

[0112] The memory layout within the BPF space is also fixed, consisting of, from lowest to highest, the eBPF stack frame, map values ​​(different maps are stored in the order they are declared within the eBPF program), and slab memory mappings dedicated to network packets. Therefore, even without running the target eBPF program, an attacker can deduce the specific memory address.

[0113] Furthermore, this invention initializes all memory allocated in the BPF space when the eBPF program is loaded. Each time the eBPF program executes, the current kernel's BPF stack frame is reused without re-initialization. Therefore, if the eBPF program fails to initialize the eBPF stack frame during execution, the content read will be the content from the previous execution, preventing kernel memory leaks.

[0114] Finally, eBPF relies on static verification to identify potentially exploitable code, dynamically preventing Spectre v1 and v4 attacks. Note that Spectre v2 attacks do not exist in eBPF programs because they cannot contain indirect call instructions. The key to both Spectre v1 and v4 attacks is transient access to sensitive data (such as kernel data) and using the accessed values ​​to encode and access legitimate memory addresses that cause changes in cache state.

[0115] This invention transforms memory access instructions in eBPF programs into non-privileged memory access instructions. Therefore, speculative access to kernel space will trigger a privilege malfunction, thus converting a Spectre attack into a Meltdown attack. Building upon this, the invention utilizes a hardware patch called CSV3 in ARM commercial processors. If a speculative execution would trigger a privilege malfunction, this patch prevents the data accessed during that speculative execution from being used as the target address for subsequent memory access instructions, thereby preventing a Meltdown attack. Therefore, through the modification of the LSU instruction and the CSV3 patch, this invention can block Spectre attacks at the hardware level without requiring software modifications to the kernel or eBPF program code.

[0116] Combating Denial-of-Service Attacks

[0117] eBPF programs can pose two types of denial-of-service attacks: triggering exceptions and executing without terminating. For the former, this invention passively captures all triggered exceptions, determines them to be illegal, unloads the eBPF program, and rolls back the kernel's execution state to the program's entry point. For the latter, this invention checks all eBPF execution times each time an interrupt occurs, and unloads the eBPF program and rolls back the state when the execution time reaches a certain threshold.

[0118] The method for catching exceptions is relatively straightforward; this invention achieves this by hooking exception handling functions in the kernel (such as the `handle_page_fault()` and `die_kernel()` functions). For rollback states, the eBPF program will change the system state in the following four ways:

[0119] • eBPF data in BPF space, including map values ​​and eBPF stack frames, are not considered in dedicated slabs because this memory is read-only for eBPF programs;

[0120] • eBPF-related management structures in the kernel, including map metadata, kernel stack, etc. The former is generated before the eBPF program is created and destroyed after the eBPF program is unloaded, while the latter changes with the function calls inside the eBPF program.

[0121] • Kernel objects accessible to eBPF programs, such as context objects, have most fields that are inaccessible to eBPF programs, and most of the open fields are read-only.

[0122] • eBPF-related registers, including registers corresponding to the eBPF instruction set and reserved registers used by the JIT compiler, are saved on the kernel stack by the eBPF program's prolog (controlled by the JIT compiler) before entering the eBPF code. When the eBPF program exits, its epilog restores these registers from the kernel stack.

[0123] Of the four types of data mentioned above, changes to the first two types will not affect the kernel state. For the third type of data, fields accessible to the eBPF program for modification will not affect kernel execution even if modified, since legitimate programs can arbitrarily modify these fields. Therefore, this invention only needs to uninstall the eBPF program to clear this data. Finally, to restore the registers, this invention needs to additionally record the kernel stack pointer (sp register) at the entry point of the eBPF program and save it to a reserved register (x28, invisible to eBPF). After the eBPF program triggers an exception, the kernel stack pointer (sp register) is restored to the x28 register of the exception context, and the program jumps to the prolog of the eBPF program, thus completing the rollback of the register state.

[0124] As shown in Figure 10, the prolog of the eBPF program saves the callee-saved registers involved in eBPF on the kernel stack. Among them, registers x23, x24, and x28 are introduced in this invention. Other registers (such as parameter registers x0-x4) do not need to be considered, because either these registers do not need to be saved or the kernel will save them. After this, this invention adds an instruction to save the stack pointer sp register into register x28 (line 7). Since this register is not visible to the eBPF program, it cannot be modified by the eBPF program. At the same time, this register is a callee-saved register, so helper function calls will not change this register. Once a crash is maliciously triggered during the execution of the eBPF program, this invention can parse the x28 register at the crash scene to locate the stack position at the entry point of the eBPF program, and then jump to the epilog code of the eBPF program to restore the values ​​of the registers one by one, and finally return to the kernel code through a ret instruction.

[0125] This invention maintains a schedule for the eBPF programs already loaded in the kernel to record the execution time of each eBPF program. Additional logic is inserted into the kernel's `schedule()` function, which is called each time interrupt handling logic ends to check if an eBPF program has taken too long to execute. First, it checks if any eBPF program is running on any core. If found, it retrieves the current execution time of the corresponding eBPF program by looking up the schedule and checks if the execution time exceeds a preset limit (default is the execution time of 1 million instructions). Programs that time out are forcibly unloaded; for programs that do not time out, this invention updates their schedule using the current time.

[0126] This invention designs a two-level execution configuration for eBPF programs based on program type and time level. First, each type of eBPF program is allowed a different execution time, which is configured by the system administrator. Second, for the same program type, different programs can also have different execution times. For example... Figure 11a and Figure 11b As shown, at the entry point of the eBPF program, this invention uses the tpidrro_el0 register to record the current program type and time level. During inspection, the corresponding execution time limit is queried through this register. Note that each core has one of these registers, and the kernel does not use this register; therefore, it is only necessary to clear this register before the eBPF program exits.

[0127] The duration calculation above is accurate because eBPF programs execute non-preemptively. The advantage of this method is that the execution time statistics also include the execution time of helper functions, thus avoiding denial-of-service issues that can arise from estimating only the execution time of the eBPF program.

[0128] The following are system embodiments corresponding to the above method embodiments. This embodiment can be implemented in conjunction with the above embodiments. The relevant technical details mentioned in the above embodiments are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above embodiments.

[0129] like Figure 13 As shown, the present invention also proposes a hardware-assisted isolated execution device for eBPF programs, comprising:

[0130] Module M1 is used to obtain the eBPF program to be executed. After setting all the access data pages in the eBPF program to non-privileged pages, it issues all memory access instructions in the eBPF program as non-privileged access instructions through just-in-time compilation to obtain the program to be executed.

[0131] Module M2 is used to run the program to be executed in kernel mode EL1 of the server operating system and obtain the running result; and during the execution of the program to be executed, the non-memory access instructions in the program to be executed are run at the kernel mode EL1 privilege level, and the memory access instructions in the program to be executed are non-privileged access instructions, which are run at the user mode EL0 non-privileged level.

[0132] The hardware-assisted isolated execution device for the eBPF program, wherein the just-in-time compilation process of module 1 is as follows: by creating a mapping of the eBPF data in the kernel-mode EL1 application of the eBPF program, the eBPF data is mapped to an independent address space to obtain eBPF shadow data, and the eBPF shadow data is set as a privileged page.

[0133] The M2 module is used for: the program to be executed to directly access the eBPF shadow data by calling the helper function provided by the server operating system kernel;

[0134] By allocating dedicated stack space for each eBPF function in the eBPF program, the accessible data and inaccessible data in the eBPF data are decoupled; when the server operating system loads the program to be executed, a dedicated memory area is allocated for the program to be executed as the stack space, and registers are set to point to the stack space in the code of the program to be executed generated by just-in-time compilation.

[0135] When running the program to be executed, a timetable is maintained to record the execution time of each program to be executed. Based on the timetable, it is checked whether the program has taken too long to execute and the program that has timed out is forcibly unloaded. When running the program to be executed, the exception handling function in the server operating system kernel is used to monitor whether an exception occurs. If an exception occurs, the program that has timed out is forcibly unloaded.

[0136] The module M2 is used to: run the executable program in the kernel mode EL1 of the server operating system, and use the non-privileged access isolation hardware to create bidirectional isolation between the user-mode application in the server operating system and the executable program, and / or use the non-privileged access isolation hardware to create a multi-domain isolated execution environment for the executable program loaded by multiple users.

[0137] Module M1 is used to prevent non-privileged access instructions in the executable program from accessing illegal memory through hardware patches to the processor in the server operating system.

[0138] like Figure 14 As shown, in another embodiment of the present invention, a first electronic device A is also provided, including the hardware-assisted isolated execution device B for the eBPF program.

[0139] like Figure 15 As shown, the first electronic device A can also be connected to the data acquisition device C and the information display device D through a wired or wireless information transmission scheme. The data acquisition device C is used to acquire the eBPF program, and the information display device D is used to display the program running results obtained by running the present invention.

[0140] The information display device D can process and organize the data output by the first electronic device A based on an information display mechanism to improve the readability of the data. This information display mechanism can be manually preset, for example, visualizing the data output by the first electronic device A. It can present the user with specified key information, such as the program's running status, based on user-defined display parameters and / or attributes. Display parameters could be, for example, the data range to be displayed, and display attributes could be, for example, the font, color, and whether scrolling is enabled. This allows the user to access this information more quickly without having to access secondary pages or scroll through pages, saving user effort. Alternatively, this information display mechanism can be an artificial intelligence (AI) display model, which can learn the user's key information interests based on previous usage habits, such as viewing time, number of clicks, and number of edits, and then automatically present the user with rich and necessary key information.

[0141] In another embodiment, the present invention also proposes a storage medium VIII for storing a computer program of a hardware-assisted isolated execution method for executing the eBPF program. It should be understood that the storage medium in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0142] Figure 16 A schematic block diagram of a second electronic device 1000 that can be used to implement embodiments of the present invention is shown. The second electronic device 1000 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The second electronic device 1000 can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein. The second electronic device 1000 may be the same as or different from the first electronic device A.

[0143] The second electronic device 1000 includes a computing unit I, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory II (ROM) or a computer program loaded from storage medium VIII into random access memory (RAM) III. The RAM III may also store various programs and data required for the operation of the device 1000. The computing unit I, ROM II, and RAM III are interconnected via bus IV. An input / output (I / O) interface V is also connected to bus IV.

[0144] Multiple components in the second electronic device 1000 are connected to I / O interface V, including: input unit VI, such as a keyboard, mouse, etc.; output unit VII, such as various types of displays, speakers, etc.; storage medium VIII, such as a disk, optical disk, etc.; and communication unit IX, such as a network card, modem, wireless transceiver, etc. Communication unit IX allows the second electronic device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0145] The computing unit I can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of computing unit I include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit I performs the various methods and processes described above, such as method steps S1-S2. For example, in some embodiments, the methods can be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage medium VIII. In some embodiments, part or all of the computer program can be loaded and / or installed on device 1000 via ROM II and / or communication unit IX. When the computer program is loaded into RAM III and executed by computing unit I, one or more steps of the methods described above can be performed. Alternatively, in other embodiments, computing unit I can be configured to perform methods by any other suitable means (e.g., by means of firmware).

[0146] Although embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, other modifications can be easily made. Therefore, without departing from the general concept defined by the claims and their equivalents, the present invention is not limited to the specific details and illustrations shown and described herein.

Claims

1. A hardware-assisted isolated execution method for eBPF programs, characterized in that, include: Step 1: Obtain the eBPF program to be executed. After setting all data pages accessed in the eBPF program to non-privileged pages, just-in-time compilation is used to issue all memory access instructions in the eBPF program as non-privileged access instructions to obtain the program to be executed. Step 2: Run the program to be executed in kernel mode EL1 of the server operating system and obtain the running result; and during the running of the program to be executed, the non-memory access instructions in the program to be executed are run at the kernel mode EL1 privilege level, and the memory access instructions in the program to be executed are non-privileged access instructions, which are run at the user mode EL0 non-privileged level. The just-in-time compilation process in step 1 includes: creating a mapping of the eBPF data in the kernel-mode EL1 application of the eBPF program, mapping the eBPF data to an independent address space to obtain eBPF shadow data, and setting the eBPF shadow data as a privileged page. Step 2 includes: the program to be executed directly accesses the eBPF shadow data by calling the helper function provided by the server operating system kernel; By allocating dedicated stack space for each eBPF function in the eBPF program, the accessible and inaccessible data in the eBPF data are decoupled; when the server operating system loads the program to be executed, a dedicated memory region is allocated for the program to be executed as the stack space, and registers are set to point to the stack space in the program code generated by just-in-time compilation.

2. The hardware-assisted isolated execution method for eBPF programs as described in claim 1, characterized in that, When running the program to be executed, a timetable is maintained to record the execution time of each program to be executed. Based on the timetable, it is checked whether the program has taken too long to execute and the program that has timed out is forcibly unloaded. When running the program to be executed, the exception handling function in the server operating system kernel is used to monitor whether an exception occurs. If an exception occurs, the program that has timed out is forcibly unloaded.

3. The hardware-assisted isolated execution method for eBPF programs as described in claim 1, characterized in that, Step 2 includes: running the program to be executed in the kernel mode EL1 of the server operating system, and using non-privileged access isolation hardware to create bidirectional isolation between the user-mode application in the server operating system and the program to be executed, and / or using the non-privileged access isolation hardware to create a multi-domain isolated execution environment for the program to be executed loaded by multiple users.

4. The hardware-assisted isolated execution method for eBPF programs as described in claim 1, characterized in that, Step 1 includes: preventing non-privileged access instructions in the program to be executed from accessing illegal memory through hardware patches on the processor in the server operating system.

5. A hardware-assisted isolated execution device for an eBPF program, characterized in that, include: Module 1 is used to obtain the eBPF program to be executed. After setting all data pages accessed in the eBPF program to non-privileged pages, all memory access instructions in the eBPF program are issued as non-privileged access instructions through just-in-time compilation to obtain the program to be executed. Module 2 is used to run the program to be executed in the kernel mode EL1 of the server operating system and obtain the running result; and during the running of the program to be executed, the non-memory access instructions in the program to be executed are run at the kernel mode EL1 privilege level, and the memory access instructions in the program to be executed are non-privileged access instructions, which are run at the user mode EL0 non-privileged level. The just-in-time compilation process of module 1 is as follows: by creating a mapping of the eBPF data in the kernel-mode EL1 application of the eBPF program, the eBPF data is mapped to an independent address space to obtain eBPF shadow data, and the eBPF shadow data is set as a privileged page. Module 2 is also used for: the program to be executed to directly access the eBPF shadow data by calling the helper function provided by the server operating system kernel; By allocating dedicated stack space to each eBPF function in the eBPF program, the accessible data and inaccessible data in the eBPF data are decoupled. When the server operating system loads the program to be executed, a dedicated memory area is allocated for the program to be executed as the stack space, and registers are set to point to the stack space in the program code generated by just-in-time compilation.

6. The hardware-assisted isolated execution device for the eBPF program as described in claim 5, characterized in that, When running the program to be executed, a timetable is maintained to record the execution time of each program to be executed. Based on the timetable, it is checked whether the program has taken too long to execute and the program that has timed out is forcibly unloaded. When running the program to be executed, the exception handling function in the server operating system kernel is used to monitor whether an exception occurs. If an exception occurs, the program that has timed out is forcibly unloaded. Module 2 is also used to: run the executable program in the kernel mode EL1 of the server operating system, and use the non-privileged access isolation hardware to create bidirectional isolation between the user-mode application in the server operating system and the executable program, and / or use the non-privileged access isolation hardware to create a multi-domain isolated execution environment for the executable program loaded by multiple users. Module 1 is also used to: prevent non-privileged access instructions in the program to be executed from accessing illegal memory through hardware patches on the processor in the server operating system.

7. An electronic device, characterized in that, The hardware-assisted isolated execution device includes the eBPF program as described in claim 5 or 6.

8. A storage medium for storing a computer program for executing a hardware-assisted isolated execution method of the eBPF program according to any one of claims 1-4.

Images