Method for starting pre-boot execution environment, computer device and related product

Abstract

The application discloses a pre-start execution environment starting method, a computer device and related products, and relates to the technical field of computers. The method comprises the following steps: monitoring a timeout event of a monitoring timer and a network reply message event when a first network driver is triggered to unload a target by a second network driver loading and the first network driver has sent a network release message in the target unloading process; triggering the first network driver to resend the network release message when the timeout event is monitored and the network reply message event is not monitored; and forcibly terminating a target event polling operation and transferring network control from the first network driver to the second network driver when the resending frequency exceeds a preset retransmission threshold, so that the second network driver takes over and continues to execute a starting process based on its own network protocol stack. The technical problem of deadlock in the pre-start execution environment starting process in the related art is solved, and the technical effect of improving the starting reliability of the pre-start execution environment is achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and particularly relates to a pre-boot execution environment starting method, a computer device and related products. BACKGROUND

[0002] In the pre-boot execution environment, when the system completes the loading of the network starting program and transfers the control right from the first network driver of the firmware original to the second network driver of high performance, the network driver uninstalling process needs to be executed. In this process, the first network driver needs to send a network release message to the server and enter a target event polling operation to wait for receiving the corresponding network reply message, so as to confirm the successful release of the network resource.

[0003] However, in actual application, it is found that because the loading of the second network driver will cause the dynamic adjustment of the system task priority, the first network driver is extremely easy to compete with the second network driver in the task priority when executing the target event polling operation. The competition causes the polling channel of the first network driver to be blocked and unable to effectively capture the network reply message. Even if the server side has normally sent, because the first network driver will be blocked in the target event polling operation for an indefinite period of time, the uninstalling process cannot be successfully completed and the network control right cannot be transferred, which will cause the system starting process to deadlock, the pre-boot execution environment cannot be normally established, and further, the reliability and efficiency of the server cluster automatic deployment are affected. SUMMARY

[0004] The present application provides a pre-boot execution environment starting method, a computer device and related products, to solve the technical problem that in the related art, in the network driver control right transfer process in the pre-boot execution environment starting, the first network driver competes with the second network driver in the task priority, causes the system to be in the state of waiting for the network reply message all the time, and finally deadlocks.

[0005] The present application provides a pre-boot execution environment starting method, which comprises the following steps:

[0006] In response to the first network driver triggering a target offloading process due to loading of the second network driver, and the first network driver having sent a network release message in the target offloading process, a monitoring timer independent of a target event polling operation is started, the target event polling operation being an event polling operation performed by the first network driver waiting for a network reply message corresponding to the network release message; in response to starting of the monitoring timer, monitoring of a timeout event of the monitoring timer and a network reply message event is performed; in response to monitoring of the timeout event and failure to monitor the network reply message event, the first network driver is triggered to resend the network release message; in response to a number of times of resending the network release message exceeding a preset retransmission threshold, the target event polling operation is forcibly terminated, and network control is transferred from the first network driver to the second network driver, so that the second network driver takes over and continues to perform a startup process of the pre-boot execution environment based on a network protocol stack of the second network driver.

[0007] The application further provides a computer device, comprising a memory for storing a computer program, and a processor for implementing steps of the startup method of the pre-boot execution environment in the embodiments when executing the computer program.

[0008] In response to the first network driver triggering a target offloading process due to loading of the second network driver, and the first network driver having sent a network release message in the target offloading process, a monitoring timer independent of a target event polling operation is started, the target event polling operation being an event polling operation performed by the first network driver waiting for a network reply message corresponding to the network release message; in response to starting of the monitoring timer, monitoring of a timeout event of the monitoring timer and a network reply message event is performed; in response to monitoring of the timeout event and failure to monitor the network reply message event, the first network driver is triggered to resend the network release message; in response to a number of times of resending the network release message exceeding a preset retransmission threshold, the target event polling operation is forcibly terminated, and network control is transferred from the first network driver to the second network driver, so that the second network driver takes over and continues to perform a startup process of the pre-boot execution environment based on a network protocol stack of the second network driver.

[0009] The pre-boot execution environment starting method provided by the application establishes an independent and undisturbed monitoring path for solving the polling blocking problem caused by task priority competition by creating a monitoring timer independent of the original event polling operation, and ensures that even if the main event polling loop of the first network driver is blocked due to resource competition, the timer timeout event can still be triggered, which provides the possibility for system self-recovery; By setting a double-channel monitoring mode, the timeout event of the monitoring timer and the network reply message event are monitored at the same time, so that no matter which channel corresponding to the event triggers the event first, the system can perceive and respond in the first time, and the perception ability of the system to abnormal state is improved. When the timeout event is monitored and the network reply message event is not monitored, actively triggering the first network driver to resend the network release message can effectively deal with the reply loss problem caused by network instantaneous packet loss, packet being discarded by mistake and the like, and gives the system preliminary self-repairing ability. By setting the operation number of resending the network release message to exceed the preset retransmission threshold, the target event polling operation is forcibly terminated, and the network control right is transferred from the first network driver to the second network driver, so that no matter whether the release process is successful or not, the system can transfer the network control right to the second network driver, so that the second network driver takes over and continues to execute the starting process of the pre-boot execution environment based on its own network protocol stack, and breaks the deadlock state. BRIEF DESCRIPTION OF DRAWINGS

[0010] In order to more clearly illustrate the embodiments of the application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

[0011] Figure 1 The flowchart of the pre-boot execution environment starting method provided by an embodiment of the application is shown in the figure.

[0012] Figure 2 The flowchart of the pre-boot execution environment starting method provided by another embodiment of the application is shown in the figure.

[0013] Figure 3 The schematic diagram of the pre-boot execution environment provided by an embodiment of the application is shown in the figure.

[0014] Figure 4 The structure schematic diagram of the server of the pre-boot execution environment provided by an embodiment of the application is shown in the figure.

[0015] Figure 5 The flowchart of the pre-boot execution environment starting method provided by another embodiment of the application is shown in the figure.

[0016] Figure 6A structural diagram of a pre-boot execution environment starting device provided by an embodiment of the present application is shown.

[0017] Figure 7 An internal structure diagram of a computer device provided by an embodiment of the present application is shown. DETAILED DESCRIPTION

[0018] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, any other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present application.

[0019] It should be noted that, in the description of the present application, the terms “comprise”, “contain” or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such a process, method, article or device. The terms “first”, “second” and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0020] In order for those skilled in the art to better understand the technical solutions of the present application, the present application will be further described in detail below with reference to the drawings and specific embodiments.

[0021] As shown in Figure 1 An embodiment of the present application provides a pre-boot execution environment starting method, which specifically comprises the following steps:

[0022] Step 101: In response to the target uninstallation process being triggered by the second network driver for loading the first network driver, and the first network driver having sent a network release message in the target uninstallation process, starting a monitoring timer independent of a target event polling operation, the target event polling operation being an event polling operation performed by the first network driver for waiting for a network reply message corresponding to the network release message.

[0023] The first network driver refers to a firmware native network protocol stack driver, which can be specifically a DHCPv6 network driver (Dynamic Host Configuration Protocol version 6 driver) embedded in UEFI BIOS (Unified Extensible Firmware Interface Basic Input Output System). The driver is responsible for obtaining a network address and starting information at the initial stage of starting.

[0024] The second network driver refers to a high-performance or function-enhanced network driver loaded subsequently, which can be specifically a network driver of an iPXE (a kind of open-source pre-boot execution environment) or the like network boot program. The driver aims to take over the hardware to provide faster network speed or support more complex protocols.

[0025] The target unloading procedure refers to a series of ordered operations of resource release and state cleaning performed by the first network driver when the pre-boot execution environment control right is transferred.

[0026] The target event polling operation refers to a waiting mechanism of the first network driver after sending the release message, which is to promote the task priority to the TPL_CALLBACK (callback level network task priority level) level and cyclically check whether the network interface has data arrival.

[0027] The network release message refers to a protocol message initiated by the client actively, which is used to release the previously allocated network resources and contains information such as the IPv6 address to be released and the device identifier.

[0028] The network reply message refers to a confirmation message returned by the server to the client after receiving the release message, which is used to confirm that the resources have been released.

[0029] The monitoring timer can be a software timer created based on a UEFI timer event and independent of the network polling cycle. The timeout event of the timer has the same priority as the network event, which ensures that even if the network polling is blocked, the timeout event can be responded to, thereby providing an independent time monitoring channel for the whole procedure.

[0030] It can be understood that the first network driver in the present application can refer to any software network stack entity responsible for initial network configuration and communication in the pre-boot or early boot stage, and which will be replaced or unloaded in the later stage of the boot process. Specifically, as long as the driver needs to be replaced by another network driver before the operating system kernel takes over completely, it belongs to the category of the first network driver. The second network driver can refer to any software network stack entity loaded in the later stage of the boot process, aiming to take over or enhance network functions, and thus trigger the unloading of the previous driver. Specifically, as long as the driver is loaded in the boot process and needs to exclusively or primarily control the network hardware, it belongs to the category of the second network driver. Meanwhile, the deadlock in the present application can also refer to any kind of deadlock state caused by the intractable competition of two or more drivers (or system components) in task priority, interrupt request, memory access, or control of hardware registers, which causes the system process to fail to continue forward. Specifically, as long as the resource competition causes the driver unloading process to fail, thereby blocking the entire system startup sequence, it is considered as a deadlock problem that can be solved by the present application. In the present application, only the first network driver is taken as the DHCPv6 network driver embedded in UEFI BIOS, and the second network driver is taken as iPXE as an example for description, but it is not limited thereto.

[0031] For example, assuming that the deadlock is a startup failure problem caused by network quality, specifically, in a unstable network environment with network congestion, high packet loss rate or high delay, the network reply message / network release message may be lost, causing the first network driver to wait indefinitely, and the startup timeout fails. Through the monitoring timer timeout and intelligent retransmission mechanism in the present application, automatic retransmission can be initiated after a packet is lost, effectively resisting network jitter, and significantly improving the startup success rate in poor network environment.

[0032] For another example, assuming that the deadlock is a startup delay problem caused by server response delay, specifically, when the PXE (Preboot Execution Environment) server load is too high, it may not be able to process and reply to the client's release request in time, causing the client to wait for a long time, greatly prolonging the entire startup cycle. Through the preset retransmission threshold and forced exit mechanism in the present application, a maximum tolerance time is set for the entire waiting process. It avoids the indefinite suspension of the entire startup process due to the unresponsiveness of a single server, and ensures the predictability of the startup time.

[0033] In an embodiment, when the target unloading process is initialized, a special storage area is configured to persistently save the protocol context of the current network session, the network session being the whole process of sending a network release message by the first network driver and receiving a network reply message corresponding to the network release message, the protocol context including key parameters for uniquely identifying the current session, the client device and the network resource to be released, the key parameters including a transaction identifier and a device unique identifier; a firmware interface is called to create a monitoring timer based on a hardware clock source; in response to the sending completion of the network release message, the monitoring timer is initialized and started, and the timeout time of the monitoring timer is set as an initial threshold; wherein the interrupt response of the monitoring timer is not affected by the task priority level of the first network driver.

[0034] The special storage area can be a protected area in the system memory, which is used to safely save the key data during the turbulent period of driver unloading and switching, and ensure that the key data is not covered or lost by the subsequently loaded driver or cleaning process.

[0035] The transaction identifier can be a random number that is unique in a complete network conversation, which is used to accurately match the client's request with the server's reply to prevent message confusion.

[0036] The device unique identifier is a number that uniquely identifies the client device in the network, which ensures that the release message is accurately positioned to the resources of which device to be released.

[0037] By setting the system at the beginning of starting the target unloading process, a special storage area is first configured in the memory to persistently save the protocol context of the current network session. The session covers the whole process from sending a network release message to receiving a network reply message, and its protocol context contains key parameters such as transaction identifier and device unique identifier, which are used to uniquely identify the current session, the client and the resource to be released. Then, the system calls a firmware interface to create a monitoring timer based on a hardware clock source. When the network release message is sent, the timer is immediately initialized and started, and its timeout time is set as an initial threshold. By setting the interrupt response of the monitoring timer to be not affected by the task priority level of the first network driver, it is ensured that even if the main driver process is blocked due to resource competition, the timer timeout event can still be reliably triggered, providing an independent monitoring channel for the system to recover from deadlock.

[0038] Step 102: in response to the start of the monitoring timer, the timeout event of the monitoring timer and the network reply message event are monitored simultaneously.

[0039] A dedicated event waiting loop is created, and the timeout event and the network reply message event have the same processing priority in the dedicated event waiting loop; in the dedicated event loop, the timeout event triggered by the monitoring timer and the network reply message event triggered by the network interface are simultaneously waited for.

[0040] The dedicated event waiting loop refers to a program logic loop that continuously runs at the bottom of the system and is designed to process specific types of events. In this loop, the program suspends the current thread until one or more specific events registered in the loop are awakened. In this application, the dedicated event waiting loop is specifically created to listen to the timeout and network reply events in parallel, which is the core mechanism to realize dual-channel monitoring.

[0041] The timeout event refers to a signal actively sent by the monitoring timer to the system when the preset initial threshold or target timeout time is reached.

[0042] A dedicated event waiting loop is created by setting the system. In this loop, the timeout event and the network reply message event are given the same processing priority, so that the system is no longer passively and singly waiting for network reply, but in this dedicated event loop, any one of the above two events is waited for in parallel. This ensures that both timely awareness of network anomalies and timely response to normal replies can be processed with equal efficiency.

[0043] Step 103: In response to monitoring the timeout event and not monitoring the network reply message event, triggering the first network driver to resend the network release message.

[0044] S1: In response to the timeout event being triggered in the dedicated event waiting loop, checking whether a valid network reply message has been received at the time of triggering the timeout event or within the dedicated event waiting time.

[0045] S2: In response to not receiving a valid network reply message, determining that the timeout event has been monitored and that the network reply message event has not been monitored.

[0046] When the timeout event in the dedicated event waiting loop is triggered, the system first performs a state check to check whether a valid network reply message has been successfully received within the just-ended waiting period, aiming to exclude unnecessary retransmission caused by event response timing problems.

[0047] After confirming that no valid reply has been received, the system determines that the timeout event has been monitored and that the network reply message event has not been monitored.

[0048] S3: Increment the value of the retransmission counter, which records the number of times the first network driver resends the network release message.

[0049] S4: determining whether the current value of the retransmission counter is less than or equal to a preset retransmission threshold.

[0050] S5: in response to the current value of the retransmission counter being less than or equal to the preset retransmission threshold, invoking a preset callback function, accessing the dedicated storage area through the preset callback function, and obtaining the protocol context of the network session persistently saved in the dedicated storage area.

[0051] The value of the retransmission counter is incremented each time the network release message is retransmitted. The counter is specifically used to accurately record the cumulative number of times the network driver retransmits the network release message. The current value of the retransmission counter is compared with the preset retransmission threshold to determine whether the retransmission attempt is still within the allowed number of times. If the number of retransmissions does not exceed the threshold, the system invokes a preset callback function. This function accesses the dedicated storage area and obtains the protocol context of the network session previously persistently saved, ensuring that even in abnormal states, the retransmission behavior is based on complete and consistent session information.

[0052] S6: the preset callback function reconstructs and sends a target network release message consistent in semantics with the first sent network release message based on the protocol context of the network session.

[0053] The preset callback function uses the obtained protocol context to accurately reconstruct a target network release message that is completely consistent in semantics with the first sent network release message and retransmits it.

[0054] Specifically, the preset callback function reconstructs the network release message based on the protocol context of the network session, reads the first network session protocol context saved when the first network release message is sent from the dedicated storage area, determines whether the transaction identifier and device identifier in the reconstructed network release message match the first network session protocol context, and retransmits the reconstructed network release message as the target network release message in response to the transaction identifier and device identifier in the target network release message matching the first network session protocol context.

[0055] The preset callback function is a function registered by the system in advance and automatically invoked after a specific event such as a timeout event. In this application, it is set to compare the transaction identifier and device identifier in the reconstructed network release message with the original identifier saved in the first network session protocol context before retransmitting the network release message. Only when the two key identifiers completely match, does it prove that this retransmission is a legal continuation of the original session, and the reconstructed message is sent as a valid target network release message, thus ensuring the correctness and security of the retransmission behavior and preventing protocol errors caused by context confusion.

[0056] Among them, retransmitting the reconstructed network release packet as a target network release packet includes: calculating the target network release packet sending time based on the network release packet process network delay, network delay weight coefficient, link delay parameter, network link speed, target network release packet estimated size, link transmission weight coefficient, server load coefficient, minimum timeout protection time, last network release packet sending time and sending time calculation formula; sending the target network release packet based on the target network release packet sending time, and updating the target timeout time of the monitoring timer corresponding to the target network release packet sending this time according to the target network release packet sending time.

[0057] The network release packet process network delay refers to the average round-trip time experienced from sending a network release packet to receiving its acknowledgement reply packet, which is used to measure the network condition index. It can be calculated by recording the packet sending timestamp and receiving timestamp in the protocol interaction process.

[0058] The network delay weight coefficient refers to the coefficient dynamically adjusted according to the stability and change trend of the network delay, which can be set by the operator according to actual experience. Generally, the larger the network jitter, the larger the network delay weight coefficient setting value, so as to reserve more buffer time.

[0059] The link delay parameter refers to the inherent propagation delay of the signal on the physical link, which is related to the physical distance and medium.

[0060] It can be set by the operator according to actual experience, or it can be obtained by querying the LLDP information of network equipment, and it can also be simplified to an empirical value set according to the network type (such as local area network, wide area network) in the pre-start environment.

[0061] The network link speed refers to the connection rate of the network interface, which can be 100Mbps, 1Gbps, 10Gbps. It can be directly obtained by querying the network card hardware register or calling the network protocol interface provided by UEFI / BIOS.

[0062] The target network release packet estimated size can refer to the estimated length of the DHCPv6 release packet to be retransmitted, which can be directly calculated and obtained by the program after the construction is completed.

[0063] The link transmission weight coefficient refers to the weight coefficient used to convert the packet size and link speed into transmission time. It takes into account the protocol encapsulation overhead and hardware processing delay.

[0064] The server load factor can be a parameter for evaluating the current processing capacity of the PXE / DHCPv6 server. Generally, the higher the load, the slower the expected response can be. The speculation can be made by analyzing the trend of the historical reply time of the server; in a more advanced implementation, the server can inform the client of its load state through a specific option of the DHCPv6 message.

[0065] The minimum timeout protection time is a manually set minimum timeout threshold for preventing the calculated sending time from being too short and avoiding too frequent retransmission. It can be set according to the minimum waiting interval that the system can tolerate or set according to the experience of the operator.

[0066] The last network release message sending time refers to the time point of the most recent sending of the network release message. The timestamp of the system can be recorded each time a message is sent and saved persistently in the network session context.

[0067] The target timeout time is a new timeout time set for waiting for a reply after this retransmission, which is usually associated with the target network release message sending time and can be calculated based on the target network release message sending time and the updated network delay.

[0068] The sending time calculation formula is represented as:

[0069] ;

[0070] Wherein, T n represents the target network release message sending time, RTT base represents the network delay of the network release message process, K rtt represents the network delay weight coefficient, L represents the link delay parameter, LinkSpeed represents the network link speed, S represents the target network release message estimated size, K link represents the link transmission weight coefficient, ServerLoad represents the server load factor, T min represents the minimum timeout protection time, T n-1 represents the last network release message sending time.

[0071] In this way, on the basis of ensuring not less than the minimum timeout protection time, the network conditions (delay, bandwidth) and the influence of the real-time load of the server on the message processing capacity are comprehensively considered, so that the retransmission interval dynamically adapts to the real load of the system, avoiding network congestion and improving the efficiency and stability of the retransmission mechanism.

[0072] Step 104: in response to the number of operations of re-sending the network release packet exceeding the preset retransmission threshold, forcibly terminating the target event polling operation, and transferring the network control from the first network driver to the second network driver, so that the second network driver takes over and continues to execute the pre-boot execution environment startup process based on its own network protocol stack.

[0073] Specifically, the number of operations of re-sending the network release packet is obtained, and in response to the number of operations of the network release packet exceeding the preset retransmission threshold, the target event polling operation of the first network driver is forcibly interrupted; the network buffer pool held by the first network driver is traversed and released; the network protocol instance registered by the second network driver through the protocol interface is queried; and in response to the initialization state and the operation state of the network protocol instance being both valid, it is determined that the network protocol interface of the second network driver is in a ready state, and the network control is transferred from the first network driver to the second network driver.

[0074] The preset retransmission threshold refers to the maximum number of times allowed to re-send the network release packet, which is a safety mechanism to prevent the system from falling into an infinite retransmission cycle.

[0075] The network buffer pool can be a storage area created by the first network driver specifically for storing network data packets to be sent and received.

[0076] The network protocol instance refers to a specific and operable network protocol interface object registered by the second network driver to the system, which represents the ability of the driver to prepare and provide network services.

[0077] The initialization state indicates that the required hardware, memory, and other resources of the network protocol instance have been successfully configured. The operation state indicates that the network protocol instance is in an active state and can normally process network data streams.

[0078] The network control refers to the control power of configuring and managing the hardware resources (such as registers, DMA engines, interrupts) of the network interface card.

[0079] When the number of operations of re-sending the network release packet exceeds the preset retransmission threshold, the system first forcibly terminates the target event polling operation of the first network driver to break the potential deadlock. Then, a thorough resource cleanup is performed, i.e., all network buffer pools held by the first network driver are traversed and released. After the cleanup is completed, the network protocol instance registered by the second network driver through the protocol interface is queried, and its initialization state and operation state are checked. When it is confirmed that the instance is completely ready, it is determined that the network protocol interface of the second network driver is in a working state, and then the final operation is performed, i.e., the network control is formally transferred from the first network driver to the second network driver, so that it can take over the network hardware and continue to execute the pre-boot process.

[0080] The application further comprises, before the forced termination of the target event polling operation, identifying a network session corresponding to a network release message that has been sent and for which no valid network reply message has been received; and performing a resource cleanup operation on the identified network session, the resource cleanup operation comprising releasing a network buffer occupied by the identified network session and deregistering a monitoring timer corresponding to the identified network session.

[0081] The application further comprises, after the forced termination of the target event polling operation, generating a network session diagnosis report, the diagnosis report comprising: a number of network release messages sent, a number of invalid network reply messages received, a number of task priority conflicts, and a network link quality indicator; sending the diagnosis report to a remote log server or a local persistent storage; and determining whether to trigger a network driver version rollback based on the diagnosis report.

[0082] In response to triggering the network driver version rollback, a historical version of the driver compatible with the current first network driver is queried from a preset driver version repository; an image file of the historical version of the driver is used to overwrite an image file of the current first network driver; configuration parameters of the first network driver are reset to initial default values; the first network driver is reinitialized and the sending process of the network release message is reattempted based on the reset configuration parameters.

[0083] The network link quality indicator is a quantitative parameter for evaluating the current network connection status, which can include link speed, signal strength, bit error rate, etc.

[0084] The network driver version rollback is a fault recovery strategy, which refers to automatically replacing the current problematic first network driver with a known stable old version of the driver when a serious compatibility problem is diagnosed.

[0085] The driver version repository is a storage repository storing a plurality of historical version network driver image files and metadata (such as version number and compatibility information) thereof.

[0086] The initial default values can be original configuration parameters possessed by the network driver when it is manufactured or installed.

[0087] The application adds a precise resource recycling mechanism before the forced termination operation, identifies all network sessions initiated by the first network driver but not completed, and performs a thorough resource cleaning operation on these sessions, i.e., releases the network buffer occupied by the sessions and cancels the dedicated monitoring timer, thereby eliminating resource leakage. After the forced termination operation, the application also adds an intelligent operation and maintenance diagnosis and recovery mechanism, which automatically generates a network session diagnosis report that records key information such as the number of message sending times, the number of invalid replies, the number of inferred task priority conflicts, and network link quality indicators, and sends it to a remote or local storage. The system determines whether to trigger the network driver version rollback based on the report. If triggered, the compatible historical version driver is queried from the driver version warehouse, the image file of which is used to overwrite the current driver, and the driver configuration is reset to the initial default value and then reinitialized, thereby automatically repairing the startup failure caused by driver compatibility problems and greatly improving the self-healing ability and operation and maintenance efficiency of the system.

[0088] In an embodiment, before the network control right is transferred from the first network driver to the second network driver, the following steps are included: extracting the digital signature data and the issuer key identifier from the preset option field of the target network release message to be verified; querying the list of trusted public keys pre-stored in the firmware non-volatile storage area according to the issuer key identifier to obtain a verification public key matched with the issuer key identifier; performing a digital signature verification operation on the message payload part of the target network release message using the verification public key, the message payload part being the original data part used to calculate the digital signature in the target network release message; in response to the success of the digital signature verification operation, determining that the target network release message is complete and the source is trusted, and performing the step of transferring the network control right to the second network driver; in response to the failure of the digital signature verification operation, determining that the target network release message is tampered or the source is abnormal, interrupting the network control right transfer process, recording a security audit event, and triggering a security recovery process for the first network driver.

[0089] The digital signature data is ciphertext data generated by the sender using the private key to perform an encryption operation on the message payload, which is used to prove the integrity and source identity of the message. It can be directly parsed and extracted from a specific option field (such as a custom DHCPv6 option) of the received target network release message.

[0090] The issuer key identifier is an identity identifier used to uniquely identify the private key used for signing, so that the receiver can quickly locate the correct verification public key from multiple public keys. It can be parsed and extracted from the option field of the message together with the digital signature data.

[0091] The trusted public key list is a preset collection of trusted signature public keys and their corresponding key identifiers. Only messages signed by public keys in this list will be trusted. It can be pre-installed by the system administrator or device manufacturer in the non-volatile storage area of the firmware (such as the variable storage of UEFI) and queried during verification.

[0092] The verification public key is the public key part of the asymmetric key used to verify the validity of the digital signature, which can be obtained by matching the extracted issuer key identifier in the trusted public key list.

[0093] The message payload part refers to the remaining application layer data part (i.e. the DHCPv6 message itself) after removing the headers (such as IP header, UDP header) that may change during transmission from the target network release message, which is the original data for signature calculation. It can be obtained by decoding and stripping the received original network message according to the protocol format.

[0094] In order to ensure the security of the control transfer, a digital signature verification mechanism is introduced before the transfer. The system first extracts the digital signature data and the issuer key identifier from the target network release message to be verified. Then, according to the identifier, it queries the trusted public key list pre-installed in the firmware security storage area to obtain the corresponding verification public key. Then, the system uses this public key to perform digital signature verification operation on the payload part of the message. Specifically, it uses the verification public key to verify the digital signature, and at the same time, it performs hash calculation on the received message payload part. Finally, it compares the operation results with the hash value. If the comparison result is consistent, it is determined that the digital signature is valid, the message is complete and the source is trusted, and the control transfer is allowed to be executed. If the comparison result is inconsistent, it is determined that the verification fails, the message is tampered or forged, and the transfer process is immediately interrupted. At the same time, this exception is recorded as a security audit event, and a security recovery process is started for the first network driver, effectively resisting the man-in-the-middle attack and malicious code injection, providing key security protection for the pre-boot environment.

[0095] In an implementable embodiment, the preset retransmission threshold in the present application can be a self-adaptive threshold dynamically adjusted based on historical diagnosis reports; wherein, the dynamically adjusting the self-adaptive threshold comprises: calculating an environment stability coefficient based on the correlation between the network link quality index and the number of task priority conflicts in the historical diagnosis reports; in response to the environment stability coefficient being lower than a first threshold, increasing the self-adaptive threshold to enhance the tolerance of the system in a harsh environment; in response to the environment stability coefficient being higher than a second threshold, and the total success rate of network release message sending being continuously higher than a set level, then decreasing the self-adaptive threshold to optimize the starting efficiency, thus, by setting the preset retransmission threshold as a self-optimizing adaptive threshold. By analyzing the historical diagnosis reports, the correlation between the network link quality and the number of task priority conflicts is calculated, and a quantitative environment stability coefficient is obtained. When the coefficient is low, it indicates that the system is in a state of complex network environment or frequent drive conflicts, at this time, the retransmission threshold is automatically increased, and the fault tolerance of the system is enhanced by allowing more retransmission attempts to ensure the success rate of starting. Conversely, when the environment is stable and the success rate is continuously high, the retransmission threshold is decreased to avoid unnecessary waiting, thereby speeding up the starting efficiency under normal circumstances, so that the system has the ability of intelligently sensing the environment and dynamically balancing reliability and efficiency.

[0096] The pre-start execution environment starting method provided by the present application effectively solves the system deadlock problem caused by the task priority competition between network drivers by introducing independent monitoring timers and special event waiting loops to build a double-channel event monitoring mechanism. Through intelligent retransmission and protocol context persistence, reliable recovery of the network release process is achieved in a complex network environment; through digital signature verification and safe recovery process, a security protection system for the control right transfer process is established; and through diagnosis report and driver version rollback mechanism, system self-diagnosis and self-repairing capability is formed. These technical means cooperate with each other to transform the traditional fragile and dead starting process into a robust system with fault tolerance, security and self-healing capability, which significantly improves the starting success rate and operation reliability in large-scale deployment scenarios.

[0097] In the field of servers and cloud computing, PXE (Preboot eXecution Environment) as a basic network boot technology has become the core pillar of modern data center automation operation, which completely changes the mode of traditional server deployment and maintenance by transferring the starting process of the server from local storage to the network (the starting process of the pre-start execution environment). In a super large-scale data center, an enterprise private cloud and a hybrid cloud environment, PXE technology enables administrators to complete the deployment of operating systems for hundreds of physical servers within minutes, which is several orders of magnitude higher than the efficiency of traditional optical drive or USB installation.

[0098] With the rapid development of cloud computing and software-defined data centers, the role of PXE has expanded from simple operating system installation to the management of the entire server life cycle. It not only supports common Linux and Windows system deployment, but also enables the automated configuration of cloud-native infrastructure such as Kubernetes nodes (an open-source container orchestration system) and OpenStack compute nodes (an open-source infrastructure as a service platform). In hyper-converged architecture (HCI), the integration of PXE with automation tools such as Ansible and Terraform enables unified deployment of computing, storage, and network resources. In enterprise IT operations scenarios, the value of PXE is also not to be underestimated. By combining enhancements such as iPXE (an open-source pre-boot execution environment), operations personnel can build intelligent network boot menu systems to achieve system repair, hardware diagnosis, firmware upgrade, and other diverse functions. In particular, in the event of server hardware failure, PXE can quickly load diagnostic tools, greatly reducing mean time to repair (MTTR). In the security field, UEFI PXE (Unified Extensible Firmware Interface-based pre-boot execution environment) and Secure Boot work together to ensure the security of the network boot process and prevent the injection of malicious code.

[0099] Compared to traditional IPv4 PXE (using IPv4 protocol to start PXE), IPv6 PXE (using IPv6 protocol to start PXE) has significant advantages in modern data centers and cloud computing environments. Its 128-bit address space completely solves the address exhaustion problem and is particularly suitable for the automated deployment needs of large-scale server clusters (post-network control handover boot process). In terms of security, IPv6 PXE naturally integrates with IPsec (a protocol standard for providing encryption and security authentication for IP-based network communication), providing end-to-end encryption protection and perfect compatibility with UEFI SecureBoot (Unified Extensible Firmware Interface-based secure boot) mechanisms, building a complete trust chain from firmware to operating system. In hybrid cloud and edge computing scenarios, IPv6 PXE supports end-to-end network connectivity without the need for NAT (Network Address Translation) penetration to achieve cross-regional remote system installation and maintenance. These technical advantages make IPv6-based PXE a key technology foundation for supporting next-generation data center automation operations, Internet of Things device batch deployment, and cloud-native infrastructure construction, providing new possibilities for the scaling, intelligentization, and security of IT infrastructure operations.

[0100] In the iPXE network booting process in the IPv6 environment, when the UEFI BIOS (Basic Input Output System) firmware is matched, there is a key technical defect: the probability of system startup phase shutdown problem occurs. The triggering mechanism of the problem is as follows: when the PXE client completes the NBP (Network Self-Test Program) file download and starts to load the iPXE program, the iPXE initializes its own network driver, and unloads the original UEFI (Unified Extensible Firmware Interface) DHCPv6 driver (the first network driver triggers the target uninstallation process due to the loading of the second network driver). At this time, the UEFI DHCPv6 (Unified Extensible Firmware Interface Dynamic Host Configuration Protocol version 6) driver actively sends the DHCPv6 RELEASE message (PXE client actively releases the IPv6 address allocated by the PXE server, which is transmitted based on the UDPv6 protocol, port 546 / 547) to the PXE server, which contains the IPv6 address to be released and the server identifier (UUID). Under normal circumstances, the PXE server should reply with the DHCPv6 REPLY message (PXE server replies DHCPv6 REPLY to confirm the release of the IPv6 address, also using the UDPv6 protocol, because it is suitable for connectionless and real-time scenarios), confirming the release of the IPv6 address and updating the address pool state.

[0101] In actual operation, the UEFI firmware polls the network data packet by raising the TPL (Task Priority Level) to the TPL_CALLBACK level (callback level network task priority level), and the iPXE driver also sets its TPL to the same priority, resulting in resource competition (target event polling operation implementation mechanism) between the two. That is, in the UEFI IPv6 PXE startup process, when the iPXE takes over the network control, the UEFI native DHCPv6 driver will enter the Polling state after sending the DHCPv6 RELEASE message, waiting for the DHCPv6 REPLY of the server (the event polling operation implemented by the first network driver waiting for the network release message corresponding to the network reply message). Since the iPXE driver raises the task priority (TPL) to the same TPL_CALLBACK level as the UEFI driver, resource competition occurs between the two, and the key DHCPv6 REPLY message may be discarded. The UEFI driver continues to block in the Polling state because it cannot receive the reply, and eventually causes system startup deadlock.

[0102] In the PXE boot flow of UEFI architecture, when the client server completes the hardware initialization (including memory, CPU and basic chipset configuration) of the BIOS PEI (Pre-EFI Initialization) stage, it loads and executes most of the hardware drivers through the DXE (Driver Execution Environment) stage, and the system enters the BDS (Boot Device Selection) stage. At this time, the BIOS will enumerate all network interfaces in turn, and identify the network interface supporting PXE boot through detecting the PCI Option ROM or the UEFI PXE-BC protocol (a standard protocol built in the UEFI firmware for realizing the network boot (PXE) function). For each candidate network interface, the BIOS will load the UEFI native DHCPv6 driver, establish an IPv6 link local address (FE80:: / 10), and obtain a global IPv6 address, a boot server information (OPT_BOOTFILE_SERVER-Bootfile Server Option) and a network boot program path (OPT_BOOTFILE_URL-Bootfile URL Option) through complete DHCPv6 interaction (Solicit-request, Advertise-announcement, Request-request, Reply-reply). After successfully downloading the NBP (Network Boot Program) file and handing over the control right to iPXE, the iPXE will initialize its high-performance network driver (based on UEFI SNP-Simple Network Protocol), and at the same time, inform the BIOS to uninstall the native UEFI DHCPv6 driver through ExitBootServices(). At this time, the uninstalled UEFI DHCPv6 driver will actively send a DHCPv6 RELEASE message (using the UDPv6 547 port) to release the temporarily allocated IPv6 address, and enter the Polling mode to wait for the DHCPv6 REPLY confirmation of the server (also through the UDPv6 546 port). Since the iPXE raises the task priority (TPL-Task Priority Level) to the TPL_CALLBACK level when taking over the network stack, a priority conflict occurs with the event polling mechanism of the UEFI driver, resulting in the critical DHCPv6 REPLY message being discarded. This TPL (task priority) competition causes the UEFI driver to continuously block in the Polling state, and cannot complete the resource release process, finally causing the system boot process deadlock.The core of the problem is the incompatibility of UEFI network stack and third-party network driver (iPXE) in task priority management and resource release timing.

[0103] To solve this problem, the application sets the process of BIOS unloading the native UEFI DHCPv6 driver (including the process of sending DHCPv6 RELEASE release message and polling DHCPv6 REPLY reply message) as a reentrant callback function, and integrates it into the DHCPv6Stop function (starts a monitoring timer independent of the target event polling operation). In the specific implementation, after the PXE client successfully sends the DHCPv6 RELEASE release message, the system will immediately start a configurable timer (the initial recommended setting is 5 seconds according to the test on the server with this problem), and the timer runs in parallel with the original polling state detection mechanism (monitoring timer start and monitoring mechanism). When the timer triggers the timer timeout event, it indicates that the polling state may be blocked due to the TPL task priority competition between BIOS and iPXE. The system will automatically call back the DHCPv6Stop function to reinitiate the complete DHCPv6 RELEASE release process (including message construction, sending and state maintenance) (trigger the first network driver to resend the network release message). In order to improve the reliability, we designed an intelligent retransmission strategy: using multiple backoff algorithm to dynamically adjust the retransmission interval (such as 5 seconds for the first time, 10 seconds for the second time, and 15 seconds for the third time), and strictly checking the consistency of transaction ID and server identifier (DUID-device unique identifier) at each retransmission. At the same time, the system will maintain a retransmission counter, and when the maximum retransmission number (recommended 3 times) is reached, even if no DHCPv6 REPLY reply message is received, it will be safely assumed that the PXE server has completed the IPv6 address release at this time. At this time, the system will: forcibly exit the polling loop, clean up the UEFI network protocol stack residual state, and completely hand over the network control to the iPXE network driver (forcibly terminate the target event polling operation and hand over the network control to the second network driver).

[0104] The boundary condition processing is considered in the application, including: verifying the iPXE driver ready state before the final forced exit, saving necessary DHCPv6 session information for fault diagnosis, and ensuring the correct release of memory resources. Through this mechanism, not only the startup process deadlock problem caused by TPL competition is solved, but also the robustness in complex network environment is enhanced, the normal startup of PXE environment of numerous PXE clients in the client server cluster scenario is ensured, more reliable underlying support is provided for UEFI IPv6 PXE network startup, the success rate of IPv6 PXE startup is greatly improved; the intelligent retransmission strategy does not significantly increase the PXE startup time (about 30s) while ensuring the completion of IPv6 address release, within the acceptable range, the system robustness in complex PXE network environment is improved, and the compatibility problem of UEFI network driver and iPXE network driver is solved.

[0105] Please refer to Figure 2 In a specific application scenario, when the first network driver is a UEFI native DHCPv6 driver and the second network driver is an iPXE driver, in order to solve the compatibility problem of UEFI network driver and iPXE network driver, the pre-boot execution environment startup method of the application can be as shown in the following flow chart:

[0106] 1. In the PXE startup process of the UEFI architecture, after the client server completes the key hardware initialization (including memory controller configuration, CPU microcode update, basic chipset register setting and PCIe device enumeration) of the BIOS PEI (Pre-EFI Initialization) stage, the system formally enters the DXE (Driver Execution Environment) stage. In this stage, the BIOS will perform deep initialization on each detected network interface controller by traversing the PCIe device tree, including:

[0107] 1) Read the Option ROM (Option ROM) information through the PCI configuration space, verify the PXE compatibility (meet the PXE-BC2.1 or newer specification).

[0108] The system reads the preset Option ROM (Option Read-Only Memory) code in the network card PCI configuration space by accessing the specific register area, parses the firmware identifier and instruction set in the ROM, strictly verifies whether it complies with the PXE-BC 2.1 or higher version technical specification formulated by Intel, and confirms whether the network card hardware has basic PXE startup capability.

[0109] 2) For UEFI-compliant network cards, load the device-specific UEFI driver (follow the UNDI (Universal Network Driver Interface) protocol).

[0110] For UEFI-compliant network cards that pass compatibility verification, the system locates and loads the device driver specifically designed for this model of network card from its Option ROM or firmware built-in driver library. This driver is developed strictly in accordance with the UNDI (Universal Network Driver Interface) protocol, and its loading provides a standardized and unified underlying network hardware operation interface for the upper-layer software, achieving initialization and basic control of the network card.

[0111] 3) Establish a complete UEFI network protocol stack (including ARPv6 (Address Resolution Protocol for IPv6), ICMPv6 (Internet Control Message Protocol for IPv6), and other basic protocols).

[0112] After the network card driver successfully loads and initializes the hardware, the UEFI firmware builds a simplified network protocol stack running in the pre-boot environment on top of its driver layer. This protocol stack fully implements ARPv6 (for IPv6 address resolution), ICMPv6 (for network diagnosis and control), and other core network protocols, laying the necessary protocol foundation for subsequent DHCPv6 communication, address acquisition, and network boot program download.

[0113] 2. After successfully identifying the PXE boot network port, the system instantiates the UEFI native DHCPv6 driver, which first establishes an IPv6 link-local address (FE80:: / 10) through RS (Router Solicitation) / RA (Router Advertisement) interaction, and then initiates a complete DHCPv6 four-step handshake process:

[0114] 1) Send Solicit (Request) message (FF02::1:2) to probe available servers.

[0115] After obtaining the link-local address, the PXE client broadcasts the Solicit message in IPv6 multicast mode (target address FF02::1:2, representing all DHCPv6 servers and relay agents). This message is equivalent to a network probe, aiming to discover available DHCPv6 servers in the network and request basic network configuration and boot parameters.

[0116] 2) Resolve the Option 59 (Boot Server Identifier) in the Advertise message.

[0117] One or more DHCPv6 servers in the network will respond with Advertise messages after receiving the Solicit message. The client resolves these response messages, and the key operation is to extract the Option 59 (Boot Server Identifier) option in the message, which indicates the specific PXE server address that can provide the boot file for the client, and the client selects a server for subsequent requests accordingly.

[0118] 3) Request specific configuration through the Request message.

[0119] The client sends a Request message to the specified PXE server (known from Option 59) according to the selection in the previous step. This message formally requests specific network configuration from the server, including global IPv6 address, DNS information, and crucial boot file location (OPT_BOOTFILE_URL) parameters.

[0120] 4) Finally get the Reply message of the IPv6 PXE server, complete the PXE service registration, and facilitate subsequent loading of the iPXE driver.

[0121] The selected PXE server processes the Request message and sends the final Reply message. The client receives this message and obtains the global IPv6 address allocated to it, the exact boot file path, and other configuration information. This marks the completion of the DHCPv6 interaction, the successful registration of the PXE service, and the client can immediately download and execute the iPXE network boot program according to the obtained URL address through TFTP or HTTP protocol.

[0122] 3、In the NBP (Network Boot Program) (such as iPXE.efi) loading stage, the system will go through a complex process of transferring control:

[0123] 1) BIOS loads the NBP image through LoadImage().

[0124] The UEFI BIOS uses the LoadImage() service to load the network boot program from the storage device or network into system memory. This step completes the loading and basic memory and format verification of the NBP image, preparing for execution, but the NBP code has not started running at this time.

[0125] 2) Call StartImage() to transfer execution authority.

[0126] After the image is successfully loaded, the BIOS calls the StartImage() service. This call formally hands over the execution control of the CPU from the UEFI firmware to the entry function of the NBP, marking the beginning of the independent running of the network boot program such as iPXE.

[0127] 3) When iPXE is initialized, it registers its own SNP (Simple Network Protocol) implementation through InstallProtocolInterface().

[0128] During the initialization process, iPXE calls the InstallProtocolInterface() function. This operation registers the SNP instance implemented by itself to the UEFI system, thereby declaring that it is ready to take over the network function and cover or supplement the original simple network protocol of UEFI.

[0129] 4) Call ExitBootServices() to trigger UEFI environment cleaning.

[0130] When iPXE confirms that it is fully ready and can independently manage all necessary hardware and resources, it calls the ExitBootServices() function. This call is a key turning point in the system running state, which informs the UEFI firmware that the operating system boot loader (such as iPXE) is ready, and the UEFI can release most of the runtime service resources it occupies, thereby triggering the uninstallation process of the UEFI native driver (including the DHCPv6 driver).

[0131] 4, At this time, the network driver of iPXE will completely take over the hardware control, including:

[0132] 1) Reset the network card DMA (Direct Memory Access) engine.

[0133] iPXE driver first resets the DMA engine of the network card. This step aims to stop all ongoing data transmission of the network card, clear the DMA cache queue, and ensure that the data channel between the network card and the host memory is in a completely new and determined initial state, laying the foundation for iPXE exclusive control.

[0134] 2) Reconfigure the receive descriptor ring.

[0135] iPXE releases or reallocates the receive descriptor ring set by the UEFI driver and establishes a new descriptor ring structure according to its own memory management strategy and performance requirements. This enables the network card to store the received network packets directly into the memory area specified by the iPXE driver according to the instructions of the iPXE driver, thereby completely taking over the network data reception process.

[0136] 3) Update MAC (Media Access Control) filter settings.

[0137] iPXE reconfigures the MAC address filter registers of the network card according to the needs of its network protocol stack. This includes setting new unicast addresses, updating multicast group lists, etc., to ensure that the network card only receives network messages sent to itself or of interest to iPXE, while filtering out irrelevant data, optimizing performance and ensuring the correctness of communication.

[0138] After the iPXE driver completes the comprehensive takeover and initialization of the network hardware, it guides the UEFI to execute the exit mechanism of its native DHCPv6 driver. This is the starting point of the address release process, marking the end of the UEFI network stack and formally transferring the final network control responsibilities to the ready iPXE driver.

[0139] 5. When the UEFI executes the exit mechanism of the native DHCPv6 driver, it strictly follows the RFC 8415 specification:

[0140] 1) Construct a RELEASE message containing an Identity Association Identifier (IAID) and a Device Unique Identifier (DUID).

[0141] The driver first assembles a DHCPv6 RELEASE message in memory that conforms to the RFC 8415 standard. The message must contain the key identification fields: IAID (Identity Association Identifier), indicating the specific address lease to be released; and DUID (Device Unique Identifier), used to uniquely identify the client device to the server.

[0142] 2) Set the transaction ID (xid) to match the previous session.

[0143] From the context of the previous successful DHCPv6 session, obtain the unique transaction ID for this session. Set the obtained transaction ID to the corresponding field in the newly constructed RELEASE message. This is crucial to ensure that the PXE server can correctly associate this release request with the original address allocation session and process it.

[0144] 3) Send through UDPv6 port 547 to All_DHCP_Relay_Agents_and_Servers (FF02::1:2), wait for PXE server to return a DHCPv6 REPLY message and update BIOS's UDPv6 state information.

[0145] The assembled RELEASE message is sent through UDPv6 protocol from the client's 547 port to the target address FF02::1:2 (the link-local multicast address of all DHCPv6 relay agents and servers). After the message is sent, the driver enters a waiting state, expecting to receive a DHCPv6 REPLY confirmation message from the server in reply through port 546. Once a valid reply is received, the driver updates the BIOS's internal UDPv6 protocol state information to reflect that the address has been successfully released.

[0146] 6) During the waiting for the reply process, the system faces multiple levels of resource competition, which can cause UEFI to fail to successfully obtain the DHCPv6 REPLY message through the network card and update the BIOS's UDPv6 state information, resulting in a deadlock phenomenon in the IPv6 PXE startup process:

[0147] Network card event handling level: The iPXE driver registered ISR (Interrupt Service Routine) will preempt the UEFI Polling (polling) cycle; since both TPLs are set to TPL_CALLBACK (0x08), the data packet is lost.

[0148] When the UEFI firmware continuously checks whether the network card has data through Polling (polling), the loaded iPXE driver registers an interrupt service routine in the system. When the DHCPv6 REPLY message arrives at the network card and triggers an interrupt, since the iPXE ISR and the UEFI polling cycle are at the same task priority, the iPXE ISR will preempt the execution right. This causes the message that should be handled by the UEFI stack to be incorrectly intercepted or directly discarded by the iPXE stack, causing the UEFI polling cycle to never receive the expected message.

[0149] Memory management level: UEFI uses BootServices (start-up services) to allocate network buffers; iPXE may use its own memory pool management; buffer ownership conflicts cause message loss.

[0150] The UEFI network stack uses its BootServices to allocate and manage memory buffers for storing network packets. While the iPXE driver is initializing and taking over the hardware, it establishes its own independent memory pool to manage network buffers. When iPXE starts resetting the network card and reconfiguring the DMA engine, the buffer held by UEFI becomes ambiguous in ownership, and it can be recycled or marked as invalid by iPXE. Therefore, even if the packet successfully reaches the host memory, it can be invalid due to being written into an "unclaimed" or overwritten buffer, causing UEFI to fail to read correctly.

[0151] To solve the problem that the UEFI DHCPv6 driver cannot normally receive the DHCPv6 REPLY packet due to resource competition during the uninstallation triggered by the iPXE driver loading, a monitoring timer independent of the UEFI event polling cycle is started after the DHCPv6 RELEASE packet is sent, a parallel monitoring mechanism is established, and the monitoring timer timeout event and network reply packet event are monitored. When the timeout occurs and no reply packet is received, the system automatically triggers the retransmission process of the DHCPv6 release packet, and controls the number of times by a retransmission counter. After reaching the preset maximum number of retransmissions, the system forcibly terminates the waiting process, and completes the handover of network control to the iPXE driver. By setting a dynamically reentrant callback function architecture, the uninstallation process of the UEFI DHCPv6 driver is reconstructed, and a double-channel retransmission and exit mechanism is established. The architecture changes the traditional linear execution process into an intelligent retransmission system with state retention capability, realizes the reliable recovery capability of the uninstallation process under the premise of maintaining the protocol specification. First, through the independent monitoring channel and intelligent retransmission mechanism, the system deadlock problem caused by task priority competition is effectively solved, and the success rate of IPv6 PXE startup is significantly improved. Second, the double-channel monitoring architecture ensures that the system can recover from the deadlock state under any abnormal condition, greatly enhancing the robustness of the system. Finally, the forced exit mechanism provides a final guarantee for the control right handover, ensuring that the startup process can be reliably completed under any network condition.

[0152] Please refer to Figure 3 , Figure 3 A PXE environment connection diagram is shown, as Figure 3 shown, a PXE client (a server to be deployed), a PXE server, and network infrastructure constitute. A plurality of PXE clients are connected to the PXE server through a network switch (Switch), forming a local area network (LAN).

[0153] PXE server is usually integrated with DHCPv6 service and TFTP / HTTP boot service (file service). After the PXE client is powered on, its network card will broadcast a request in the network. The request is captured by the PXE server, then the server allocates an IPv6 address to the client through the DHCPv6 protocol and informs the location of the boot file (NBP), and finally the client downloads and executes the boot file through the TFTP or HTTP protocol, thereby starting the installation or booting process of the operating system. That is, the client obtains the required resources and configuration for booting from a remote server through the network instead of the local disk when PXE booting.

[0154] Referring to Figure 4 , Figure 4 The PXE server architecture is shown in FIG. 1. As shown in FIG. 1, the PXE server architecture includes a PXE server, which carries a DHCPv6 service (IPv6 Dynamic Host Configuration Protocol service), a file storage service, and a network interface layer. Figure 4

[0155] The PXE server can be deployed on a physical machine or a virtual machine. Its core consists of two service components working together: a DHCPv6 service and a file service, wherein the DHCPv6 service is responsible for processing the dynamic address allocation request of the client. The file service (TFTP / HTTP Boot) is responsible for storing and transmitting network boot program (NBP) and operating system image files to the client. The DHCPv6 service and the file storage service can be deployed on the same physical server, or can be associated through configuration (such as the DHCPv6 service specifying the address of the file server and the boot file path in the response).

[0156] The DHCPv6 service listens to the DHCPv6 request (Solicit / Request) of the client, and responds with a message containing an IPv6 address, a next-hop server address (Option 59), and a boot file URL (Option 60). The file service receives the file transfer request initiated by the client according to the information in the DHCPv6 response, and sends the required NBP (such as iPXE.efi) or kernel image to the client. The PXE server architecture is the environmental background of the problem, and its DHCPv6 service needs to correctly receive and process the DHCPv6 RELEASE message issued by the UEFI stack of the client, and reply with a REPLY message.

[0157] Referring to Figure 5 , Figure 5 The PXE client architecture is shown in FIG. 5. As shown in FIG. 5, the PXE service client carries out PXE booting through an IPv6 network in a UEFI BIOS environment, which is divided into four logical stages: hardware initialization, network configuration, file download, and system takeover.​

[0158] Wherein, the hardware initialization includes: the firmware initialization: after the computer is powered on, the UEFI firmware first performs self-check and hardware initialization. The UEFI BIOS environment is established: the UEFI driver and service are loaded, and the running environment is provided for subsequent operation. The network card ROM is loaded: the PXE firmware code on the network card is executed, and the network start capability is enabled. The SNP network protocol stack is initialized: the simple network protocol under the UEFI environment is loaded, which is the basis for network communication. The PCIE UNDI driver is loaded: the network card hardware is standardizedly controlled through the general network device interface driver. The UEFI network protocol stack is constructed: the complete UEFI network service is finally established, and the network configuration in the next stage is prepared.

[0159] The network configuration includes: the UEFI DHCPv6 client starts: the DHCPv6 client running in the UEFI environment starts working. The SOLICIT message is sent: the client broadcasts the DHCPv6 request to the network, and looks for the available server. The ADVERTISE / REPLY message is processed: the advertisement and confirmation messages returned by the DHCPv6 server are received and processed. The communication through the UDPv6 port 546-547 is completed: the whole communication interaction between the client and the DHCPv6 server is completed. The OPTION_BOOTFILE option is parsed: the URL address of the next boot file (NBP) to be downloaded is parsed from the reply of the server.

[0160] The file download includes: the NBP file is downloaded: according to the URL obtained in the previous stage, the network boot program such as iPXE or GRUB2 is downloaded through the TFTPv6 or HTTPv6 protocol. The iPXE / GRUB2 is loaded: the more powerful boot program is loaded and run in the client memory, so as to support more complex operation and protocol. The kernel and initrd are obtained: according to the configuration, the boot program continues to download the kernel image and initial memory disk of the operating system through the TFTPv6 or HTTPv6 protocol. The IPv6 GUA / ULA address communication is used: in the whole file download process, the client uses the IPv6 global unicast address or unique local address obtained in the second stage to communicate with the server.

[0161] The system takeover includes: drive loading and iPXE drive takeover: loading a custom network driver (such as an iPXE driver) with better performance, and preparing to take over network control. Uninstall the native UEFI driver: actively close and uninstall the native network driver with poor performance or compatibility provided by UEFI. Reconfigure the network card DMA engine: reconfigure the direct memory access engine of the network card to optimize data transmission efficiency and prepare for the operating system to take over the hardware. Call the ExitBootServices function: formally inform the UEFI firmware boot service that the service is over, and after that, the operating system kernel will fully take over the control of the hardware. SNP protocol reload: reinitialize the network protocol stack in the new driver environment to ensure the continuity and stability of the network function before the operating system starts.

[0162] The PXE boot process includes four core stages: first, in the address acquisition stage, the client obtains network configuration and boot parameters from the server through the DHCPv6 four-step handshake (Solicit-Advertise-Request-Reply); then in the program loading stage, the client downloads the network boot program through the TFTP / HTTP protocol according to the obtained information; then enters the critical control transfer stage, when the iPXE program is loaded and ExitBootServices() is called, the system is in a waiting deadlock due to task priority competition when sending an address release request and waiting for a confirmation reply; finally, in the boot stage, after successfully solving the deadlock, the iPXE driver reconfigures the network and loads the operating system image to complete the boot.

[0163] In this application, the DHCPv6Stop function is systematically reconstructed, and the traditional linear execution process is transformed into an intelligent retransmission mechanism with fault tolerance. This implementation solves the reliability problem of IPv6 address release in the UEFI environment through hierarchical design, and the main technical improvements include the following key aspects:

[0164] 1. Modularization and state machine design: decouple the original rigid sequential execution process into an independent callback function using the state machine mode. This function clearly defines five core states: initialization state, sending state, listening state, retransmission state, and termination state: Set the initialization state: preliminary work, set the 5-second initial timer and reset the retransmission counter. Set the sending state: construct and send a DHCPv6 release packet that meets the RFC8415 standard. Set the listening state: wait for the server's response through the event notification mechanism of the UEFI network protocol stack. Set the retransmission state: handle the timeout event and execute the intelligent retransmission strategy. Set the termination state: complete resource cleanup and final transfer of control, so that the entire release process becomes a robust process that can be traced back and recovered.

[0165] 2. Intelligent timing and retransmission strategy: A set of intelligent timer system is introduced to dynamically manage the timeout waiting. The strategy is to set the first waiting time as 5 seconds, and if timeout occurs, the interval time of each subsequent retransmission will be increased. This step-by-step back-off approach effectively avoids exacerbating the network congestion while providing more ample time for system recovery.

[0166] 3. Dual protection and control logic: To ensure foolproof, the system maintains a set of dual protection mechanisms: by strictly limiting the maximum number of retransmissions to 3 times through a retransmission counter, to prevent infinite loops. And before each retransmission, the consistency of key information such as transaction ID, server identification, etc. is strictly verified to ensure that each retransmission is effective and correct. At the same time, explicit termination conditions are set. Once the response is successfully received, the retransmission limit is reached, or the iPXE driver is detected to be abnormal, the system will immediately terminate the waiting, forcibly exit the polling loop, clean up the protocol stack state, and hand over control to iPXE, thereby completely breaking the deadlock situation.

[0167] In this way, by modularizing the release process into an intelligent state machine and supplemented by adaptive retransmission strategies and robust protection mechanisms, IPv6 PXE address release is transformed from a fragile link into a highly reliable, self-fault-tolerant robust process.

[0168] The execution process in this application is deeply optimized and reconstructed, forming three stages of clear, logical workflow: In the initialization stage, the system first completes the construction of the basic environment, including registering key callback functions, allocating dedicated storage for persistent protocol state, and starting the first round of monitoring timer, laying the foundation for subsequent fault-tolerant processing. After entering the core polling phase, the process first sends a DHCPv6 RELEASE packet, and then enters an event-driven waiting loop. In this loop, the system monitors two major event sources: network response and timer. When a timeout event occurs, the system will not be blocked, but will activate intelligent processing logic to dynamically decide whether to initiate retransmission or execute subsequent strategies, ensuring that the process always moves forward. Finally, in the termination processing stage, the system performs perfect end-of-process operations: thoroughly cleaning up the network buffer to prevent resource leakage, strictly verifying whether the network control has been completely handed over to the iPXE driver, and writing key debugging information to the log. This closed-loop design ensures that no matter what path the process completes, the system can reach a stable, predictable final state.

[0169] The embodiment of the application provides a pre-boot execution environment starting device, and the pre-boot execution environment starting device specifically like Figure 6 as shown, the pre-boot execution environment starting device comprises a starting module 20, a monitoring module 21, a sending module 22 and an execution module 23.

[0170] The starting module 20 is configured to start a monitoring timer independent of a target event polling operation in response to a first network driver loading trigger target uninstallation procedure caused by a second network driver, and the first network driver has sent a network release message in the target uninstallation procedure.

[0171] The monitoring module 21 is configured to monitor a timeout event of the monitoring timer and a network reply message event in response to the monitoring timer being started.

[0172] The sending module 22 is configured to trigger the first network driver to resend the network release message in response to the timeout event being monitored and the network reply message event not being monitored.

[0173] The executing module 23 is configured to forcibly terminate the target event polling operation and transfer network control from the first network driver to the second network driver in response to a number of times of resending the network release message exceeding a preset retransmission threshold, so that the second network driver takes over and continues to execute a starting procedure of the pre-start execution environment based on a network protocol stack of the second network driver.

[0174] As shown in Figure 7 The embodiment of the present application further provides a computer device, including a memory and a processor, the memory stores a computer program, and the processor is arranged to run the computer program to execute steps in any of the above-mentioned starting method embodiments of the pre-start execution environment.

[0175] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program, and the computer program is arranged to execute steps in any of the above-mentioned starting method embodiments of the pre-start execution environment when running.

[0176] In an example embodiment, the above-mentioned computer readable storage medium can include but is not limited to: a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0177] Those skilled in the art will further realize that the mere concepts, teachings, and embodiments described herein are merely meant to provide an enabling description of the applications and are not intended to limit the scope of the applications. Therefore, embodiments or examples described herein are not meant to be limiting, but merely to aid in the understanding of the overall more complete disclosure of the applications. Accordingly, those skilled in the art will recognize that modifications and variations of the more complete description herein can be resorted to without departing from the spirit and scope of the applications. Therefore, it is intended that the applications encompass all such modifications and variations as fall within the scope of the applications. All articles, patents, and other publications that have been cited herein are incorporated herein by reference for the teachings relevant to the sentence and / or paragraph in which the article, patent, and / or publication is mentioned.

[0178] The above has carried on the detailed introduction to the starting method of the pre-start execution environment provided by the application. The principle and implementation mode of the application are described by applying specific examples in the present article. The above example description is only applicable to help understand the method and core idea of the application. It should be pointed out that for the ordinary skilled in the art, some improvements and modifications can be made to the application without departing from the principle of the application. These improvements and modifications also fall within the protection scope of the application.

Claims

1. A method for starting a pre-boot execution environment, characterized in that, The startup method of the pre-boot execution environment includes: In response to the first network driver triggering a target unloading process due to the loading of the second network driver, and the first network driver having sent a network release message during the target unloading process, a monitoring timer independent of the target event polling operation is started. The target event polling operation is an event polling operation that is blocked due to competition with the task priority of the second network driver after the first network driver sends the network release message and waits for the network reply message corresponding to the network release message. The interrupt response of the monitoring timer is not affected by the task priority level of the first network driver. Create a dedicated event wait loop, and set timeout events and network reply message events to have the same processing priority in the dedicated event wait loop; Within the dedicated event waiting loop, it simultaneously waits for a timeout event triggered by the monitoring timer and a network reply message event triggered by the network interface; In response to the detection of the timeout event and the absence of the network reply message event, the first network driver is triggered to resend the network release message; In response to the number of times the network release message is retransmitted exceeds a preset retransmission threshold, the target event polling operation is forcibly terminated, and network control is transferred from the first network driver to the second network driver, so that the second network driver can take over and continue to execute the startup process of the pre-boot execution environment based on its own network protocol stack; The process of transferring network control from the first network driver to the second network driver includes: Extract the digital signature data and the issuer key identifier from the preset option field of the target network release message to be verified; Based on the issuer key identifier, query the list of trusted public keys pre-stored in the firmware non-volatile storage area to obtain the verification public key that matches the issuer key identifier; Using the verification public key, a digital signature verification operation is performed on the payload portion of the target network release message, wherein the payload portion is the original data portion in the target network release message used to calculate the digital signature; In response to the successful digital signature verification operation, it is determined that the target network release message is complete and has a trustworthy source, and the step of transferring network control to the second network driver is executed; In response to the failure of the digital signature verification operation, it is determined that the target network release message is at risk of tampering or has an abnormal source, and the transfer process of network control is interrupted, a security audit event is recorded, and a security recovery process for the first network driver is triggered.

2. The startup method for the pre-boot execution environment according to claim 1, characterized in that, The step of starting a monitoring timer independent of the target event polling operation in response to the first network driver triggering the target unloading process due to the loading of the second network driver, and the first network driver having sent a network release message during the target unloading process, includes: During the initialization of the target unloading process, a dedicated storage area is configured to persistently save the protocol context of the current network session. The network session is the entire process of the first network driver sending a network release message and receiving a network reply message corresponding to the network release message. The protocol context includes key parameters used to uniquely identify this session, the client device, and the network resources to be released. The key parameters include a transaction identifier and a device unique identifier. Call the firmware interface to create a monitoring timer based on a hardware clock source; In response to the completion of the network release message transmission, the monitoring timer is initialized and started, and the timeout period of the monitoring timer is set to the initial threshold.

3. The startup method for the pre-boot execution environment according to claim 1, characterized in that, The step of triggering the first network driver to resend the network release message in response to the detection of the timeout event and the absence of the network reply message event includes: In response to the timeout event being triggered within the dedicated event wait loop, check whether a valid network reply message has been received at the timeout event was triggered or within the dedicated event wait time. In response to the failure to receive a valid network reply message, it is determined that the timeout event has been monitored and the network reply message event has not been monitored. The value of the retransmission counter is incremented, and the retransmission counter is used to record the number of times the first network driver retransmits the network release message; Determine whether the current value of the retransmission counter is less than or equal to the preset retransmission threshold; In response to the current value of the retransmission counter being less than or equal to the preset retransmission threshold, a preset callback function is invoked, and the dedicated storage area is accessed through the preset callback function to obtain the protocol context of the network session persistently stored in the dedicated storage area. The preset callback function reconstructs and sends a target network release message that is semantically consistent with the first network release message sent, based on the protocol context of the network session.

4. The startup method for the pre-boot execution environment according to claim 3, characterized in that, The preset callback function, based on the protocol context of the network session, reconstructs and sends a target network release message semantically consistent with the initially sent network release message, including: The preset callback function reconstructs the network release message based on the protocol context of the network session; Read the initial network session protocol context saved when the network release message was first sent from the dedicated storage area; Determine whether the transaction identifier and device identifier in the reconstructed network release message match the initial network session protocol context; In response to the transaction identifier and device identifier in the target network release message matching the initial network session protocol context, the reconstructed network release message is retransmitted as the target network release message.

5. The startup method for the pre-boot execution environment according to claim 4, characterized in that, The step of retransmitting the reconstructed network release message as the target network release message includes: The target network release message sending time is calculated based on network latency, network latency weight coefficient, link latency parameters, network link speed, estimated size of the target network release message, link transmission weight coefficient, server load coefficient, minimum timeout protection time, last network release message sending time, and the sending time calculation formula. The target network release message is sent based on the target network release message sending time, and the target timeout time of the monitoring timer corresponding to this target network release message sending is updated according to the target network release message sending time.

6. The startup method for the pre-boot execution environment according to claim 5, characterized in that, The formula for calculating the transmission time is expressed as follows: ； Among them, T n Indicates the target network release message sending time, RTT base K represents the network delay during the network release message process. rtt The network latency weighting coefficient is represented by L, the link latency parameter is represented by LinkSpeed, the network link speed is represented by S, and the estimated size of the target network release packet is represented by K. link T represents the link transmission weight coefficient, ServerLoad represents the server load coefficient, and T represents the link transmission weight coefficient. min T represents the minimum timeout protection time. n-1 This indicates the time when the last network release message was sent.

7. The startup method for the pre-boot execution environment according to claim 1, characterized in that, The step of forcibly terminating the target event polling operation and transferring network control from the first network driver to the second network driver in response to an operation that retransmits a network release message more than a preset retransmission threshold includes: The number of times the network release message is retransmitted is obtained. In response to the number of times the network release message is retransmitted exceeding a preset retransmission threshold, the target event polling operation driven by the first network is forcibly interrupted. Iterate through the network buffer pool held by the first network driver and release the network buffer pool; Query the network protocol instances registered by the second network driver through the protocol interface installation service; In response to the fact that both the initialization state and the operation state of the network protocol instance are valid, it is determined that the network protocol interface of the second network driver is in a ready state, and network control is transferred from the first network driver to the second network driver.

8. The startup method for the pre-boot execution environment according to claim 1, characterized in that, Before forcibly terminating the target event polling operation, the following steps are also included: Identify the network session corresponding to the network release message that has been sent but has not received a valid network reply message, which corresponds to the first network driver; Perform resource cleanup operations on the identified network sessions, including releasing the network buffer occupied by the identified network sessions and deregistering the monitoring timers corresponding to the identified network sessions.

9. The startup method for the pre-boot execution environment according to claim 1, characterized in that, The forced termination of the target event polling operation includes: Generate a network session diagnostic report, which includes: the number of network release messages sent, the number of invalid network reply messages received, the number of task priority conflicts, and network link quality indicators. The number of task priority conflicts is the cumulative number of network reply messages lost due to task priority competition between the first network driver and the second network driver when the timeout event of the monitoring timer is triggered. The diagnostic report is sent to a remote log server or local persistent storage; Based on the diagnostic report, determine whether to trigger a network driver version rollback.

10. The startup method for the pre-boot execution environment according to claim 9, characterized in that, The determination of whether to trigger a network driver version rollback includes: In response to triggering a network driver version rollback, the system queries a pre-configured driver version repository for a historical version driver that is compatible with the current primary network driver. Use the image file driven by the previous version to overwrite the image file of the current first network driver; Reset the configuration parameters of the first network driver to their initial default values; The first network driver is reinitialized, and the network release message sending process is retried based on the reset configuration parameters.

11. A computer device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the startup method of the pre-boot execution environment as described in any one of claims 1 to 10 when executing the computer program.

Images