An eBPF-based inter-kernel indirect control flow transfer dynamic verification method

Abstract

The application discloses a kind of inter-kernel indirect control flow transfer dynamic verification method based on eBPF, by locating the eBPF attachment point of indirect call instruction and dynamically attaching verification program, the composite key of source address and target address is generated, and the legality of control flow is verified in the pre-built BPF hash table;At the same time, differentiated strategy is adopted to adapt to three types of addressing mode of register, immediate number and memory indirect.Based on eBPF technology, the EV program can be dynamically loaded into the running kernel as needed at runtime, which can perfectly adapt to the characteristics of modern kernel dynamic expansion;All capabilities are built on the general software mechanism of Linux kernel, and do not depend on any hardware extension;While providing strong security defense, it realizes extremely low runtime overhead.Benefiting from the innovative hybrid verification strategy and efficient CFG storage scheme, it can effectively prevent real-world control flow hijacking attacks with extremely low performance loss.

Description

Technical Field

[0001] This invention relates to a dynamic verification method for kernel indirect control flow transfer based on eBPF, belonging to the field of computer system security technology. Background Technology

[0002] Operating system kernels commonly employ indirect calling mechanisms such as function pointers and callback tables to improve modularity and scalability, but this also introduces the risk of control flow hijacking: attackers can exploit heap overflow, use-after-free, or out-of-bounds write vulnerabilities to tamper with pointers, thereby directing the execution flow to malicious code or existing privileged segments, bypassing protections such as SMEP and KASLR to obtain the highest privileges.

[0003] Traditional defense strategies mainly include three categories:

[0004] Static control flow integrity (CFI) involves inserting a whitelist check for each indirect branch during compilation. Once the kernel is upgraded, hot patched, or modules are dynamically loaded, it must be recompiled and restarted, resulting in extremely high maintenance costs. Furthermore, inline code significantly increases binary size, doubles the pressure on instruction cache and branch prediction, and is difficult for production environments to withstand.

[0005] Hardware extension solutions—such as IntelCET's IBT mechanism—rely on new instruction sets and platform characteristics, making them unusable on older CPUs, ARM, and other non-x86 architectures, resulting in poor portability. Furthermore, the hardware only provides coarse-grained checks, making it difficult to combine with kernel semantics to implement fine-grained strategies.

[0006] Traditional KProbe-based eBPF solutions, while capable of injecting probe points at runtime, suffer from high overhead in context switching and helper function calls, typically limiting their use to sampling and auditing. Furthermore, KProbes can only attach to probeable instructions, not directly to the indirect call instructions themselves, creating inherent gaps in control flow tracing. Additionally, the sheer number and uneven distribution of indirect call points in the kernel mean that simple full injection would result in unacceptable performance fluctuations, making it unsuitable for online scenarios.

[0007] More importantly, traditional eBPF solutions do not differentiate the verification complexity of register, memory, and immediate addressing modes, uniformly adopting the 'source-target address pair full match' logic. Memory indirect addressing requires an additional call to bpf_probe_read to read the memory value, and the verification time is more than 3 times that of register addressing. Such high-overhead operations reduce overall performance and cannot meet the low-latency requirements of production environments.

[0008] In summary, existing technologies cannot perform real-time, fine-grained control flow verification on all indirect kernel call points without rebooting, relying on specific hardware, or significantly impacting performance. Therefore, there is an urgent need for a hot-swappable, cross-platform, and low-overhead dynamic protection solution to fill this gap. Summary of the Invention

[0009] This invention provides a dynamic verification method for kernel indirect control flow transfer based on eBPF to solve the problems existing in the prior art.

[0010] The technical solutions adopted in this invention are as follows:

[0011] A dynamic verification method for kernel indirect control flow transfer based on eBPF includes the following steps:

[0012] 1) Locate the actual virtual address of each indirect call instruction in the kernel binary, and determine the executable instruction preceding each indirect call instruction as the eBPF attachment point exclusive to that indirect call instruction; the preceding executable instruction includes the sequential preceding instruction and all instructions that directly jump to that indirect call instruction;

[0013] 2) The pre-set eBPF verification program, which is used to capture the source address and target address of the corresponding indirect call instruction at runtime, is dynamically attached to the eBPF attachment point dedicated to each indirect call instruction, so that the corresponding eBPF verification program is triggered when the kernel execution flow reaches any eBPF attachment point.

[0014] 3) The triggered eBPF verification program immediately obtains the source address and target address of this indirect call instruction, concatenates the lower 32 bits of the source address and the lower 32 bits of the target address to form a 64-bit composite key, and performs a hash lookup in a single BPF hash table using the composite key; the single BPF hash table is formed according to a pre-built control flow diagram.

[0015] If the result indicates that the query is illegal, an error is immediately returned to terminate the execution of the kernel function containing the indirect call instruction.

[0016] If the instruction is valid, the indirect call instruction is allowed to continue execution.

[0017] Furthermore, the eBPF verification program attaches itself by setting a hook trigger mechanism at the instruction immediately preceding each indirect call instruction. Specifically, it first uses a static analysis tool based on LLVM-IR to locate the indirect call point. Using the source code file name and offset provided by CFG, the tool gdb determines the approximate range of the indirect call instruction in the binary virtual address space based on the symbol + offset. By searching within this range, the specific indirect call instruction and its actual location in the virtual address space are located. Then, based on this location, the corresponding base address function symbol name is determined, and combined with the relative offset, the address information is represented in the format "function_name + offset" as the basis for eBPF program attachment and location. By setting a hook trigger mechanism at the instruction immediately preceding each indirect call instruction, dynamic program injection is achieved.

[0018] Furthermore, the 64-bit composite key is formed by directly concatenating the lower 32 bits of the source address and the lower 32 bits of the destination address, and a single BPF hash table uses this composite key as its unique key value.

[0019] Furthermore, the validity of a lookup result in a single BPF hash table is represented by a single-byte status value, with a status value of 0x01 indicating validity and a status value of 0x00 indicating invalidity.

[0020] Furthermore, for register-addressed indirect call instructions, the eBPF verifier reads the target address only from the corresponding register and performs validity verification only on the target address;

[0021] For indirect call instructions with immediate addressing, the eBPF verifier maintains an LRU cache with a capacity of 32. When the cache is full, the least recently used verification result is evicted to accelerate repeated verification of the same source-target pair.

[0022] For indirect call instructions with memory indirect addressing, the eBPF verifier reads the target address from memory using the bpf_probe_read helper function and uses it as the target address to perform strict matching verification on the source-target address pair.

[0023] Furthermore, a single BPF hash table is stored in the kernel address space. Taking advantage of the fixed high 32 bits of the x86-64 architecture kernel address space, only the low 32 bits of the source and destination addresses are saved to achieve compressed storage. The low 32 bits of the code segment within the same kernel image are not overloaded, so the concatenated 64-bit composite key value is unique.

[0024] The key-value structure of the single BPF hash table perfectly matches the 64-bit composite key rule—the key is 8 bytes (64 bits), corresponding to the concatenation result of 'lower 32 bits of source address + lower 32 bits of destination address'; the value is 1 byte, corresponding to the validity status value (0x01 valid / 0x00 invalid), ensuring that the composite key can be directly used for hash lookup.

[0025] The present invention has the following beneficial effects:

[0026] (1) Based on eBPF technology, its EV (eBPF Verification) program can be dynamically loaded into the running kernel on demand at runtime, which can perfectly adapt to the dynamic expansion characteristics of modern kernels.

[0027] (2) All capabilities are built on the general software mechanisms of the Linux kernel and do not depend on any hardware extensions.

[0028] (3) While providing strong security defense, it achieves extremely low runtime overhead. Thanks to the innovative hybrid verification strategy and efficient CFG (kernel control flow graph) storage scheme, it can effectively defend against real-world control flow hijacking attacks with extremely low performance loss.

[0029] (4) Through the full coverage scheme of “indirect call to preceding instructions”, both sequential execution and jump convergence paths are included in the monitoring; combined with the verification strategy customized according to the addressing mode, register, memory and immediate call scenarios can be distinguished to achieve fine-grained inspection at the instruction level and eliminate “missed detection” blind spots.

[0030] (5) The verification action is compiled into native eBPF bytecode, resides in kernel mode, and has no user-kernel mode round trip; the composite key is determined by hashing once, and with optional strategies such as LRU caching and target aggregation, the administrator can flexibly switch on or off or reduce the number of monitoring points according to the actual load, and the overall system response remains smooth. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the process of the present invention. Figure 1 In the target address capture, the three branches correspond to register addressing, immediate addressing, and memory indirect addressing, respectively.

[0032] Figure 2 For EV execution time cumulative curve; Figure 2 In the graph, the horizontal axis represents EV execution time (nanoseconds), and the vertical axis represents the cumulative percentage (%). Detailed Implementation

[0033] The present invention will now be further described.

[0034] This invention provides a dynamic verification method for kernel indirect control flow transfer based on eBPF, comprising:

[0035] The actual virtual address of each indirect call instruction is located in the kernel binary, and the executable instruction preceding each indirect call instruction is determined as the eBPF attachment point exclusive to that indirect call instruction; the preceding executable instruction includes the sequential preceding instruction and all instructions that directly jump to that indirect call instruction;

[0036] The pre-built eBPF verification program, which is used to capture the source and target addresses of the corresponding indirect call instructions at runtime, is dynamically attached to the dedicated eBPF attachment point of each indirect call instruction, so that the corresponding eBPF verification program is triggered when the kernel execution flow reaches any eBPF attachment point.

[0037] The triggered eBPF verification procedure immediately obtains the source address and target address of this indirect call instruction, concatenates the lower 32 bits of the source address and the lower 32 bits of the target address to form a 64-bit composite key, and performs a hash lookup in a single BPF hash table using the composite key.

[0038] If the result indicates an invalid instruction, an error is immediately returned to terminate the execution of the kernel function containing the indirect call instruction; if the result indicates a valid instruction, the indirect call instruction is allowed to continue execution.

[0039] The present invention will now be described in further detail.

[0040] The operating environment for this invention must meet the following conditions:

[0041] Software environment: Linux kernel version 5.4 or above; Hardware environment: x86-64 architecture server.

[0042] By using static analysis tools (such as IDA Pro; using IDA Pro 7.7 to load the vmlinux file, then executing the menu Edit → Plugins → CFG Analysis to export valid address pairs to addr_pairs.csv; subsequently, using bpftool to batch write the address pairs to a hash table), the kernel binary file is traversed to pre-build valid kernel control flow graphs (CFGs) and store them in a single BPF hash table. This leverages the characteristic that the high 32 bits of the x86-64 architecture kernel address space are fixed (e.g., always `0xFFFF8880`), saving only the low 32 bits of the source and destination addresses to achieve storage compression.

[0043] Step 1: Locate the address of the indirect call instruction and determine the eBPF attachment point.

[0044] 1) Indirect call instruction address location:

[0045] First, use the GDB tool to read the symbol table of the kernel binary file (such as `vmlinux`). Then, determine the approximate address range of the indirect call point by "function symbol + offset" (for example, the symbol address of the function sys_open is `0xffffffff81234000`, and combined with static code analysis, determine that its indirect call point is concentrated in the offset range of `0x10-0x30`).

[0046] Then, the `objdump -d` tool is used to scan the binary code within this address range to identify indirect call instructions characterized by `jmp*reg` (register addressing), `jmp*mem` (memory indirect addressing), and `call*imm` (immediate addressing), and finally determine the actual virtual address of each instruction at runtime (such as `0xffffffff81234512`).

[0047] 2) Determination of eBPF attachment points:

[0048] For the two types of preceding instructions, namely "the instruction preceding the preceding instruction" and "the instruction that jumps directly to the indirect call," they are handled separately:

[0049] If the indirect call instruction is executed sequentially (e.g., `mov%rdi,%rax` followed by `jmp*%rax`): the instruction sequence is directly parsed using `objdump`, and the address of the previous sequential instruction (`mov%rdi,%rax`) (e.g., `0xffffffff81234510`) is used as the attachment point;

[0050] If a direct jump instruction points to an indirect call (e.g., `jmp0xffffffff81234512`): Use a global code analysis tool (e.g., `radare2`) to traverse the kernel binary, find all jump instructions that point to this indirect call instruction, and use the address of the jump instruction (e.g., `0xffffffff81236780`) as the attachment point to ensure there are no monitoring gaps.

[0051] Step 2: Dynamically attach eBPF verification procedure.

[0052] 1) eBPF verification procedure preparation:

[0053] The pre-built eBPF verification program is written in C and compiled into BPF bytecode by Clang. Its core function is to "capture the source address and the destination address"—see attached program logic. Figure 1 The "address capture" step.

[0054] Source address: The attachment point address is obtained through the `bpf_get_current_pc()` function, and then combined with the pre-stored "attachment point-indirect call instruction address" mapping table to deduce the actual address of the indirect call instruction (i.e., the source address).

[0055] Target address: Read according to the addressing mode of the instruction.

[0056] 2) Dynamic attachment process:

[0057] Attachment is implemented using the "KProbe mechanism": The `bpf_attach_kprobe()` function is called via the BCC tool to allocate a unique KProbe instance (such as `kp_sys_open_indir`) for each eBPF attachment point, and a trigger condition is set—when the kernel execution flow reaches the attachment point address, the corresponding eBPF verification program is automatically triggered. For example, after attaching the eBPF program for the `0xffffffff81234510` attachment point using KProbe, the kernel will immediately enter the verification logic when it executes to that address.

[0058] Step 3: Real-time verification and control flow processing.

[0059] 1) After the eBPF verification procedure is triggered, a 64-bit composite key is generated according to the following logic:

[0060] Source address: Obtain the address of the indirect call instruction (e.g., `0xffffffff81234512`) from the "Attachment Point-Indirect Call Instruction Address" mapping table, and extract its lower 32 bits (`0x81234512`).

[0061] Target address: After reading according to the addressing mode (e.g., register addressing reads `0xffffffff81456789` from `%rax`), extract its lower 32 bits (`0x81456789`).

[0062] Composite key: The source address lower 32 bits (high bits) + destination address lower 32 bits (low bits) are directly concatenated to obtain 0x8123451281456789 (64 bits), which serves as the unique key value for hash lookup; the lower 32 bits of the code segment within the same kernel image are not overloaded, therefore this 64-bit composite key value is unique.

[0063] 2) Hash lookup and validity determination:

[0064] Call the `bpf_map_lookup_elem()` function to perform a lookup in a pre-built single BPF hash table with a 64-bit composite key:

[0065] If the 1-byte status value is `0x01` (valid): execute `bpf_return()`, allowing the kernel execution stream to continue executing indirect call instructions;

[0066] If the status value is found to be `0x00` (illegal): immediately call `bpf_send_signal(SIGKILL)` to send an error signal, terminate the kernel function containing this indirect call (such as `sys_open`), and output the alarm log (including source address, destination address, and triggering process PID) through `bpf_trace_printk()` to block control flow hijacking.

[0067] For the three addressing modes of indirect call instructions, the eBPF verification program adopts customized logic, as specifically implemented as follows:

[0068] Addressing methods Implementation steps Register addressing 1. Read the value of the target register (e.g., %rax) using the bpf_get_current_regs() function and use it directly as the target address; 2. Generate only a composite key of "lower 32 bits of source address + lower 32 bits of target address", skip the source address correlation check, and only verify whether the target address is in a valid CFG, thus achieving lightweight verification. Immediate number addressing 1. Read the immediate value in the instruction (such as 0x12345678 in call*0x12345678) as the target address; 2. Maintain an LRU cache with a capacity of 32 in kernel mode (implemented using a BPF array), with the cache indexed by a composite key and the status value as the content; 3. During verification, prioritize checking the cache: if a hit occurs, return the result directly; if a miss occurs, perform a hash lookup and update the cache, evicting the least used entry (such as an entry that has not been accessed for more than 10 seconds). Memory indirect addressing 1. Call the helper function bpf_probe_read() to read 4 / 8 bytes of value from the memory address specified by the instruction (e.g., 0x80(%rbp)) as the target address (this function has passed kernel security audit to prevent out-of-bounds access); 2. After generating the composite key, not only is the legality of the target address verified, but also whether "transfer from the source address to the target address is allowed" (e.g., prohibiting sys_read from transferring to sys_execve), and perform strict matching.

[0069] Implementation effect verification:

[0070] To verify the security and performance of the solution, tests were conducted in the above environment:

[0071] To test whether the monitoring mechanism of this method can capture illegal jumps in real time and successfully block them, instead of directly exploiting real vulnerabilities that could cause system crashes, a safer and more controllable simulated attack method is adopted, namely, simulating the tampering of the control flow target address through an injected eBPF program.

[0072] (1) Security protection effectiveness (corresponding to Table 1: Evaluation of the effectiveness of real vulnerability attack and defense);

[0073] Table 1: Evaluation of Attack and Defense Effectiveness Against Real-World Vulnerabilities

[0074] CVE-ID type Location (file path) Hijacking point (function name) Validity CVE-2022-0185NIST(2022a) Heap overflow linux-5.11 / fs / fs_context.c:98 vfs_parse_fs_param √ CVE-2022-25636NIST(2022b) Heap overflow linux-5.4 / net / netfilter / nf_tables_offload.c:90 nft_flow_rule_create √ CVE-2023-2598NIST(2023a) Out-of-bounds write linux-6.3 / net / ipv4 / af_inet.c:1005 inet_ioctl √ CVE-2017-8890NIST(2017b) Double release linux-4.10.15 / source / kernel / rcu / rcu.h:106 _rcu_reclaim √ CVE-2018-5333NIST(2018) Null pointer dereferencing linux-4.14.13 / net / rds / rdma.c rds_cmsg_send √ CVE-2023-6546NIST(2023b) Use after release linux-4.13 / drivers / tty / n_gsm.c:811 gsm_send √ CVE-2017-6074NIST(2017a) Use after release linux-4.9.11 / net / dccp / input.c dccp_rcv_state_process √ CVE-2013-2094NIST(2013) Integer overflow linux-3.8.9 / kernel / events / core.c perf_event_open √

[0075] Eight real kernel vulnerabilities were selected from the publicly available CVE vulnerability database (based on public POCs, including heap overflow CVE-2022-0185, out-of-bounds write CVE-2023-2598, use-and-release CVE-2023-6546, etc.) to simulate a control flow hijacking attack (tampering with the target address indirectly called to malicious code):

[0076] The experimental results are shown in Table 1. All simulated control flow hijacking attacks were successfully detected by the monitoring mechanism of this method. Specifically, this is reflected in the following: (1) Each attack attempt triggered the correct security alarm, proving the comprehensive coverage capability of the monitoring mechanism; (2) No attack achieved its intended malicious goal, proving the effectiveness of this method.

[0077] (2) Performance overhead effect;

[0078] Micro-bench tests (Table 2: LMbench overhead) were conducted to test three differentiation strategies and a hybrid strategy. The results show:

[0079] The average performance overhead of the hybrid strategy is only 10.14% (far lower than the 30%+ of the traditional static CFI), with the register addressing strategy having the lowest overhead (4.51%) and the memory indirect addressing strategy having the highest overhead (27.89%), which is in line with the design of "optimizing overhead on demand".

[0080] Table 2: Cost of each strategy in the LMbench test suite

[0081] Test Suite Native (ms) Fine (%) Lightweight (%) Cache (%) Hybrid (%) Nullcall 0.0410 4.63 1.13 3.66 2.19 NullI / O 0.0575 61.29 10.00 33.14 21.68 Stat 0.2219 38.65 6.89 12.24 10.11 siginst 0.0729 1.34 0.09 1.09 0.42 sighndl 0.4610 2.17 0.01 0.98 0.68 Forkproc 47.8807 11.79 2.72 9.07 6.67 Execproc 135.0256 16.73 3.56 11.11 8.14 Shproc 317.2941 14.45 2.82 8.07 7.15 100fdselct 0.4613 1.69 0.62 1.38 0.91 UDP 3.0118 73.84 10.40 29.16 23.97 TCP / IP 3.6998 80.19 11.41 44.12 29.48 average value – 27.89 4.51 14.00 10.14

[0082] As shown in Table 2, from a pure performance perspective, the lightweight strategy has the lowest overhead, followed by the caching strategy and the hybrid strategy, while the fine-grained strategy has the highest overhead. The hybrid strategy has an overall average overhead of 10.14%, achieving the best balance between security and performance.

[0083] By measuring the latency of each verification procedure, the root cause of the aforementioned performance issues was revealed. Figure 2 The cumulative execution time curve for EV shows the distribution of execution overhead for all triggered verification programs under four different verification strategies.

[0084] Because indirect calls in the kernel exhibit strong temporal locality, recent jump pairs are frequently reused, demonstrating competitive performance and significantly improving verification efficiency through caching strategies. Under the hybrid strategy, the average execution time of each verification procedure is only 0.3 nanoseconds, with the vast majority completed well below 0.001 milliseconds, far less than the 0.0425 milliseconds required for a simple system call. From a security and performance tradeoff perspective, the hybrid strategy achieves the optimal balance between security guarantees and runtime efficiency, and also demonstrates that inserting verification checks before indirect control flow transfers does not significantly impact the performance of real-world applications.

[0085] Macro benchmark tests (Table 3: SPECCPU2006 overhead) running 12 computationally intensive applications (such as gcc compilation and bzip2 compression) in Table 3 showed an average performance overhead of 0.58% for the dynamic detection method. This data indicates that the dynamic detection process is almost imperceptible to users, resulting in minimal load on the kernel and negligible performance impact. For traditional computationally intensive applications, such as gcc compilation and bzip2 compression, the introduced overhead is typically below 0.2%. For workloads involving numerous simulations and complex data structures with deep call stacks, such as hmmer and libquantum, indirect calls are more frequent, increasing the number of verifications and thus the overhead. Nevertheless, such runtime overhead is acceptable for modern operating systems, making this method a viable candidate for continuous and practical deployment of kernel control flow protection. These results demonstrate that the present invention provides robust security protection while having a negligible impact on the performance of practical applications, fully meeting the requirements for production environment deployment.

[0086] Table 3 compares the additional overhead of enabling protection mechanisms in the SPECCPU2006 test suite.

[0087] Test Suite Fine-CFI This method 400.perlbench -1.67% 0.617% 401.bzip2 4.13% 0.145% 403.gcc 3.11% 0.245% 429.mcf -0.93% 0.340% 445.godmk -3.01% 0.098% 456.hmmer 2.72% 2.068% 458.sjeng 12.56% 0.114% 462.libquantum -1.13% 4.069% 464.h264ref 4.62% -0.386% 471.omnetpp -1.35% 1.166% 473.astar -5.54% 0.128% 483.xalancbmk 7.12% 0.928% average value 1.70% 0.580%

[0088] The above description is only a preferred embodiment of the present invention. It should be noted that those skilled in the art can make several improvements without departing from the principle of the present invention, and these improvements should also be considered within the scope of protection of the present invention.

Claims

1. A dynamic verification method for kernel indirect control flow transfer based on eBPF, characterized in that: Includes the following steps: 1) Locate the actual virtual address of each indirect call instruction in the kernel binary, and determine the address of the executable instruction preceding each indirect call instruction as the eBPF attachment point exclusive to that indirect call instruction; the preceding executable instruction includes the sequential preceding instruction and all instructions that directly jump to that indirect call instruction; 2) The pre-set eBPF verification program, which is used to capture the source address and target address of the corresponding indirect call instruction at runtime, is dynamically attached to the eBPF attachment point dedicated to each indirect call instruction, so that the corresponding eBPF verification program is triggered when the kernel execution flow reaches any eBPF attachment point. 3) The triggered eBPF verification program immediately obtains the source address and target address of this indirect call instruction, concatenates the lower 32 bits of the source address and the lower 32 bits of the target address to form a 64-bit composite key, and performs a hash lookup in a single BPF hash table formed according to the pre-built kernel control flow chart using this composite key. If the result indicates that the query is illegal, an error is immediately returned to terminate the execution of the kernel function containing the indirect call instruction. If the instruction is valid, then the execution of this indirect call instruction is permitted to continue; The source address is the actual virtual address of the indirect call instruction itself; The target address is the entry address of the function to which the indirect call instruction will jump or call.

2. The kernel indirect control flow transfer dynamic verification method based on eBPF as described in claim 1, characterized in that: The eBPF verification program attaches itself by setting a hook trigger mechanism at the address of the instruction immediately preceding each indirect call instruction.

3. The dynamic verification method for kernel indirect control flow transfer based on eBPF as described in claim 1, characterized in that: The 64-bit composite key is formed by directly concatenating the lower 32 bits of the source address and the lower 32 bits of the destination address, and each BPF hash table uses this composite key as its unique key value.

4. The dynamic verification method for kernel indirect control flow transfer based on eBPF as described in claim 1, characterized in that: The validity of a lookup result in a single BPF hash table is represented by a single-byte status value: 0x01 indicates a valid result, and 0x00 indicates an invalid result.

5. The kernel indirect control flow transfer dynamic verification method based on eBPF as described in claim 1, characterized in that: For register-addressed indirect call instructions, the eBPF verifier reads the target address only from the corresponding register and performs validity verification only on the target address; For indirect call instructions with immediate addressing, the eBPF verifier maintains an LRU cache with a capacity of 32. When the cache is full, the least recently used verification result is evicted to accelerate repeated verification of the same source-target pair. For indirect call instructions with memory indirect addressing, the eBPF verifier reads the target address from memory using the bpf_probe_read helper function and performs a matching verification on the source-target address pair.

6. The dynamic verification method for kernel indirect control flow transfer based on eBPF as described in claim 1, characterized in that: A single BPF hash table is stored in the kernel address space. Taking advantage of the fact that the high 32 bits of the x86-64 architecture kernel address space are fixed, only the low 32 bits of the source and destination addresses are saved to achieve compressed storage.

Images