A shared memory virtual network device runtime security control method

Abstract

The application provides a shared memory virtual network device runtime security control method, and belongs to the technical field of computers.The method is to decompose the running path of a shared memory virtual network device driver into three types of key execution semantics, namely a data plane, a control plane and a state machine, and to construct a three-layer runtime closed-loop control system.The three-layer runtime closed-loop control system comprises a driver behavior control layer and a running state constraint layer in a kernel state, and a running state adjustment layer in a user state.The method of the application realizes system-level security authorization of an RTOS-Linux shared memory communication link, and blocks a horizontal attack channel in a mixed criticality system.

Description

Technical Field

[0001] This invention relates to runtime security control methods, and more particularly to a runtime security control method for shared memory virtual network devices, belonging to the field of computer technology. Background Technology

[0002] With the widespread application of hybrid critical systems in industrial control, automotive electronics, and edge computing, static domain virtualization software (such as Jailhouse) is widely adopted. RTOS typically runs in the real-time domain, handling real-time tasks such as sensor data acquisition and control execution, while Linux runs in the functional and administrative domains, handling system management, network communication, and security policy enforcement. Zero-copy, low-latency, and high-throughput data communication between the two is generally achieved through shared-memory virtual network devices (such as ivshmem-net).

[0003] These shared-memory virtual network devices employ a pass-through communication architecture, where data is directly transferred between the RTOS and Linux via shared memory. Although the virtualization software is responsible for establishing the memory mapping relationship, during communication, data read and write operations are directly handled by the hardware, bypassing deep packet inspection, access arbitration, or semantic verification performed by the virtualization software. This also bypasses the traditional physical network device and standard kernel network receiving path. Meanwhile, due to their simplified structure and limited resources, RTOSs typically lack robust information security protection capabilities. Once the RTOS is compromised, attackers can inject illegal, malformed, or malicious data into Linux through the shared-memory communication path, causing Linux protocol stack anomalies, memory corruption, or denial-of-service attacks, forming a side-channel attack path for lateral penetration from within the system.

[0004] Existing network layer firewalls, protocol stack access control mechanisms, and DMA isolation mechanisms can only cover skb-level traffic semantics or physical address access ranges. They cannot constrain driver execution semantic behaviors such as descriptor parsing, register access, interrupt triggering, and device state machine transitions, and therefore lack effective protection against the aforementioned structural attack surfaces formed by shared memory virtual network devices.

[0005] In hybrid critical systems, shared-memory virtual network devices run as kernel drivers on the Linux side. Their basic operating mode is as follows: the Linux driver parses the descriptor structure written by the RTOS side from shared memory via interrupts or polling, performs address dereferencing, status checks, and data reception processing, and then delivers the data to the kernel network protocol stack. Because this communication mode bypasses traditional physical network devices and standard network reception paths, its data reception link typically does not include early filtering and preprocessing mechanisms such as XDP before entering the protocol stack.

[0006] Under this architecture, existing systems mainly adopt the following security protection methods: 1. Network layer protection mechanism Firewalls, intrusion detection, and traffic filtering mechanisms are deployed in the Linux kernel network protocol stack path to implement access control and auditing for skb-level data streams.

[0007] 2. Hardware isolation mechanism By utilizing hardware address translation and access control units such as IOMMU, the range of physical addresses that DMA can access is limited to prevent out-of-bounds memory access.

[0008] 3. Driver source code hardening mechanism By modifying the source code of the virtual network device driver, boundary checks, exception handling, and security verification logic are introduced into critical paths such as descriptor resolution, register access, and state transition.

[0009] In a hybrid critical system that implements high-speed communication between RTOS and Linux based on shared memory virtual network devices, the above solution has the following problems at the Linux-side driver execution path level: (1) Misalignment of protection layers and problem of Linux driver exposure in the front On the Linux side, shared memory virtual network devices are directly parsed by the kernel driver, which then executes the corresponding processing logic. This process occurs before the network protocol stack. Furthermore, because mechanisms like ivshmem-net bypass the traditional physical network reception path, their data reception link lacks pre-filtering mechanisms such as XDP. In this scenario, the Linux kernel driver becomes the first execution entity from the shared memory input of the RTOS. When an attacker controls an RTOS with limited security protection, they can construct illegal, malformed, or malicious descriptors and data content through shared memory. This allows the attack payload to directly enter the Linux driver execution path outside the visible boundary of the protocol stack. Consequently, during descriptor parsing, status checks, or interrupt handling, execution flow anomalies, memory corruption, or protocol stack anomalies can be triggered, forming a high-risk lateral movement attack channel from within the system to Linux.

[0010] (2) Lack of ability to constrain the execution semantics of Linux drivers Hardware isolation mechanisms such as IOMMU can only restrict the range of physical address access. They cannot determine whether the descriptor structure in shared memory is legal, whether the field combination meets the device semantic constraints, or whether the register access order, interrupt triggering conditions, or device state transition process conform to the execution semantics of the virtual network device. In a pass-through architecture, the RTOS side can systematically construct semantic-level abnormal inputs, causing the Linux driver to enter an illegal execution state without violating physical address access constraints. This can trigger execution path disorder, state machine abnormalities, or unpredictable kernel behavior. Such risks cannot be identified and suppressed by existing hardware isolation mechanisms.

[0011] (3) Lack of Linux driver-level runtime adjustment and evolution capabilities While modifying driver source code to introduce protective logic can enhance security to some extent, it is costly to maintain, has a long deployment cycle, and its defense strategies are rigid. It is difficult to adjust and continuously evolve Linux driver execution behavior online without modifying the source code, restarting the system, or compromising zero-copy performance and real-time constraints. Furthermore, with dynamic changes in RTOS-side attack methods and input characteristics, existing solutions struggle to respond promptly to new attack techniques and provide continuous and effective security governance capabilities for Linux-side shared memory driver execution paths.

[0012] In summary, in hybrid critical systems where RTOS security protection capabilities are limited and high-speed direct communication with Linux is established through shared memory virtual network devices, the existing security protection system lacks architectural-level control over the Linux driver execution path and its front-end input boundaries. This allows lateral attack channels to form within the system that can bypass network protocol stack semantic checks and hardware isolation mechanisms, making it difficult to ensure the security and stable operation of the entire platform from the system architecture level. Summary of the Invention

[0013] To address the aforementioned issues, this invention provides a runtime security control method for shared memory virtual network devices, enabling system-level security authorization of RTOS–Linux shared memory communication links and blocking lateral attack channels within hybrid critical systems.

[0014] To achieve the above objectives, the technical solution of the present invention is: a runtime security control method for shared memory virtual network devices, wherein the method decomposes the running path of the shared memory virtual network device driver into three types of key execution semantics: data plane, control plane, and state machine, and constructs a three-layer runtime closed-loop control system; The three-layer runtime closed-loop control system includes a driver behavior control layer and a runtime constraint layer located in the kernel mode, as well as a runtime adjustment layer located in the user mode. The driver behavior control layer is used to intercept and constrain data passed from the RTOS side to the virtual network device driver through shared memory in real time. It uses dynamic kernel injection and function-level instrumentation to implant data plane execution semantic control points, control plane execution semantic control points and state machine execution semantic control points at the key execution path entry of the virtual network device driver to achieve real-time data interception and execution constraints. The runtime constraint layer is connected to the driving behavior control layer to provide a unified control benchmark for the execution behavior of virtual network device drivers. The runtime adjustment layer is connected to the driver behavior control layer to receive abnormal event streams reported from the kernel mode, and, in conjunction with system security policies and historical behavior, generate dynamic control instructions and feed them back to the driver behavior control layer.

[0015] Furthermore, the unified control benchmark includes the following constraint structures: state transition constraint structure, memory space constraint structure, and execution frequency constraint structure.

[0016] Furthermore, the following steps are included: Step 1): Establish function-level driven execution control points After the system starts, runtime control logic is deployed at the critical function execution entry point of the virtual network device driver through a dynamic kernel instrumentation mechanism; Step 2): Execute control mechanism When the driver execution path is triggered, the runtime control logic activates multiple types of runtime constraint structures in parallel within the same execution context, and implements joint control over the driver execution semantics. Step 3): Closed-loop feedback This includes collecting events, analyzing strategies, and issuing rules for the results events generated by the execution control mechanism in step 2).

[0017] Furthermore, in step 1), the control point covers the following set of functions: data surface functions, control surface functions, and state machine functions.

[0018] Furthermore, in step 2), the joint control includes the following mechanisms: data plane consistency control, control plane rate and timing control, and state machine transition control.

[0019] Furthermore, in step 2), the data plane consistency control is the runtime control logic that performs the following control actions when entering the descriptor parsing or data sending path: (1) field binding sampling; (2) space validity verification; (3) queue structure consistency verification; and (4) control execution.

[0020] Furthermore, in step 2), the control plane rate and timing control are the following control actions executed by the runtime control logic when the execution path triggers the Doorbell write or notification send operation: (1) target address verification; (2) payload semantic verification; (3) execution frequency control; (4) exception suppression processing.

[0021] Furthermore, in step 2), the state machine transition control is when the drive execution involves a device state change path, the runtime control logic performs the following control actions: (1) active transition verification; (2) passive synchronization verification.

[0022] Furthermore, in step 3), event collection refers to the kernel-mode control logic continuously reporting control results, abnormal events, and execution statistics to the user-mode control unit; strategy analysis refers to the user-mode control unit analyzing abnormal event sequences and execution behavior patterns to identify potential attack paths or abnormal operating trends; and rule distribution refers to synchronizing updated parameters such as rate limiting thresholds, risk address markers, and illegal migration sets to the kernel-mode runtime constraint structure in real time.

[0023] Furthermore, the data plane execution semantic control points include: vshm_net_desc_data(): The entry point for shared memory address mapping; ivshm_net_xmit(): Data sending entry point; ivshm_net_rx_desc() / ivshm_net_poll(): Data receiving and extraction entry points; Control plane execution semantic control points include: writel(..., &ivshm_regs->doorbell): Doorbell interrupt trigger entry point; ivshm_net_notify_tx() / rx(): Encapsulation entry point for notification logic; The state machine execution semantic control points include: ivshm_net_set_state(): Entry point for writing device state; ivshm_net_state_change(): Entry point for cross-domain state synchronization processing.

[0024] The beneficial effects of the shared memory virtual network device runtime security control method of the present invention are as follows: The method of this invention no longer treats shared memory virtual network devices as passive data channels, but abstracts them as controllable execution objects. It constructs a runtime closed-loop control mechanism in the Linux driver execution path to implement real-time perception, constraint and feedback adjustment of execution behaviors such as descriptor resolution, register access, interrupt triggering and state transition. Thus, without modifying the driver source code or sacrificing zero-copy performance and real-time performance, it achieves system-level security authorization of the RTOS-Linux shared memory communication link and blocks lateral attack channels within hybrid critical systems.

[0025] This invention, for the first time, formalizes the security problem of shared memory virtual network communication as a runtime control problem of Linux device driver execution behavior. It constructs a three-layer closed-loop control system in the kernel, consisting of a "driver behavior management layer—runtime constraint layer—runtime adjustment layer," achieving proactive, structured, and continuous control over shared memory communication-related execution behaviors. This system uses the driver execution path as the control object, the runtime constraint structure as the control benchmark, and the user-space adjustment module as the feedback adjustment mechanism, forming a "perception-control-feedback" runtime closed-loop control loop. This allows security protection to be moved down from the traditional network packet semantic layer and peripheral isolation mechanisms to the device driver execution semantic layer, eliminating the security blind spot created by shared memory pass-through communication from a system architecture perspective.

[0026] Unlike traditional solutions that achieve protection by modifying driver source code or static instrumentation, this invention uses a dynamic kernel instrumentation mechanism (such as eBPF) to implant runtime control logic into the driver execution path, and combines it with a multi-dimensional runtime constraint structure maintained by the kernel (including memory space constraint structure, state transition constraint structure and execution frequency constraint structure) to form a unified control benchmark, thereby achieving: (1) completing the deployment of security control logic without modifying the driver source code, recompiling the kernel, or restarting the system; (2) implementing structured runtime control at the function level, semantic level and path level for driver execution behavior; and (3) supporting online adjustment and continuous evolution of control parameters during system operation.

[0027] This invention moves the security protection boundary forward to the earliest observable point in the shared memory communication link—namely, the execution semantic parsing entry point of the Linux virtual network device driver. It structurally solves the security blind spot problem caused by data bypassing the Hypervisor I / O arbitration layer, virtual switch, and protocol stack pre-filtering mechanisms in shared memory communication. By constructing runtime control points in key driver execution paths such as descriptor parsing, register access, interrupt triggering, and device state transitions, illegal, malformed, or malicious input from the RTOS side is structurally identified, constrained, and blocked before entering the Linux protocol stack, thereby cutting off side-channel attack paths within hybrid critical systems.

[0028] This invention introduces field binding and intra-path consistency verification mechanisms into the driver execution path. Within the same execution context, it performs real-time verification and structural constraints on key fields, access boundaries, and state transition conditions of shared memory descriptors, thereby preventing race-state tampering between the inspection and usage phases. Simultaneously, by combining state transition constraint structures, execution frequency constraint structures, and abnormal path degradation handling mechanisms, it maintains the stable operation of the device state machine and the overall service availability of the system while blocking abnormal behavior. This preserves zero-copy performance characteristics without altering the existing data path structure or introducing additional data copying and context switching. Attached Figure Description

[0029] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0030] Figure 1 This is a system architecture diagram of the method of the present invention; Figure 2 This is a flowchart illustrating the implementation of the method of the present invention. Detailed Implementation

[0031] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0032] Explanation and translation of technical terms Hypervisor: A virtual machine monitor is a virtualization control layer software that runs between the hardware and the operating system. It is responsible for creating, scheduling, and isolating multiple virtual execution environments, and provides resource management capabilities such as interrupt forwarding, exception handling, memory mapping, and device access control.

[0033] Mixed-Criticism System: A mixed-critical system refers to a system that runs multiple software systems or operating system instances with different real-time, security, and deterministic requirements on the same hardware platform. At least one of these is a real-time operating system with strict time constraints, while the remaining systems are used to carry general-purpose or high-throughput non-real-time tasks.

[0034] RTOS: Real-time Operating System, is a software system that can complete task scheduling and event response within a defined time limit. It supports high-priority preemptive scheduling, deterministic interrupt response, and time-constrained guarantees, and is suitable for industrial control, automotive electronics, and safety-critical systems.

[0035] Instrumentation refers to the dynamic insertion of executable logic at specific function entry points, exit points, or event trigger points in the program execution path to achieve the perception, interception, enhancement, or control of runtime behavior without modifying the original program source code or recompiling the target system.

[0036] eBPF: extended Berkeley Packet Filter, is a verifiable bytecode program mechanism that runs in a kernel-controlled execution environment. It supports the dynamic loading and unloading of runtime logic without modifying the kernel source code, and is used to achieve high-performance data processing, event monitoring, and execution path control.

[0037] ivshmem-net: A virtual network device driver based on the Inter-VM Shared Memory mechanism, used to achieve zero-copy, high-throughput, and low-latency data communication between multiple virtual execution environments through shared memory regions.

[0038] Doorbell: The doorbell notification mechanism is a cross-domain notification method that triggers interrupts or event handling processes on the other end by writing to registers or using shared memory signals. It is used to implement asynchronous signal transmission for sending completion, receiving scheduling, or state changes in virtual devices.

[0039] Skb: Socket buffer, is a core data structure in the Linux network subsystem used to encapsulate network packets and their metadata, and is used to transmit and process messages between different layers of the network protocol stack.

[0040] Iptables: A user-space configuration tool for the Linux kernel's network filtering and packet processing framework, used to define network packet filtering, forwarding, modification, and access control rules based on protocol fields, interface attributes, or connection states.

[0041] XDP: eXpress Data Path, a high-speed packet processing framework that runs on the early receive path of network device drivers. It allows filtering, forwarding, modification, or dropping of packets before they enter the kernel protocol stack, achieving extremely low latency and high throughput.

[0042] Netfilter: A network packet processing and access control framework in the Linux kernel.

[0043] NAPI (New API) is a network packet receiving mechanism in the Linux kernel. It combines interrupt triggering with polling to reduce interrupt overhead and steadily improve throughput and real-time performance under high load.

[0044] DMA: Direct Memory Access, is a hardware mechanism that allows peripherals to read and write memory directly without CPU intervention, thereby reducing CPU load and improving data transfer efficiency.

[0045] This invention provides a runtime security control method for shared memory virtual network devices. The problem is clearly identified as a runtime security issue stemming from the lack of structural controllability in driver execution semantics. By constructing a closed-loop control mechanism within the driver execution path, structural constraints and system-level authorization are implemented on device access behavior and data processing flows, thereby establishing a pre-emptive security protection capability against shared memory communication from RTOS on the Linux side. The core technical ideas of this invention include: 1. Principle of Controllable Execution Path By treating the execution behaviors of Linux side drivers, such as descriptor parsing, register access, interrupt triggering, and device state transitions, as constrainable objects, and introducing a pluggable runtime control mechanism within their execution path, real-time constraints are implemented on the semantics of shared memory input and the sequence of device operations, thus structurally blocking the internal bypass attack channel from RTOS to Linux.

[0046] 2. Zero-copy communication path preservation principle Without introducing an intermediate forwarding path, violating the zero-copy semantics of shared memory, or affecting real-time performance and high throughput, security control and behavior authorization are completed within the Linux driver execution path, avoiding sacrificing system real-time performance for security.

[0047] 3. Closed-loop regulation principle during operation By constructing a runtime closed-loop control mechanism of "perception-control-feedback" in the Linux driver execution path, the system can perceive, dynamically constrain, and evolve policies for the execution behavior of virtual network device drivers in real time, thereby achieving continuous security governance capabilities for shared memory communication links without modifying the driver source code or restarting the system.

[0048] Based on the above technical concepts, the main technical aspect of this invention is to dynamically implant perception and control logic into the execution path of Linux virtual network device drivers, imposing deterministic semantic constraints on the execution behavior of the data plane, control plane, and state machine, thereby eliminating kernel-level attack risks without sacrificing zero-copy performance and real-time performance. This method does not rely on intrusive modifications to existing driver source code, nor does it depend on specific hardware-assisted security modules. Instead, it constructs a hot-pluggable and evolvable security control layer in the Linux kernel through a set of standardized dynamic kernel instrumentation mechanisms and runtime constraint mechanisms, making the driver execution path itself a security control boundary. This invention implements control logic implantation and runtime management based on the following infrastructure provided by the Linux kernel: 1. Dynamic kernel instrumentation mechanism By utilizing kernel mechanisms such as kprobe, runtime control logic can be deployed to the key function execution entry point of the target virtual network device driver without restarting the system or recompiling the kernel. This enables data awareness, behavior constraints, and anomaly interception capabilities that cover the driver execution path, achieving continuous monitoring and real-time control of the driver execution process.

[0049] 2. eBPF Map State Storage Mechanism By utilizing kernel-mode key-value pair storage structures to maintain the device's runtime constraint structure, such as the current device state, descriptor access boundaries, Doorbell call frequency counters, and exception instance identifiers, cross-function call state consistency verification and behavior throttling control can be achieved.

[0050] 3. Perf Event Channel Mechanism By utilizing a high-efficiency kernel-user-mode circular buffer channel, abnormal behavior events captured in the driver execution path are reported to the user-mode control unit in real time, and dynamic policy parameter updates issued by the user-mode are received, forming a runtime closed loop of "perception-control-feedback".

[0051] The aforementioned technologies, as standard capabilities of the operating system kernel, provide a solid technical foundation for building a runtime-driven security control system that is zero-intrusive, low-overhead, and capable of continuous evolution. This enables the present invention to move the security protection boundary forward to the earliest observable and most decisive execution semantic layer in the shared memory communication link without compromising the existing communication architecture and performance assumptions.

[0052] The method of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0053] Example 1 Combination Figure 1 As shown, the method of this invention abstracts shared-memory virtual network devices into controllable execution objects and constructs a runtime closed-loop control system around their critical execution paths in the Linux kernel. This system achieves the following control closed loop by inserting dynamically loadable perception and execution control logic into the execution path of the virtual network device driver function, and by combining device runtime constraints and user-mode policy adjustment modules: Shared memory data enters the driver execution path → Runtime instrumentation is triggered at the entry point of critical functions → Consistency checks are performed on descriptors, registers, and state transition semantics → Abnormal execution paths are blocked, replaced, or downgraded → Feedback on device running status and execution results is collected → Runtime control strategies are updated based on the feedback results.

[0054] This invention targets virtual network device drivers (preferably ivshmem-net) based on shared memory mechanisms. It decomposes their execution path into three key execution semantics: data plane, control plane, and state machine. A three-layer runtime closed-loop control system is constructed, with these three layers working together to form a closed-loop security control system for the execution path of shared memory virtual network device drivers on the Linux side. Details are as follows: First layer: Behavior control layer (responsible for real-time interception and constraint enforcement) This layer uses dynamic kernel injection and function-level instrumentation to implant "perception" and "control" logic into the critical execution path entry point of the virtual network device driver without modifying the driver source code or recompiling the kernel.

[0055] (1) Data plane execution semantic control point Establish runtime control points for the data path of the ivshmem-net driver: ivshm_net_desc_data(): The shared memory address mapping entry point, which is the first boundary of the input data; ivshm_net_xmit(): Data sending entry point; ivshm_net_rx_desc() / ivshm_net_poll(): Data receiving and extraction entry points.

[0056] Real-time consistency checks are performed on the descriptor address, length, and queue pointer here. If an out-of-bounds or abnormality is detected, the process is immediately blocked or downgraded.

[0057] (2) Control plane execution semantic control points Establish runtime control points for register access and interrupt triggering paths: writel(..., &ivshm_regs->doorbell): Doorbell interrupt trigger entry point; ivshm_net_notify_tx() / rx(): Encapsulation entry point for notification logic.

[0058] Constraints are imposed here on write frequency, target ID, and trigger timing to prevent interruption storms and denial-of-service attacks.

[0059] (3) State machine execution semantic control points Establish runtime control points for equipment status change paths: ivshm_net_set_state(): Entry point for writing device state; ivshm_net_state_change(): Entry point for cross-domain state synchronization processing.

[0060] Insert illegal transition blocking logic here to prevent driver exceptions caused by state machine malfunctions.

[0061] Second layer: Runtime constraint layer (responsible for providing verification benchmarks) This invention maintains a set of device runtime context constraint structures in the Linux kernel as a unified control benchmark for driver execution behavior. The core of this invention includes the following three types of constraint structures: (1) State transition constraint structure Record the current operating state set of the device (RESET / INIT / READY / RUN) and its legal state transition relationships to implement structured constraints on state update operations and prevent illegal state transitions and state machine mismatch.

[0062] (2) Memory space constraint structure Record the base address, length, virtual queue (vring) layout, and pointer advance rules of shared memory. This information is used to perform boundary consistency checks on address dereferences during descriptor resolution and queue operations, ensuring that memory access behavior is restricted to a legal range.

[0063] (3) Execution frequency constraint structure Record Doorbell write frequency, interrupt trigger interval and NAPI scheduling cycle to identify abnormal execution frequency behavior (such as interrupt storms) and provide constraints for execution path rate limiting and timing control.

[0064] The aforementioned constraint structure provides a continuously evolving execution semantic benchmark and context constraint basis for the runtime closed-loop control system.

[0065] The third layer: the operational adjustment layer (responsible for dynamic adjustment and closed-loop feedback). The user-mode control unit receives the exception event stream reported from the kernel mode (corresponding to...). Figure 1 Event collection in the system, combined with system security policies and historical behavior (corresponding to...) Figure 1 (Strategy analysis in the middle), generating dynamic control instructions (corresponding to) Figure 1 (Rules issued in the system), for example: (1) Limit the Doorbell write rate for specific instances; (2) Mark high-risk memory regions; (3) Block specific illegal state paths; (4) Issue service degradation strategies.

[0066] The above strategies are fed back to the first layer (driving behavior control layer) in real time through a mapping table, thus forming a dynamic closed-loop adjustment mechanism of "perception-control-feedback".

[0067] Example 2 Based on Example 1, combined with Figure 2 The implementation process of the method of the present invention is described in detail. This embodiment takes the virtual network device driver ivshmem-net based on the shared memory mechanism as an example, and includes the following steps: Step 1: Establish function-level drive execution control points After system startup, runtime control logic is deployed at the key function execution entry points of the ivshmem-net driver through a dynamic kernel instrumentation mechanism, forming a proactive awareness and structural control capability over the driver execution path. The control points cover the following set of functions: (1) Data surface functions: ivshm_net_desc_data() (descriptor resolution) ivshm_net_xmit() (data sending) (2) Control surface function: writel() (target is Doorbell register) ivshm_net_notify_tx() / rx() (notification encapsulation) (3) State machine function: ivshm_net_set_state() (state setting) ivshm_net_state_change() (state synchronization) The aforementioned instrumentation points collectively constitute a unified control entry point in the drive execution path, enabling all critical execution behaviors to enter the same runtime control framework.

[0068] Step 2: Implement control mechanisms When a driver execution path is triggered, the runtime control logic activates multiple types of runtime constraint structures in parallel within the same execution context, implementing joint control over the driver execution semantics. This joint control includes the following three parallel sub-mechanisms: (a) Data plane consistency control (memory space constraint structure) When entering a descriptor resolution or data transmission path, the runtime control logic performs the following control actions: (1) Field binding sampling: The atomic reads fields such as addr, len, and flags from the descriptor and generates immutable field binding copies to freeze the semantics of the current execution input, thus avoiding race conditions caused by inconsistencies between the inspection and usage phases.

[0069] (2) Spatial legality verification: Based on the memory space constraint structure, verify whether the address range [addr, addr+len) falls entirely within the legal shared memory range.

[0070] (3) Queue structure consistency check: Based on the vring layout parameters and index advancement rules, verify whether the descriptor index and the circular queue state satisfy the structural consistency constraints.

[0071] (4) Control execution: If all the above checks pass, the pointer that originally pointed to shared memory is redirected to the field-bound copy by modifying the execution context parameters (such as register values), forcing subsequent operations of the driver to be executed based on the field-bound copy; if any check fails, the current execution path is immediately blocked and the exception event is recorded.

[0072] (ii) Control plane rate and timing control (execution frequency constraint structure) When the execution path triggers a Doorbell write or notification send operation, the runtime control logic performs the following control actions: (1) Target address verification: Verify whether the write address belongs to the device's BAR space.

[0073] (2) Load semantic verification: Verify whether the peer_id and vector encoding in the written value meet the protocol semantic constraints.

[0074] (3) Execution frequency control: Based on the counter, time window, and threshold parameters in the execution frequency constraint structure, rate limits and timing adjustments are applied to Doorbell write and notification trigger operations.

[0075] (4) Abnormal suppression treatment: When an interruption storm or abnormal triggering pattern is detected, the current operation is dropped, delayed, or downgraded to suppress denial-of-service attack paths.

[0076] (III) State machine transition control (state transition constraint structure) When driver execution involves a device state change path, the runtime control logic performs the following control actions: (1) Active migration verification: When calling ivshm_net_set_state(new_state), the current state and the transition matrix in the state transition constraint structure are used to check whether old_state→new_state is a valid transition path; if it is invalid, the process is blocked immediately and an exception is reported.

[0077] (2) Passive synchronization verification: In the ivshm_net_state_change() path that handles peer state updates, it checks whether the remote state change satisfies the bidirectional consistency constraint; if it violates the constraint, the local state is frozen and the system enters protection mode.

[0078] The three control mechanisms mentioned above take effect in parallel within the same execution context, satisfying the following structural relationship: (1) Failure of any control dimension will trigger blocking, delay, or degradation processing; (2) Each control dimension shares the same field binding copy and execution context; (3) No additional execution phase is introduced, and the original data path structure is not changed.

[0079] This parallel execution control mechanism ensures that synchronous, multidimensional, and deterministic constraints on the execution semantics of the driver are achieved without sacrificing zero-copy communication performance or the original execution timing of the driver.

[0080] Step 3: Closed-loop feedback (1) Event Acquisition (using the Perf Event Channel Mechanism): The kernel-mode control logic continuously reports control results, abnormal events, and execution statistics to the user-mode control unit.

[0081] (2) Strategy Analysis: The user-mode control unit analyzes abnormal event sequences and execution behavior patterns to identify potential attack paths or abnormal operating trends.

[0082] (3) Issuance of rules: The updated rate limiting threshold, risk address marking, illegal migration set and other parameters are synchronized to the kernel-mode runtime constraint structure in real time.

[0083] (4) Closed-loop operation takes effect: The updated constraint structure is applied in real time to the subsequent driving execution path, enabling continuously evolving runtime safety control capabilities.

[0084] In summary, while maintaining the zero-copy, high-throughput, and low-latency communication characteristics of shared memory virtual network devices, this invention establishes a pre-emptive, structured, and parallel-constrained runtime control capability for shared memory input data and the execution behavior of virtual network device drivers within the Linux kernel, thereby achieving the following technical effects: 1. Move the security protection boundary forward to the semantic parsing stage before the protocol stack; 2. Block internal attack paths formed by malicious input on the RTOS side bypassing the network layer and hardware isolation mechanisms via shared memory communication paths; 3. Achieve continuously adjustable and evolving runtime security governance capabilities without modifying driver source code or restarting the system.

[0085] Furthermore, this invention provides a set of user-mode daemons and pre-compiled kernel-mode runtime control bytecode modules, enabling system integrators or operations personnel to quickly deploy security protection capabilities in existing virtualization platforms and hybrid critical system environments without modifying existing driver source code or rebuilding the kernel image. This method is particularly suitable for the following application scenarios: 1. High-security industrial control and vehicle gateway system In scenarios where the RTOS is responsible for connecting external sensors and actuators and is considered an "untrusted input domain," this invention establishes a pre-security control mechanism in the Linux driver execution path, which can effectively block malformed descriptor attacks, interrupt storm attacks, and state machine disruption attacks from the RTOS side, thereby protecting the Linux kernel and system management domain from lateral penetration risks.

[0086] 2. High-performance edge computing and real-time data exchange system In scenarios where large-scale data transmission must utilize shared memory zero-copy mechanisms, traditional security mechanisms based on iptables, netfilter, or user-space proxy forwarding struggle to meet real-time and throughput requirements. The "internal blocking within the driver execution path" capability provided by this invention enables secure filtering without introducing additional data copying and context switching, making it a feasible solution that balances performance and security.

[0087] During implementation, operations and maintenance personnel do not need to deeply understand the complex internal logic of virtual network device drivers. They only need to load the kernel-mode runtime control module and user-mode policy control component provided by this invention, and the system can automatically identify the target shared memory virtual network device instance and apply the default protection policy. At the same time, it supports dynamic adjustment of rate limiting thresholds, blocking rules, and risk response policies during system operation without restarting the system or interrupting business operations.

[0088] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

Claims

1. A runtime security control method for shared memory virtual network devices, characterized in that, The method decomposes the runtime path of the shared memory virtual network device driver into three key execution semantics: data plane, control plane, and state machine, and constructs a three-layer runtime closed-loop control system. The three-layer runtime closed-loop control system includes a driver behavior control layer and a runtime constraint layer located in the kernel mode, as well as a runtime adjustment layer located in the user mode. The driver behavior control layer is used to intercept and constrain data passed from the RTOS side to the virtual network device driver through shared memory in real time. It uses dynamic kernel injection and function-level instrumentation to implant data plane execution semantic control points, control plane execution semantic control points and state machine execution semantic control points at the key execution path entry of the virtual network device driver to achieve real-time data interception and execution constraints. The runtime constraint layer is connected to the driving behavior control layer to provide a unified control benchmark for the execution behavior of virtual network device drivers. The runtime adjustment layer is connected to the driver behavior control layer to receive abnormal event streams reported from the kernel mode, and, in conjunction with system security policies and historical behavior, generate dynamic control instructions and feed them back to the driver behavior control layer.

2. The method according to claim 1, characterized in that, The unified control benchmark includes the following constraint structures: state transition constraint structure, memory space constraint structure, and execution frequency constraint structure.

3. The method according to claim 1 or 2, characterized in that, Includes the following steps: Step 1): Establish function-level driven execution control points After the system starts, runtime control logic is deployed at the critical function execution entry point of the virtual network device driver through a dynamic kernel instrumentation mechanism; Step 2): Execute control mechanism When the driver execution path is triggered, the runtime control logic activates multiple types of runtime constraint structures in parallel within the same execution context, and implements joint control over the driver execution semantics. Step 3): Closed-loop feedback This includes collecting events, analyzing strategies, and issuing rules for the results events generated by the execution control mechanism in step 2).

4. The method according to claim 3, characterized in that, In step 1), the control point covers the following set of functions: data surface functions, control surface functions, and state machine functions.

5. The method according to claim 3, characterized in that, In step 2), the joint control includes the following mechanisms: data plane consistency control, control plane rate and timing control, and state machine transition control.

6. The method according to claim 5, characterized in that, In step 2), data plane consistency control is the runtime control logic that performs the following control actions when entering the descriptor parsing or data sending path: (1) field binding sampling; (2) space validity verification; (3) queue structure consistency verification; (4) control execution.

7. The method according to claim 5, characterized in that, In step 2), the control plane rate and timing control are the following control actions executed by the runtime control logic when the execution path triggers the Doorbell write or notification send operation: (1) target address verification; (2) payload semantic verification; (3) execution frequency control; (4) exception suppression processing.

8. The method according to claim 5, characterized in that, In step 2), state machine transition control is the runtime control logic that performs the following control actions when the drive execution involves a device state change path: (1) active transition verification; (2) passive synchronization verification.

9. The method according to claim 3, characterized in that, In step 3), event collection refers to the kernel-mode control logic continuously reporting control results, abnormal events, and execution statistics to the user-mode control unit; strategy analysis refers to the user-mode control unit analyzing abnormal event sequences and execution behavior patterns to identify potential attack paths or abnormal operating trends; and rule distribution refers to synchronizing updated parameters such as rate limiting thresholds, risk address markers, and illegal migration sets to the kernel-mode runtime constraint structure in real time.

10. The method according to claim 1, characterized in that: Data plane execution semantic control points include: vshm_net_desc_data(): The entry point for shared memory address mapping; ivshm_net_xmit(): Data sending entry point; ivshm_net_rx_desc() / ivshm_net_poll(): Data receiving and extraction entry points; Control plane execution semantic control points include: writel(..., &ivshm_regs->doorbell): Doorbell interrupt trigger entry point; ivshm_net_notify_tx() / rx(): Encapsulation entry point for notification logic; The state machine execution semantic control points include: ivshm_net_set_state(): Entry point for writing device state; ivshm_net_state_change(): Entry point for cross-domain state synchronization processing.

Images