Network card firmware security access method based on dynamic instruction mapping and transactional buffering

Abstract

The application discloses a kind of based on dynamic instruction mapping and transactional buffer's network card firmware security access method.This method in session initialization stage, driver and application are based on the random seed generated by negotiation, construct only this session effective instruction operation code mapping table and data structure offset rule, realize the dynamization of communication protocol feature Confusion.In processing write request, driver temporarily stores data, reads current hardware snapshot to carry out semantic level virtual assembly and logic conflict prediction, intercepts dangerous operation although signature is legal but configuration logic is mutually exclusive.Only in pre-checking passes through and receives the commit instruction, driver calculates the difference bit stream of shadow buffer and hardware data, locks bus and executes atomicity increment synchronization.The application is effectively resisted to reverse analysis and replay attack by three mechanisms of protocol dynamic transformation, logic conflict immunity and differential atomic commitment, and simultaneously eliminates firmware damage caused by configuration error or abnormal interruption.

Description

Technical Field

[0001] This invention relates to the field of computer systems and network technology, specifically to a method for establishing a secure communication channel between the operating system kernel layer and the user layer. In particular, it relates to a method combining dynamic protocol obfuscation technology and a two-phase commit transaction mechanism to ensure the security of network interface card (NIC) firmware updates and configuration access. Background Technology

[0002] In modern computer operating systems, a core security principle is the strict separation of user space and kernel space. User space is the restricted environment in which applications run, while kernel space has direct and unrestricted access to all hardware resources. This separation aims to protect the operating system from malicious or erroneous software behavior, ensuring system stability and security. As a critical hardware device, the Network Interface Controller (NIC) should have its internal storage read / write operations confined to kernel space and performed by a dedicated device driver.

[0003] Network interface card (NIC) firmware is not merely the low-level code required to initialize a device; it directly impacts the device's performance and feature set, and is a crucial carrier for applying security patches and fixing vulnerabilities. Therefore, updating and modifying firmware is an important but high-risk operation. Traditional firmware updates are typically performed using specialized tools provided by device manufacturers that require administrator privileges, such as Intel's nvmupdate tool or command-line programs like ethtool on Linux. These tools are designed for system maintenance and usually require manual operation, sometimes even necessitating a system reboot for the update to take effect.

[0004] However, with technological advancements, new demands have emerged, such as transforming general-purpose network interface cards (NICs) into dedicated devices by writing specific data (e.g., license keys, device unique identifiers, or customized configurations). This requirement necessitates that a regular user-space application be able to interact with the NIC driver and write data to specific free areas of its internal storage. Existing technological architectures do not provide a standardized, secure channel to meet such demands. Directly exposing the firmware read / write functions within the kernel driver to user-space applications is extremely dangerous, as it would compromise the core security model of the operating system.

[0005] Insecure firmware modifications can have serious consequences. The firmware layer is the highest-level target for attackers; once breached, they can bypass all operating system-level security measures. Malicious firmware can cause permanent device damage, implant persistent malware that is difficult to detect and remove, steal sensitive data, or turn the device into a springboard for cyberattacks. Furthermore, insecure update processes are vulnerable to man-in-the-middle attacks (tampering during firmware transfer) or downgrade attacks (forced installation onto older firmware versions with known vulnerabilities). Summary of the Invention

[0006] The technical problem to be solved by this invention is: to address the issues that existing network card driver interfaces are susceptible to static reverse analysis attacks, lack atomicity guarantees for direct write operations, and lack of a predictive mechanism for firmware configuration logic conflicts, which can easily lead to device malfunctions. This invention provides a secure access method for network card firmware based on dynamic instruction mapping and transactional buffering.

[0007] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is: a network interface card firmware secure access method based on dynamic instruction mapping and transactional buffering, comprising the following steps: S1 Session Initialization and Protocol Negotiation: The user space application initiates a connection request to the device driver; the device driver generates a random seed and returns it to the user space application; based on the random seed and a preset algorithm, both parties synchronously generate a command opcode mapping table and data structure offset rules specific to this session. S2 Dynamic Command Encapsulation and Transmission: The user-space application converts the access intent into a valid opcode for the current session based on the negotiated command opcode mapping table, and fills the data to be written and the digital signature into a specific offset position in the data packet according to the data structure offset rules, thus constructing a request data packet that conforms to the characteristics of the current session; after encapsulation, the application sends the request data packet to the device driver through the input / output control interface; S3 Mapping Resolution and Validity Verification: After receiving the request data packet, the device driver performs reverse resolution based on the mapping table and offset rules generated in step S1. If the resolved opcode or data layout does not conform to the characteristics of the current session, the session is terminated. If the opcode and format verification pass, the driver further resolves the target address, data length, and firmware payload. At this point, the driver enters the transaction preprocessing stage. S4 Shadow Buffer Allocation and Data Temporary Storage: For a successfully parsed write request, the device driver does not directly operate the hardware, but instead requests a kernel-level buffer storage area (i.e., the shadow buffer), temporarily stores the data to be written in the buffer storage area, and marks the operation as "pending submission". S5 Semantic-level Virtual Assembly and Logical Conflict Prediction: The device driver reads the current hardware registers and non-volatile memory area state of the network card to generate a snapshot. In memory, the shadow buffer data is virtually assembled with the hardware snapshot to generate the expected hardware state map. Then, the map is compared with the preset logical constraint topology table. If a state conflict is found or the digital signature verification fails, the transaction is circuit-broken and the shadow buffer is destroyed. If the verification passes, the session is locked and awaits submission. Semantic-level virtual assembly and logical conflict prediction specifically include: the device driver reads the current hardware registers and non-volatile memory state of the network card to generate a hardware snapshot; the driver extracts the configuration bit information in the shadow buffer and applies it to the hardware snapshot through bitwise operations to simulate the register state after writing; the driver traverses the logical constraint topology table to check whether there are situations such as simultaneous enabling of mutex function bits, out-of-bounds electrical parameter configuration, or address space access violations in the simulated state; if any of the above conflicts are detected, or digital signature verification fails, the driver immediately destroys the shadow buffer and returns an error code; if there are no conflicts and digital signature verification passes, the session is locked and awaits submission; S6 Atomic Commit and Differential Bitstream Mapping: The user-space application sends a commit confirmation command; after receiving the command, the device driver calculates the differential bitstream between the shadow buffer and the actual data stored in the network interface card, locks the hardware bus, and only synchronizes the changed differential data blocks to the network interface card through direct memory access (DMA) to achieve atomic commit of the operation; S7 Session Destruction and State Cleanup: After the hardware write is complete, the device driver immediately releases the kernel-level buffer storage area, destroys the instruction opcode mapping table and random seed of this session, and invalidates the current communication protocol features.

[0008] As a preferred embodiment, the algorithm for generating the instruction opcode mapping table uses a linear congruential generator or a hash derivation function, with a random seed as the initial value, to generate a pseudo-random number sequence, and then establishes a dynamic one-to-one mapping relationship between the sequence and a preset basic command set.

[0009] As a preferred embodiment, the data structure offset rule includes padding the header or tail of the data packet with redundant data of random length, so that the starting address of the payload data dynamically changes in different sessions.

[0010] As a preferred embodiment, the differential bitstream mapping in step S6 specifically includes: the driver comparing the data in the shadow buffer with the existing data stored on the network card bit by bit at the memory page granularity; extracting the memory page indexes and corresponding data blocks with inconsistent content; constructing a direct memory access DMA transfer descriptor linked list containing the data blocks, and performing write operations only for the changed network interface card hardware storage area.

[0011] As a preferred embodiment, after the direct memory access method synchronization described in step S6 is completed, a readback verification operation is also included: the device driver immediately reads back the network card's status register and compares it with the expected hardware status map generated in step S5; if the two are consistent, the bus lock is released; if the two are inconsistent, the backup image is automatically loaded and a rollback operation is performed.

[0012] As a preferred embodiment, the device driver internally maintains a transaction state machine, which strictly limits the response to the commit instruction used to trigger step S6 only when the state machine is in a "logically safe" state and the commit timer has not expired; otherwise, the instruction is discarded.

[0013] As a preferred embodiment, locking the hardware bus in step S6 specifically refers to the driver blocking the interrupt response of the network interface card and acquiring a mutex lock to refuse concurrent access requests from other processes to the device during the execution of direct memory access (DMA) transfer.

[0014] The beneficial effects of this invention are: Time-varying communication characteristics and reverse engineering resistance: This invention abandons the traditional static interface mode and generates dynamic instruction mapping and data offsets through random seed negotiation. This means that the characteristics of the transmitted binary data stream are different for each independent session. Even if an attacker intercepts a successful communication data session, it cannot use it for a subsequent attack, thus effectively resisting replay attacks and greatly increasing the difficulty of static reverse engineering analysis of the driver interface.

[0015] Atomicity and data security of write operations: By introducing a kernel-level shadow buffer and a two-phase commit mechanism, this invention logically isolates the data transmission process from the actual hardware modification process. Any anomalies occurring during data verification or transmission will only affect the kernel buffer and will not corrupt the original firmware data in the network card hardware, thereby ensuring the atomicity of hardware operations and high system reliability.

[0016] Logical-level conflict immunity: Unlike traditional methods that only verify data integrity, this invention introduces semantic-level virtual assembly and logical constraint topology verification. This is equivalent to performing a "pre-flight simulation check" before actual writing, which can effectively identify and block write requests that, although the signature is valid, have incorrect configuration logic (such as mutual exclusion of functions or out-of-bounds parameters), fundamentally preventing the device from becoming "bricked" due to configuration errors.

[0017] High bus utilization: Combined with differential bitstream mapping technology, the driver only writes the changed differential data blocks to the hardware. This not only significantly reduces PCIe bus occupancy time and write latency, but also reduces flash memory chip wear and extends device lifespan.

[0018] A robust access control system combines asymmetric encryption signatures with dynamic protocol negotiation to achieve dual verification of the authenticity of the data source and the uniqueness of the communication link, ensuring that only legitimate processes that hold the private key and follow the dynamic protocol specifications can modify the network card firmware. Attached Figure Description

[0019] Figure 1 System architecture diagram for a network interface card flash memory secure read / write method based on a custom kernel driver; Figure 2 A flowchart illustrating the authentication and authorization process for secure read / write methods of network interface card flash memory based on a custom kernel driver; Figure 3 A flowchart illustrating the secure read / write method for network interface card flash memory based on a custom kernel driver; Figure 4 Write a flowchart for a secure read / write method for network interface card flash memory based on a custom kernel driver. Detailed Implementation

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

[0021] The overall system architecture of this invention embodiment is as follows: Figure 1 As shown, it mainly includes three core interactive entities: a user-space application in user mode, an operating system kernel in kernel mode, and a network interface card at the physical layer. The operating system kernel runs a dedicated device driver that is deeply customized for this network interface card. This driver not only handles conventional hardware control but also integrates the dynamic security access mechanism proposed in this invention.

[0022] During system initialization, the device driver registers a character device through the kernel-provided interface and creates a corresponding device node, serving as the sole entry point for communication between user space and kernel space. User-space applications open this device node through the standard file operation interface and interact with the driver using the input / output control interface (ioctl). To achieve strong security and data consistency guarantees, the driver internally comprises three core logical units: a dynamic protocol negotiation unit, a transactional buffer management unit, and a low-level atomic transfer unit. The dynamic protocol negotiation unit is responsible for generating random instruction mapping rules at the start of each session; the transactional buffer management unit maintains a shadow buffer in kernel memory for temporary storage and verification of data to be written; and the low-level atomic transfer unit is responsible for locking the hardware bus during the final commit phase to ensure that the data writing process is not interrupted.

[0023] like Figure 2 As shown, the secure access method for network interface card firmware based on dynamic instruction mapping and transactional buffering proposed in this invention includes the following detailed steps in its complete implementation process: S1 Session Initialization and Protocol Parameter Negotiation. The user-space application first initiates a session establishment request to the device driver via a file descriptor. Upon receiving the request, the device driver first calls the kernel's high-precision random number generation function to generate a 64-bit random number as the random seed for this session. Simultaneously, the driver records the current system timestamp as a timestamp for the session to prevent the same session from being suspended indefinitely.

[0024] Subsequently, the device driver returns the random seed to the user-space application via a data copy function from kernel space to user space. At this point, the driver and application enter the protocol construction phase. Both parties independently calculate and generate an instruction opcode mapping table using the random seed as the initial value, employing a pre-built linear congruential algorithm or other deterministic pseudo-random algorithm in their code. This mapping table defines the correspondence between logical instructions and actual transmitted values. For example, in this session, a logical write instruction might be mapped to the value 0xA5, while in the next session it might become 0x3F. Simultaneously, both parties calculate a data structure offset rule based on the random seed, which specifies the starting position of the payload data in the transmitted data packet and the length of the padding data. Through this step, the communication protocol becomes dynamic, preventing external attackers from extracting general control commands by listening to a single communication.

[0025] S2 Dynamic Command Encapsulation and Transmission. When a user-space application needs to write firmware data to the network card, it must construct the request packet according to the dynamic rules generated in step S1. The application first looks up the temporary opcode corresponding to the write operation based on the current command opcode mapping table. Then, the application constructs a data buffer containing redundant padding according to the data structure offset rules.

[0026] Specifically, the application fills the beginning of the buffer with a specified length of random bytes, followed by the actual operation instructions and target address, then the firmware data to be written, and finally fills the end with more random data. To ensure data authenticity, the application uses its asymmetric encryption private key to digitally sign the core data segment (including the target address, data length, and firmware content), and attaches the signature to a specific field in the data packet. After encapsulation, the application sends the request data packet to the device driver via the input / output control interface.

[0027] S3 Mapping Resolution and Protocol Feature Verification. After receiving data packets from user space, the device driver enters the parsing and verification phase. The driver first reads the instruction opcode mapping table and offset rules in the current session context and performs reverse parsing on the received data packets. The driver removes the header padding data and extracts the opcode field.

[0028] If the extracted opcode does not match the write instruction defined in the current mapping table, or if the total length of the data packet does not meet the expected length calculated by the offset rules, the driver will determine the request as an illegal request (possibly a replay attack or scanning probe), immediately terminate the current session, release all related resources, and record a security log. If the opcode and format verification pass, the driver further parses the target address, data length, and firmware payload. At this point, the driver does not directly operate the hardware but enters the transaction preprocessing stage.

[0029] S4 Shadow Buffer Allocation and Data Temporary Storage. To address the potential data corruption issues caused by direct writes, the driver allocates a contiguous block of memory in the kernel memory region as a shadow buffer. The driver completely copies the firmware data parsed from user space into this shadow buffer. At this time, the driver's internal state machine switches from an idle state to a pending verification state. The existence of the shadow buffer ensures that data is in a controlled, rollback-capable isolated environment before it is actually written to the hardware. Even if the application crashes or a network interruption occurs at this time, the original firmware on the network card hardware remains intact and unaffected.

[0030] S5 semantic-level virtual assembly and logical conflict prediction. After data is temporarily stored in the shadow buffer, the device driver enters the critical pre-verification phase. Unlike the traditional static approach that only verifies the signature of data packets, this step performs deep semantic analysis and state simulation.

[0031] First, the driver invokes its internal parsing engine to identify the binary structure of the data to be written in the shadow buffer, extracting the configuration mask and function control bits. Simultaneously, the driver reads the network interface card's current non-volatile memory (such as firmware data in EEPROM or flash memory) and hardware control register status (including the Control Status Register (CSR), extended configuration space, and link status), generating a hardware status snapshot.

[0032] Next, the driver performs a virtual assembly operation in kernel memory. That is, without touching the actual hardware, it uses bitwise operations to apply the new data in the shadow buffer to the hardware state snapshot, generating a simulated expected hardware state map. This map reflects the theoretical state of each control register of the network card after a write operation.

[0033] Subsequently, the driver loads a pre-defined logical constraint topology table. This table defines the electrical limitations and logical mutual exclusion rules of the network interface card (NIC) hardware (e.g., when virtualization is enabled, traditional flow control bits must be set to zero; or write values ​​to specific address ranges cannot violate parity rules). The driver then iterates through and compares the expected hardware state map with the logical constraint topology table.

[0034] If the expected hardware state is found to violate a taboo rule in the topology table (i.e., a logical conflict is detected), or if digital signature verification fails, the driver will determine that the write request, although formatted correctly, is logically dangerous and poses a risk of causing hardware malfunction (i.e., "bricking" the device). In this case, the driver immediately triggers the circuit breaker mechanism, destroys the shadow buffer, locks the error log, and returns an error code containing the specific conflict type to the application. Only when the virtually assembled state graph fully conforms to the hardware logical constraints and digital signature verification passes will the driver mark the current transaction as "logically safe" and start the commit timer window.

[0035] S6 Atomic Commit and Differential Bitstream Mapping. After receiving the "logically safe" confirmation, the user-space application sends the final commit command. Upon receiving the command, the device driver first verifies the validity of the commit timing window. To further improve write efficiency and reduce bus occupancy time, this step does not perform a blind full copy but instead uses differential bitstream mapping. The driver compares the data in the shadow buffer with the data in the network card's current memory space page by page, calculating the index of the memory page that has only changed.

[0036] Subsequently, the driver acquires a mutex lock and locks the PCIe bus interface, temporarily disabling interrupt responses. Using the calculated difference index, the driver constructs a streamlined Direct Memory Access (DMA) descriptor list, directing only changed differential data blocks to specific physical addresses on the network interface card. After the transfer is complete, the driver immediately reads the network card's status register for verification, confirming that the actual hardware state matches the "expected hardware state map" predicted in step S5. If they match, the bus lock is released, and the transaction is declared successful; if they do not match, the driver immediately and automatically loads the backup recovery image for a rollback operation to ensure absolute determinism of the hardware state.

[0037] S7 Session Destruction and State Cleanup. After the hardware transfer operation is completed, the driver immediately releases the bus lock and mutex, restoring the network card's normal I / O responsiveness. Subsequently, the driver releases the shadow buffer in the kernel, returning the memory to the operating system.

[0038] Next, the driver executes the session destruction logic: clearing the saved random seed, destroying the instruction opcode mapping table, resetting the data offset rules, and restoring the internal state machine to its initial state. At this point, the secure access process is completely complete. Any subsequent access request must re-initiate a handshake request to generate new communication protocol parameters, thus ensuring the independence and security of each operation.

[0039] The above-described specific implementation constructs a robust defense system at the software level by building a dynamically changing communication language and a transaction mechanism with rollback capabilities. This not only effectively resists reverse engineering and malicious attacks targeting drivers, but also greatly improves the robustness of the firmware update process.

[0040] The above embodiments are merely illustrative of the principles and effects of the present invention, as well as some examples of its application, and are not intended to limit the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the inventive concept of the present invention, and these modifications and improvements are all within the scope of protection of the present invention.

Claims

1. A method for secure access to network interface card firmware based on dynamic command mapping and transactional buffering, comprising the following steps: S1 Session Initialization and Protocol Negotiation: The user space application requests the device driver to establish a session; the device driver generates a random seed and returns it to the user space application; both parties use the random seed as input and use a preset algorithm to synchronously generate the instruction opcode mapping table and data structure offset rules specific to this session. S2 Dynamic Command Encapsulation and Sending: The user space application converts the access operation into a temporary operation code corresponding to the current session according to the command operation code mapping table, and constructs a request data packet containing the data to be written and a digital signature according to the data structure offset rules. After encapsulation, the application sends the request data packet to the device driver through the input / output control interface; S3 Mapping Resolution and Validity Verification: After receiving the request data packet, the device driver performs reverse resolution based on the mapping table and offset rules generated in step S1. If the resolved opcode or data layout does not conform to the characteristics of the current session, the session is terminated. If the opcode and format verification pass, the driver further resolves the target address, data length, and firmware payload. At this point, the driver enters the transaction preprocessing stage. S4 Shadow Buffer Allocation and Data Temporary Storage: For a successfully parsed write request, the device driver requests a kernel-level shadow buffer, temporarily stores the parsed data to be written in the shadow buffer, and marks the transaction status as pending commit. S5 semantic-level virtual assembly and logical conflict prediction: The device driver reads the current hardware registers and non-volatile memory area status of the network card to generate a hardware snapshot. In memory, the shadow buffer data and the hardware snapshot are virtually assembled to generate the expected hardware state map. Then, the map is compared with the preset logical constraint topology table. If there is no conflict and the digital signature verification is successful, the session is locked and awaits submission. Semantic-level virtual assembly and logical conflict prediction specifically include: the device driver reads the current hardware registers and non-volatile memory area state of the network card to generate a hardware snapshot; the driver extracts the configuration bit information in the shadow buffer and applies it to the hardware snapshot through bit operations to simulate the register state after writing; the driver traverses the logical constraint topology table to check whether there are situations where mutex function bits are enabled simultaneously, electrical parameter configurations are out of bounds, or address space access violations exist in the simulated state; if any of the above conflicts are detected, or digital signature verification fails, the driver immediately destroys the shadow buffer and returns an error code; If there are no conflicts and the digital signature verification passes, the session is locked and awaits submission. S6 Atomic Commit and Differential Bit Stream Mapping: After receiving the commit command, the device driver calculates the differential bit stream between the shadow buffer and the actual data stored in the network interface card, locks the hardware bus, and only synchronizes the changed differential data blocks to the network interface card through direct memory access. S7 Session Destruction and State Cleanup: After the hardware operation is completed, the device driver releases the shadow buffer and destroys the instruction opcode mapping table and random seed of this session.

2. The network interface card firmware secure access method based on dynamic instruction mapping and transactional buffering as described in claim 1, characterized in that: The algorithm for generating the instruction opcode mapping table uses a linear congruent generator or a hash derivation function to generate a pseudo-random sequence with the random seed as the initial value, and establishes a dynamic one-to-one mapping relationship between the sequence and the preset basic command set.

3. The network interface card firmware secure access method based on dynamic instruction mapping and transactional buffering as described in claim 1, characterized in that: The data structure offset rule includes padding the header and tail of the request data packet with redundant data of random length, so that the starting offset address of the payload data changes dynamically in different sessions.

4. The network interface card firmware secure access method based on dynamic instruction mapping and transactional buffering as described in claim 1, characterized in that: The differential bitstream mapping in step S6 specifically includes: the driver comparing the data in the shadow buffer with the existing data stored on the network card bit by bit at the memory page granularity; extracting the memory page index and corresponding data block with inconsistent content; constructing a direct memory access DMA transfer descriptor linked list containing the data block, and performing write operations only for the changing physical address.

5. The network interface card firmware secure access method based on dynamic instruction mapping and transactional buffering as described in claim 1, characterized in that: After the direct memory access synchronization described in step S6 is completed, a readback verification operation is also included: the device driver immediately reads back the network card's status register and compares it with the expected hardware status map generated in step S5; if the two are consistent, the bus lock is released; if the two are inconsistent, the backup image is automatically loaded and a rollback operation is performed.

6. The network interface card firmware secure access method based on dynamic instruction mapping and transactional buffering as described in claim 1, characterized in that: The device driver internally maintains a transaction state machine, which strictly limits the response to the commit instruction used to trigger step S6 only when the state machine is in a "logically safe" state and the commit timer has not expired; otherwise, the instruction is discarded.

7. The network interface card firmware secure access method based on dynamic instruction mapping and transactional buffering as described in claim 1, characterized in that: The locking of the hardware bus in step S6 specifically refers to the driver masking the interrupt response of the network interface card and acquiring a mutex lock to refuse concurrent access requests from other processes to the device during the execution of direct memory access (DMA) transfer.

Images