Method and device for secure updating of embedded operating system firmware hot patches

Abstract

The application discloses a kind of methods and devices for embedded operating system firmware hot patch security update, the method includes: when system starts, load firmware from system running area, and establish a set of global function jump table in system memory;For specified vulnerability or function update, make micro patch package, after the running equipment of the system receives the patch package, after source authentication and integrity check pass, the patch package is decompressed, and the new function code therein is loaded into the reserved update area;For the target function to be replaced, set the target function to a safety point when it is not currently called by any task and does not exist in the call stack of any task, and perform remapping operation through update manager when reaching the safety point;After remapping is completed, all subsequent calls to the function function jump to the new function in the update area for execution.The application can greatly improve the operation and maintenance efficiency and network security protection capability of critical infrastructure.

Description

Technical Field

[0001] This invention relates to the field of embedded system security maintenance technology, specifically to a method and apparatus for secure hot patching of embedded operating system firmware to implement hot patching technology for operating system kernel or firmware functions on mission-critical devices. Background Technology

[0002] In today's Internet of Things (IoT) and critical infrastructure sectors, such as power metering terminals in smart grids, industrial controllers (PLCs) in SCADA systems, and 5G communication base stations, once equipment is put into operation, it often requires extremely high continuous service availability.

[0003] Traditional firmware updates (Firmware Over-The-Air, FOTA) or operating system (OS) updates typically use an "A / B partition" or "download-install-reboot" model, in which: (1) Reboot Update Mode: This is the most common method. The system downloads the complete firmware package, verifies it, writes it to non-volatile memory (such as Flash), and then performs a system reboot. During the reboot process, the core functions of the device (such as electricity metering, communication connection, and data acquisition) will be completely interrupted. For electricity metering devices, this means the loss of electricity data; for communication devices, this means connection interruption and service shutdown. Such interruption is unacceptable in many scenarios.

[0004] (2) A / B partition mode: This is an improved solution. The system has two identical firmware partitions (A and B). Assuming that it is currently running in A, the update package will be downloaded to B. After the download is completed, the system will restart and start from B. This method shortens the "unavailable" time, but still requires a short restart switch, and the core business will still be interrupted.

[0005] With the increasing severity of cybersecurity threats, once a high-risk vulnerability (such as a remote code execution vulnerability) is exposed in the operating system kernel or critical communication module (such as the TCP / IP protocol stack) of critical equipment, it must be patched as soon as possible. However, the business interruption caused by traditional update methods puts the operation and maintenance party in a dilemma: either tolerate the security risks or bear the losses caused by the business interruption.

[0006] Therefore, the industry urgently needs a secure update technology that can perform "surgical" repairs on running operating systems or critical tasks without interrupting core business or restarting the system, namely hot patching technology.

[0007] To address this issue, this application proposes a method and apparatus for secure hot patching of embedded operating system firmware to solve the technical problem that devices such as smart meters, industrial controllers, and communication base stations, which require 24 / 7 uninterrupted operation, cannot perform system updates without interrupting their core business (such as electricity metering, real-time communication, and industrial control) when faced with security vulnerabilities or functional defects. Summary of the Invention

[0008] The main objective of this invention is to provide a method and apparatus for secure hot patching of embedded operating system firmware, which constructs a seamless and highly reliable online security update mechanism that can greatly improve the operational efficiency of critical infrastructure and network security protection capabilities, thereby solving the technical problem in the background art that system updates must interrupt core business operations.

[0009] The present invention solves the above-mentioned technical problems by adopting the following technical solutions: A method and apparatus for secure hot patching of embedded operating system firmware, comprising the following steps performed via a computer device: When the operating system starts, it loads the firmware from the system runtime area and establishes a set of global function jump tables in memory; A set of micro-patches is created for a specified vulnerability or feature update. The micro-patches contain only the binary code of the modified or added function modules and the corresponding remapping metadata. After the operating system's running device receives the patch package, it decompresses the patch package after the source authentication and integrity verification are passed, and loads the new function code into the reserved update area (an independent storage area not occupied by running code, which can be RAM or Flash). For a target function that is about to be replaced, set a safe point when the target function is not currently called by any task and does not exist in the call stack of any task. When the safe point is reached, perform a remapping operation through the update manager: atomically modify the pointer of the corresponding entry in the function jump table, changing it from pointing to the old function address in the runtime area to pointing to the new function address in the update area. After the remapping is completed, all subsequent calls to the target function will jump to the new function in the update area for execution. The old function code still exists in the runtime area, but it will no longer be called.

[0010] Preferably, the function jump table is used during the firmware compilation and linking stage to identify all functions marked as hot-updateable using a compiler or a post-processing script. All calls to functions that need to support hot updates in the system query the function jump table through a set of pointers to indirect calls to obtain the target address, and then perform a jump operation to the physical address of the function. Preferably, the function jump table is set as a pointer array, for the first function in the system... A hot-updateable function The address of the corresponding pointer entry in the jump table Set to:

[0011] Set to 4 bytes on a 32-bit operating system and 8 bytes on a 64-bit operating system; During initialization, address The location was written Original address in the system runtime area The operational formula is as follows:

[0012] in, This is the memory base address of the jump table. For the first A unique identifier for a hot-updateable function (usually an integer index, typically a consecutive integer index starting from 0). Store the first in the jump table The address of each function pointer entry. For the first The original physical address of each function in the system runtime area.

[0013] Preferably, the micro-patch package is configured as a set of binary files, which contain function body binary code and metadata header. The metadata header is used to describe the firmware baseline version that the patch depends on, the function body content protected by the patch, the ID or index of each new function in the jump table, the size of the new function, the security hash value of the new function, and the digital signature of the micro-patch package. The source authentication and integrity verification of the micro-pattern package are achieved through a pre-set public key verification signature to ensure that the patch has not been tampered with and that its source is trustworthy. After the verification is passed, a set of patch managers extracts the function bodies in the patch package one by one and copies them to the reserved update area.

[0014] The update area is set to a RAM area or a Flash area that is dynamically mapped to RAM during loading; After the function body is extracted and copied, the patch manager verifies the hash value of the micro-patch package code loaded into the update area to ensure that it is consistent with the hash value in the metadata.

[0015] Preferably, the formula for calculating the hash value of the micro-patch package code is:

[0016] in, The hash value of the entire micro-patch package, which contains metadata and new function bodies. Metadata used to describe information about the patch package, For the new function binary machine code, This represents the concatenation of binary data; The digital signature of the micro-pattern package is based on the hash value of the micro-pattern package code. Use the server's asymmetric encryption private key Generate, have:

[0017] in, This is the hash value of the micro-patch package code.

[0018] Preferably, the source authentication and integrity verification process after the operating device of the system receives the micro patch package includes: For the final distributed security patch package, the system's running devices calculate the received metadata. and binary machine code hash value ,have:

[0019] The device uses a server public key pre-installed in the Secure Element (SE) or OTP (One-Time Programmable) zone. Digital signatures To perform decryption verification, the following steps are required:

[0020] when When the signature is valid and the hash matches, the verification passes.

[0021] Preferably, after the micro-patch package passes verification, a set of patch managers is used to generate the binary machine code of the micro-patch package. Allocate memory in the update area to enable the loading of patches there, including: Set the base address of the update region (the starting physical address of the update region in the memory map) to... And the current area's used spatial offset is Then the new function The physical address to which the new function is loaded (Actual starting address in memory after being loaded) for: ; Check boundaries before loading to ensure the update region is updated. It will not overflow; the inspection criteria are as follows: ,in, It is from the metadata of the micro patch package. The size of the new function read from it; After the patch is loaded in the update area, the update will begin. ,have:

[0022] in, For the new function The size of the binary code, This represents the total available space size in the update area.

[0023] Preferably, for each safe point, a set of atomic counters is associated with each group of hot-updateable functions. .

[0024] When specifying a task Calling hot-updateable functions via jump table Increment by 1, indicating an operation to be performed: , This is represented as an atomic increment operation; When specifying a task From the hot-update function Decrement by 1 upon return, indicating an operation was performed: , This is represented as an atomic decrement operation; There is a safe point when the atom counter is 0. The conditions for use are: Simultaneously set a set of patch lock flags. ,have: If the patch locks the flag If the settings are successful, it will be safe. Achieved; Then, for the hot-update function Perform the update operation, and in subsequent tasks call the hot-updateable function via a jump table. Prioritize checking the patch lock flag. ,like Then wait Reset the success / lock flag to release or return an error.

[0025] Preferably, before each remapping operation, the task scheduling list of the operating system kernel is checked to ensure that the module (or task) to which the function to be updated belongs is currently in a "dormant" or "waiting" state, rather than a "running" or "ready" state.

[0026] Preferably, for high-risk kernel function updates, all other tasks are paused (for a very short time window, such as a few milliseconds, without affecting the metering) by a set of update managers, and the call stacks of all tasks are quickly scanned to confirm that the address of the old function is not in any stack frame.

[0027] Preferably, the specific operation flow of the remapping operation includes: Through patch metadata The target function that needs to be updated The ID is set to The new function will be loaded into the update area. Load address set to ; Calculate the address of the entry in the jump table The calculation formula is as follows: ; It is set to 4 bytes on a 32-bit operating system and 8 bytes on a 64-bit operating system. This is the memory base address of the jump table, belonging to the firmware baseline version. For function ID; Performing an atomic write operation redirects the pointer, resulting in: ,in, This is an atomic write operation, used to ensure that pointer updates are completed within a single CPU instruction cycle and cannot be interrupted; And immediately release the locking flag after the remapping is complete. : .

[0028] In another aspect, the present invention also discloses an apparatus for hot patching security updates of embedded operating system firmware, configured as a system device for performing any of the above-described methods for hot patching security updates of embedded operating system firmware, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method for hot patching security updates of embedded operating system firmware as described above.

[0029] As can be seen from the above technical solution, the present invention provides a method and apparatus for secure hot patching and updating of embedded operating system firmware. Compared with the prior art, the present invention has the following advantages: 1. By employing hot patching technology, waiting for "safe points," and atomic write operation remapping jump tables, this invention can achieve zero interruption of core functions of power metering and communication, thereby avoiding the data loss and network disconnection problems caused by the 30-45 second interruption of core functions in traditional FOTA updates.

[0030] 2. This invention, by designing a tiny patch package containing only the parse_command function, can greatly save network bandwidth and storage space, thereby avoiding the problem of traditional complete firmware packages consuming a lot of resources.

[0031] 3. By optimizing the update process of downloading, verifying, and remapping, this invention can shorten the vulnerability repair time and avoid the problem of prolonged vulnerability exposure caused by the long repair cycle of traditional updates.

[0032] 4. By adopting an update method that does not change the system's operating state, this invention can significantly improve system stability, thereby avoiding the operational risks of potential restart failures in traditional updates.

[0033] It should be understood that the descriptions in this section are not intended to identify key or essential features of embodiments of the invention, nor are they intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Of course, implementing any product of the invention does not necessarily require achieving all of the advantages described above simultaneously. Attached Figure Description

[0034] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a schematic diagram of the process of the present invention; Figure 2 This is a schematic diagram of the micro-patch package system architecture. Detailed Implementation

[0035] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0036] For details in the embodiments, please refer to Figure 1 .

[0037] like Figure 1 As shown in the embodiment of the present invention, the method for secure hot patching of embedded operating system firmware includes the following steps: S1. Construct a calling framework based on a jump table. When the system starts up, the firmware is loaded from the "run area". During the firmware compilation and linking stage, the compiler or a post-processing script will identify all functions marked as "hot-patchable". At the same time, a global "function jump table" is established in memory. At this time, all calls to critical functions (functions that need to support hot updates) in the system do not jump directly to the physical address of the function, but instead obtain the target address by looking up this jump table before execution.

[0038] Specifically, direct calls to these "hot-updatable" functions will be replaced with indirect calls. For example, CALLFunction_A will be replaced with CALL[JumpTable + ID_Function_A×4]. Here, JumpTable is a pointer array stored in RAM that is guaranteed to be modifiable. During system initialization, this table is filled with the original physical addresses of all "hot-updatable" functions in the "run area". When the power metering task needs to call Function_A, it actually looks up the jump table, gets the address, and then jumps.

[0039] In a specific set of operational examples, the function jump table is set as an array of pointers. For the first function in the system... A hot-updateable function The address of the corresponding pointer entry in the jump table Set to:

[0040] It is set to 4 bytes on a 32-bit operating system and 8 bytes on a 64-bit operating system. This is the firmware baseline version. For function ID; During initialization, address The location was written Original address in the system runtime area The operational formula is as follows:

[0041] in, This is the memory base address of the jump table. For the first A unique identifier (usually an integer index) for each hot-updateable function. Store the first in the jump table The address of each function pointer entry. For the first The original physical address of each function in the system runtime area.

[0042] S2. Secure Reception and Verification of Patch Packages First, the monitoring center (server) creates a "micro-patch package" for specific vulnerabilities or feature updates. This patch package is a highly customized binary file containing only the binary code of the modified or added functions (or modules) and the corresponding remapping metadata. The device then receives the patch package from the update server via a secure channel and undergoes rigorous source authentication and integrity verification (such as ECC / RSA signature verification).

[0043] The remapping metadata here includes a "metadata" header. This header describes: the baseline firmware version that this patch depends on, which functions are included in the patch, the ID (or index) of each new function in the jump table, the secure hash (SHA-256) of the new functions, and the digital signature of the entire patch package.

[0044] At this point, the device must use a pre-set public key to verify the signature, ensuring that the patch has not been tampered with and that its source is trustworthy.

[0045] In a specific operational example, on the server side, the developer first locates the function that needs to be fixed. (Located in firmware version) Developers write new functions. And use a cross-compiler to compile it into binary code for the target platform. The server builds a patch package. Its structure is as follows Figure 2 As shown, it includes at least: (1) Metadata Firmware baseline version Function ID new function size New function hash }; (2) New function body ; (3) Digital signature ; At this time, the hash value of the micro patch code The calculation formula is:

[0046] in, The hash value of the entire micro-patch package, which contains metadata and new function bodies. Metadata used to describe information about the patch package, For the new function binary machine code, This represents the concatenation of binary data; Digital signature of micro-patches based on micro-patch code hash value Use the server's asymmetric encryption private key Generate, have:

[0047] in, This is the hash value of the micro-patch package code.

[0048] At this point, the source authentication and integrity verification process after the system device receives the micro patch package includes: For devices (such as smart meters), the final distributed security patch package is received via the communication module. (Include After that, the system device calculates the received metadata. and binary machine code hash value ,have:

[0049] The device uses a server public key pre-installed in the Secure Element (SE) or OTP (One-Time Programmable) zone. Digital signatures To perform decryption verification, the following steps are required:

[0050] when When the signature is valid and the hash matches, the verification passes.

[0051] S3. Secure loading of patches in the "Update Area" After verification, the device decompresses the patch package, and the patch manager extracts the function body code from the patch package one by one and copies it to the reserved "update area" storage space (an independent storage area not occupied by running code, which can be RAM or Flash).

[0052] The "update area" here can be a dedicated RAM block for the fastest execution speed, or a specific area of ​​Flash memory that is dynamically mapped to RAM during loading to save valuable RAM resources. After loading is complete, the manager will re-verify the hash value of the code loaded into the "update area" to ensure that it matches the hash value in the metadata, preventing errors during storage or copying.

[0053] In a specific operational example, after the micro patch package passes verification, a set of patch managers is used to generate the binary machine code of the micro patch package. Allocate memory in the update area to enable the loading of patches there, including: Set the base address of the update region (the starting physical address of the update region in the memory map) to... And the current area's used spatial offset is Then the new function The physical address to which the new function is loaded (Actual starting address in memory after being loaded) for: ; Check boundaries before loading to ensure the update region is updated. It will not overflow; the inspection criteria are as follows: ,in, It is from the metadata of the micro patch package. The size of the new function read from it; After the patch is loaded in the update area, the update will begin. ,have:

[0054] in, For the new function The size of the binary code, This represents the total available space size in the update area.

[0055] S4. Safe Point Detection and State Consistency Assurance During the operation of this application, the system will not switch immediately, but will wait for a "safe point". A safe point is when the target function (the old function that is about to be replaced) is not currently being called by any task and does not exist in the call stack of any task, to ensure that no task is forcibly replaced "halfway through execution".

[0056] This section employs a multi-dimensional detection mechanism to determine "safe points," which specifically includes at least the following multi-dimensional conditions: (a) Use a Usage Counter: Associate a counter with each hot-updateable function. The counter increments by 1 when the function is called and decrements by 1 when it returns. Only when the counter is 0 does it indicate that the function is not currently being used by any task; For example, for a safe point, a set of atomic counters is set up for each group of hot-updateable functions. .

[0057] When specifying a task Calling hot-updateable functions via jump table Increment by 1, indicating an operation to be performed: , This is represented as an atomic increment operation; When specifying a task From the hot-update function Decrement by 1 upon return, indicating an operation was performed: , This is represented as an atomic decrement operation; There is a safe point when the atom counter is 0. The conditions for use are: Simultaneously set a set of patch lock flags. ,have: If the patch locks the flag If the settings are successful, it will be safe. Achieved; Then, for the hot-update function Perform the update operation, and in subsequent tasks call the hot-updateable function via a jump table. Prioritize checking the patch lock flag. ,like Then wait Reset successfully or return an error to ensure the atomicity of the patch operation; (b) Task Status Inspection: Check the task scheduler list of the operating system kernel. Ensure that the module (or task) to which the function to be updated belongs is currently in a "dormant" or "waiting" state, rather than a "running" or "ready" state; For example, before each remapping operation, the task scheduling list of the operating system kernel is checked to ensure that the module (or task) to which the function to be updated belongs is currently in a "dormant" or "waiting" state, rather than a "running" or "ready" state. (c) Call stack scan (optional, for kernel-level patches): For high-risk kernel function updates, the update manager can even pause all other tasks (for a very short time window, such as a few milliseconds, without affecting the metering) and quickly scan the call stack of all tasks to confirm that the address of the old function is not in any stack frame.

[0058] S5. Atomized jump table remapping (the system performs the final switch when the "safe point" condition is met). Specifically, once a safe point is reached, the update manager performs the core "remapping" operation: in an atomic operation, it modifies the pointer of the corresponding entry in the "function jump table" from pointing to the old function address in the "run area" to pointing to the new function address in the "update area".

[0059] The specific operation process for remapping here includes: Through patch metadata The target function that needs to be updated The ID is set to The new function will be loaded into the update area. Load address set to ; Calculate the address of the entry in the jump table The calculation formula is as follows: ; Performing an atomic write operation redirects the pointer, resulting in: ,in, This is an atomic write operation, used to ensure that pointer updates are completed within a single CPU instruction cycle and cannot be interrupted; And immediately release the locking flag after the remapping is complete. : .

[0060] It should also be noted that the function replacement operation in this application must be atomic. The update manager then modifies the corresponding pointer in the JumpTable using a single, uninterruptible CPU instruction (such as the STR instruction). For example, the value of JumpTable[ID_Function_A] is changed from 0x10008000 (the address of the old function) to 0x4001A000 (the address of the new function in the update area). This process may only take a few CPU cycles, so fast that upper-layer applications (such as metering) are completely unaware of it.

[0061] S6. Update complete. After the remapping is complete, all subsequent calls to this function will automatically and transparently jump to the new function in the "update area" for execution. The old function code still exists in the "runtime area," but it will no longer be called. The entire process does not require a restart, and the core power metering and communication tasks continue to run.

[0062] Furthermore, through the above steps, the system completed the online repair of critical vulnerabilities without interrupting core business (electricity metering and communication), achieving true "hot patching".

[0063] And the call will be executed again in any task. At that time, it will no longer be blocked, and through similar logic to the above operation (i.e., CALL[A_ptr_f]), the CPU will obtain... The address will automatically jump to the new function in the "update area" for execution.

[0064] Based on the above operations, in further test descriptions, for a group of smart energy meters (model: Meter-X1000) operating on the network, their core functions are as follows: (1) Task A (Electricity Metering): High priority. Sample voltage and current every 10ms, calculate active power, and accumulate electrical energy; (2) Task B (Communication Task): Low priority. Responsible for TCP / IP communication with the main station and reporting power data every 15 minutes.

[0065] The following test scenario exists: A buffer overflow vulnerability was discovered in the `parse_command(uint8_t×buffer)` function, which is used to parse commands issued by the master station in communication task B of the electricity meter. An attacker could send a specially crafted data packet, causing the device to crash and stop metering.

[0066] The test plan at this time is: (A) Control group (traditional FOTA update): The vulnerability was fixed using the traditional firmware upgrade method (A / B partition reboot); (B) Invention Group (Hot Patch Update): Using the method of the present invention, hot patch updates are performed only on the parse_command function.

[0067] Based on the results of the above test scheme, the test metrics were constructed as follows: power metering interruption time (time when task A stopped running), communication interruption time (time when task B (TCP / IP connection) disconnected), and vulnerability repair time (time from receiving the patch package to the vulnerability repair taking effect). The following table compares the test results:

[0068] As shown in the table above, during the update process, the electricity metering task A in the control group was interrupted for as long as 30 seconds, which is a serious data loss in grid settlement.

[0069] In summary, throughout the entire process, the high-priority task A (electricity metering) remained running without losing any sampling data. Task B also remained online, achieving secure updates with zero interruption. Therefore, this application provides highly timely and reliable security maintenance capabilities without sacrificing system availability.

[0070] On the other hand, the present invention also discloses an apparatus for hot patching and security updating of embedded operating system firmware, configured as a system device for executing the method for hot patching and security updating of embedded operating system firmware in the above embodiments, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method for hot patching and security updating of embedded operating system firmware as described in the above embodiments.

[0071] In another aspect, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0072] In another aspect, the present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.

[0073] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform any of the embedded operating system firmware hot patch security update methods described in the above embodiments.

[0074] It is understood that the system provided in the embodiments of the present invention corresponds to the method provided in the embodiments of the present invention, and the explanation, examples and beneficial effects of the relevant content can be referred to the corresponding parts of the above methods.

[0075] This application also provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, communication interface, and memory communicate with each other via the communication bus. Memory, used to store computer programs; The processor, when executing a program stored in memory, implements the aforementioned method for secure hot patch updates of embedded operating system firmware.

[0076] The communication bus mentioned in the above-mentioned electronic devices can be a standard bus for interconnecting peripheral components or an extended industrial standard structure bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc.

[0077] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0078] The memory may include random access memory or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0079] The processors mentioned above can be general-purpose processors, including central processing units, network processors, etc.; they can also be digital signal processors, application-specific integrated circuits, field-programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0080] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, an optical medium, or a semiconductor medium, etc.

[0081] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0082] Furthermore, it should be noted that if any directional indication (such as up, down, left, right, front, back, etc.) is involved in the embodiments of the present invention, the directional indication is only used to explain the relative positional relationship and movement of each component in a specific posture. If the specific posture changes, the directional indication will also change accordingly.

[0083] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the meaning of "and / or" throughout the text includes three parallel solutions; for example, "A and / or B" includes solution A, solution B, or a solution where both A and B are satisfied simultaneously. Furthermore, in the embodiments of this invention, "multiple" refers to two or more. Moreover, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

Claims

1. A method for secure hot patching of embedded operating system firmware, characterized in that, include: When the system starts, the firmware is loaded from the system runtime area, and a set of global function jump tables is established in the system memory; A set of micro-patches is created for a specified vulnerability or feature update. After the system's running device receives the patch package, it decompresses the patch package after the source authentication and integrity verification are passed, and loads the new function code into the reserved update area. For a target function that is about to be replaced, set a safe point when the target function is not currently called by any task and does not exist in the call stack of any task. When the safe point is reached, perform a remapping operation through the update manager: atomically modify the pointer of the corresponding entry in the function jump table, changing it from pointing to the old function address in the runtime area to pointing to the new function address in the update area. After the remapping is completed, all subsequent calls to the target function will jump to the new function in the update area for execution.

2. The method for secure hot patching and updating of embedded operating system firmware as described in claim 1, characterized in that, The function jump table is used during the firmware compilation and linking stage to identify all functions marked as hot-updateable using a compiler or a post-processing script. All calls to functions that need to support hot updates in the system query the function jump table through a set of indirect call pointer arrays to obtain the target address, and then execute the function physical address jump operation.

3. The method for secure hot patching of embedded operating system firmware as described in claim 2, characterized in that, The function jump table is set as an array of pointers. For the first function in the system... A hot-updateable function The address of the corresponding pointer entry in the jump table Set to: It is set to 4 bytes on a 32-bit operating system and 8 bytes on a 64-bit operating system. For function ID; During initialization, address The location was written Original address in the system runtime area The operational formula is as follows: in, This is the memory base address of the jump table. For the first A unique identifier for a hot-updateable function. Store the first in the jump table The address of each function pointer entry. For the first The original physical address of each function in the system runtime area.

4. The method for secure hot patching and updating of embedded operating system firmware as described in claim 3, characterized in that, The micro-patch package is set as a set of binary files, which contain function body binary code and metadata header. The metadata header is used to describe the firmware baseline version that the patch depends on, the function body content protected by the patch, the ID or index of each new function in the jump table, the size of the new function, the security hash value of the new function, and the digital signature of the micro-patch package. The source authentication and integrity verification of the micro patch package are achieved through a pre-set public key verification signature to ensure that the patch has not been tampered with and that its source is trustworthy. After the verification is passed, a set of patch managers extracts the function bodies in the patch package one by one and copies them to the reserved update area. The update area is set to a RAM area or a Flash area that is dynamically mapped to RAM during loading; After the function body is extracted and copied, the patch manager verifies the hash value of the micro-patch package code loaded into the update area to ensure that it is consistent with the hash value in the metadata.

5. The method for secure hot patching of embedded operating system firmware as described in claim 4, characterized in that, The formula for calculating the hash value of the micro-patch package code is as follows: in, The hash value of the entire micro-patch package, which contains metadata and new function bodies. Metadata used to describe information about the patch package, For the new function binary machine code, This represents the concatenation of binary data; The digital signature of the micro-pattern package is based on the hash value of the micro-pattern package code. Use the server's asymmetric encryption private key Generate, have: in, This is the hash value of the micro-patch package code.

6. The method for secure hot patching of embedded operating system firmware as described in claim 5, characterized in that, The source authentication and integrity verification process of the system's operating equipment after receiving the micro-patch package includes: For the final distributed security patch package, the system's running devices calculate the received metadata. and binary machine code hash value ,have: The device uses a server public key pre-installed in the secure element or OTP zone. Digital signatures To perform decryption verification, the following steps are required: when The verification passed.

7. The method for secure hot patching and updating of embedded operating system firmware as described in claim 1, characterized in that, After successful verification, the micro-patch package uses a set of patch managers to generate the binary machine code for the micro-patch package. Allocate memory in the update area to enable the loading of patches there, including: Set the base address of the update area to And the current area's used spatial offset is Then the new function The physical address loaded for: ; Check boundaries before loading to ensure the update region is updated. It will not overflow; the inspection criteria are as follows: ,in, It is from the metadata of the micro patch package. The size of the new function read from it; After the patch is loaded in the update area, the update will begin. ,have: in, For the new function The size of the binary code, This represents the total available space size in the update area.

8. The method for secure hot patching and updating of embedded operating system firmware as described in claim 1, characterized in that, For each of the aforementioned safety points, a set of atomic counters is associated with each group of hot-updateable functions. ; When specifying a task Calling hot-updateable functions via jump table Increment by 1, indicating an operation to be performed: , This is represented as an atomic increment operation; When specifying a task From the hot-update function Decrement by 1 upon return, indicating an operation was performed: , This is represented as an atomic decrement operation; There is a safe point when the atom counter is 0. The conditions for use are: Simultaneously set a set of patch lock flags. ,have: If the patch locks the flag If the settings are successful, it will be safe. Achieved; Then, for the hot-update function Perform the update operation, and in subsequent tasks call the hot-updateable function via a jump table. Prioritize checking the patch lock flag. ,like Then wait Resetting was successful or returned an error.

9. The method for secure hot patching and updating of embedded operating system firmware as described in claim 1, characterized in that, The specific operation procedure for the remapping operation includes: Through patch metadata The target function that needs to be updated The ID is set to The new function will be loaded into the update area. Load address set to ; Calculate the address of the entry in the jump table The calculation formula is as follows: ; It is set to 4 bytes on a 32-bit operating system and 8 bytes on a 64-bit operating system. This is the memory base address of the jump table, belonging to the firmware baseline version. For function ID; Performing an atomic write operation redirects the pointer, resulting in: ,in, This is an atomic write operation, used to ensure that pointer updates are completed within a single CPU instruction cycle and cannot be interrupted; And immediately release the locking flag after the remapping is complete. .

10. An apparatus for hot-patching security updates of embedded operating system firmware, configured as a system device for performing the method for hot-patching security updates of embedded operating system firmware according to any one of claims 1 to 9, characterized in that, The device includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of a method for hot-patching and securely updating embedded operating system firmware as described in any one of claims 1 to 9.

Images