Code updating method and device of firmware and electronic equipment

Abstract

The application discloses a code updating method and device of firmware and electronic equipment. The method comprises the following steps: obtaining a target code package from a first cache area, wherein the first cache area is an area obtained by dividing a storage area of a controller; determining a first position of firmware original code in the first area and a second position corresponding to the first position in a second area; updating the firmware original code in the second area corresponding to the second position based on the target code package; in the case that the firmware original code in the second area is updated, switching to the second position of the second area to continue running and updating the firmware original code in the first area; and in the case that the firmware original code in the first area is updated, switching back to the first area to continue running according to the corresponding position. The application solves the technical problem of low updating reliability when updating the code of the firmware in the related art.

Description

Technical Field

[0001] This invention relates to the field of information security, and more specifically, to a firmware code update method, apparatus, and electronic device. Background Technology

[0002] In related technologies, firmware may develop security vulnerabilities, functional defects, or fail to meet the upgrade requirements of actual application scenarios during long-term operation, thus necessitating firmware code updates. However, updating firmware code in these technologies suffers from low update reliability.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This invention provides a firmware code update method, apparatus, and electronic device to at least solve the technical problem of low update reliability when updating firmware code in related technologies.

[0005] According to one aspect of the present invention, a firmware code update method is provided, comprising: obtaining a target code package from a first cache, wherein the first cache is a region divided from the storage area of ​​a controller; determining a first location of the firmware source code in the first region and a second location in a second region corresponding to the first location, wherein the second region is a backup running region of the first region and stores the same firmware source code as the first region; updating the firmware source code in the second region corresponding to the second location based on the target code package; when the firmware source code in the second region is updated, switching to the second location in the second region to continue running and updating the firmware source code in the first region; and when the firmware source code in the first region is updated, switching back to the first region to continue running according to the corresponding location.

[0006] Optionally, updating the firmware source code of the second region corresponding to the second position based on the target code package includes: loading the target code package into a second cache, wherein the second cache is isolated from the first cache; performing an integrity check on the target code package to obtain a check result, wherein the integrity check is used to check whether the code in the target code package was modified before being loaded into the second cache; determining an execution determination result for whether to perform a code update operation based on the check result; and updating the firmware source code of the second region corresponding to the second position based on the target code package in the second cache if the execution determination result is to perform a code update operation.

[0007] Optionally, if the execution result is to perform a code update operation, updating the firmware source code of the second region corresponding to the second position based on the target code package in the second cache includes: splitting the code corresponding to the target code package to obtain multiple first code segments, wherein the multiple first code segments correspond to different functions; parsing the address configurations corresponding to the multiple first code segments from the target code package; retrieving the physical address parameters in the second region; establishing address mapping relationships between the multiple first code segments and the second region based on the address configurations corresponding to the multiple first code segments and the physical address parameters in the second region; and updating the firmware source code of the second region corresponding to the second position based on the multiple first code segments and the address mapping relationships between the multiple first code segments and the second region.

[0008] Optionally, before obtaining the target code package from the first cache, the method further includes: identifying the package identifier of the candidate code package in the first cache; determining whether the package identifier is a predetermined identifier, and obtaining an identifier determination result; and if the identifier determination result indicates that the package identifier is a predetermined identifier, using the candidate code package as the target code package.

[0009] Optionally, obtaining the target code package from the first cache includes: determining the code update conditions corresponding to the firmware; determining whether the current update conditions of the firmware meet the code update conditions based on the update detection area of ​​the firmware, and obtaining the condition determination result; and obtaining the target code package from the first cache if the current update conditions meet the code update conditions.

[0010] Optionally, before obtaining the target code package from the first cache, the method further includes: obtaining multiple second code segments corresponding to the target code package, and storing the multiple second code segments in a third cache in the controller, wherein the third cache is isolated from the first cache; concatenating the multiple second code segments to obtain a package to be verified; determining whether the package to be verified is the same as the target code package to obtain a verification result; and if the verification result indicates that the package to be verified is the same as the target code package, storing the package to be verified as the target code package in the first cache.

[0011] Optionally, updating the firmware source code of the second region corresponding to the second position based on the target code package includes: determining whether the security status of the target code package is a predetermined status, and obtaining a status determination result; if the status determination result indicates that the security status of the target code package is a predetermined status, updating the firmware source code of the second region corresponding to the second position based on the target code package.

[0012] According to one aspect of the present invention, a firmware code update apparatus is provided, comprising: a first determining module, configured to obtain a target code package from a first cache, wherein the first cache is a region divided from the storage area of ​​a controller; a second determining module, configured to determine a first position of the firmware source code in the first region and a second position in a second region corresponding to the first position, wherein the second region is a backup running region of the first region and stores the same firmware source code as the first region; a third determining module, configured to update the firmware source code in the second region corresponding to the second position based on the target code package; a fourth determining module, configured to switch to the second position in the second region to continue running and update the firmware source code in the first region when the firmware source code in the second region is updated; and a fifth determining module, configured to switch back to the first region to continue running according to the corresponding position when the firmware source code in the first region is updated.

[0013] According to one aspect of the present invention, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the firmware code update method described in any of the preceding claims.

[0014] According to one aspect of the present invention, a computer-readable storage medium is provided, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the firmware code update method described in any of the preceding claims.

[0015] In this embodiment of the invention, the target code package is obtained from the first buffer area divided within the controller, and the firmware running area is no longer directly written through the external access interface. This avoids the security risks caused by direct external access, which could lead to unreliability in the update process. By determining the corresponding position of the original firmware code in the first area and the backup second area and keeping the code consistent, the firmware running position can be seamlessly connected during the update process. Based on the target code package, the original firmware code in the second area is updated first, and then the system switches to the second area to run. This ensures that the new code is only enabled after the code update is reliable, avoiding firmware failure due to update interruption or abnormality. Subsequently, the first area is updated synchronously and the system switches back to running, so that both areas complete stable and reliable updates. The entire firmware update process is internalized, step-by-step, and switchable, thereby effectively improving the stability and continuity of the update process. This solves the technical problem of low update reliability when updating firmware code in related technologies. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0017] Figure 1 This is a flowchart of a firmware code update method according to an embodiment of the present invention;

[0018] Figure 2 This is a schematic diagram of the firmware code update method in an optional embodiment of the present invention;

[0019] Figure 3 This is a structural block diagram of a firmware code update device according to an embodiment of the present invention. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] Example 1

[0023] According to an embodiment of the present invention, an embodiment of a firmware code update method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0024] Figure 1 This is a flowchart of a firmware code update method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0025] S102, Obtain the target code package from the first cache area, wherein the first cache area is the area obtained by dividing the storage area of ​​the controller;

[0026] This involves a first cache area, which is a storage area obtained by logically dividing the controller's storage area. Specifically, this first cache area can be a firmware update package cache area, which is a storage area allocated in the controller's (ECU) flash memory, used specifically to store the firmware code package to be updated, and serves as the storage carrier for the target code package.

[0027] This involves a target code package, which is a code data package used to update the firmware source code and carries the code information required to update the firmware.

[0028] This involves a controller, which is an electronic control unit (i.e., an automotive electronic control unit). It is the core control device of the vehicle hardware and provides the operating platform and hardware support for the Hardware Safety Model (HSM).

[0029] This involves a storage area, which is the hardware storage space inside the controller (ECU), specifically the flash memory area of ​​the controller ECU. This flash memory area does not lose data when power is off and can stably store the code package and related data required for firmware updates.

[0030] By retrieving the target code package from the first buffer area, which is partitioned from the controller's storage area, the security risks that may arise from direct writing operations to the firmware runtime area via external access interfaces are avoided. At the same time, it ensures that the target code package is stored in the first buffer area of ​​the controller ECU rather than on an external storage medium, which can stably retain the code information required for firmware updates. Furthermore, by leveraging the partitioning and use of this first buffer area, the reading of the target code package for firmware updates is completed by the controller's own hardware, achieving standardized storage and accurate retrieval of the target code package. This provides a complete and usable code data foundation for reliable updates to the subsequent firmware code, and also ensures that the storage and access of the target code package are both completed based on the controller's internal hardware space, guaranteeing the stability and integrity of the target code package during the reading phase.

[0031] S104, determine the first location of the firmware source code in the first region and the second location in the second region corresponding to the first location, wherein the second region is a backup operating region of the first region and stores the same firmware source code as the first region;

[0032] This involves the first region, which is the main execution area of ​​the firmware (specifically, the HSM firmware) currently running code. It is the core area where the firmware's original code is stored and executed. Specifically, the firmware is a fixed program in the Hardware Security Module (HSM), and it is the core program that implements the HSM's security preset functions such as encryption, key management, and decryption. The firmware's functionality can be upgraded or vulnerabilities can be fixed through code updates.

[0033] This involves the firmware source code, which is the code stored in the firmware runtime area (including the first area and the second area) that enables the firmware to perform its original preset functions. It is the source code that was running before the firmware was updated.

[0034] This involves the first location, which is the specific storage and running location of the firmware source code in the first area. It is a precise location identifier of the firmware source code in the main running area, enabling precise addressing and operation of the firmware source code in the first area.

[0035] This involves a second region, which is a backup operating region for the firmware corresponding to the first region. It pre-stores the original firmware code that is completely identical to that of the first region and can serve as a redundant backup region for the first region, so as to take over the firmware operation when the first region is updated.

[0036] This involves a second location, which is the code storage and execution location in the second region corresponding to the first location. It serves as a precise location identifier for the firmware's original code within the backup execution area. Specifically, before the firmware update, the firmware's original code at the first location in the first region is identical to the firmware's original code at the second location in the second region.

[0037] By determining the first position of the firmware source code in the first region, precise addressing and update operations of the firmware source code within the main operating region (i.e., the first region) can be achieved. Then, by determining the second position in the second region corresponding to the first position, and considering that the second region serves as a backup operating region for the first region and stores the same firmware source code, a precise correspondence between the code storage and operating positions of the two regions can be established. This ensures a smooth transition of the firmware's state when switching between the two regions, and allows subsequent code update operations to accurately point to the specified position in the corresponding region, avoiding address deviations or operational errors. This provides a precise location basis for the subsequent sequential updates of the source firmware code in the two regions (i.e., the first region and the second region), and also ensures that the second region can accurately take over the firmware's operation when the first region is updated.

[0038] S106, based on the target code package, update the firmware source code of the second region corresponding to the second position;

[0039] By updating the original firmware code of the second region corresponding to the second location based on the target code package (for example, erasing the Flash of the second region and simultaneously writing and injecting the code package of the RAM space into the second region), it is possible to ensure that the firmware in the first region runs normally while avoiding direct modification of the running code in the first region, which would cause firmware interruption or abnormality. At the same time, relying on the precise correspondence between the second and first locations, it is ensured that the update operation is accurately applied to the specified address of the backup region rather than other irrelevant locations, so that the updated second region has the ability to support the operation of the new firmware version, achieving seamless connection and high reliability of firmware code updates.

[0040] S108, after the firmware source code update in the second region is completed, switches to the second position in the second region to continue running and updates the firmware source code in the first region;

[0041] After the firmware source code in the second region is updated, the system switches to the second location in the second region to continue running. This allows the second region to take over the firmware operation, ensuring that the firmware remains in normal operation throughout the process. This prevents firmware functionality from being interrupted due to update failures or anomalies. At the same time, the firmware source code in the first region is updated (for example, by injecting the firmware update package from RAM into the first region, thereby completing the HSM update package code update in both the second and first regions). This ensures that the update operation in the first region will not affect the current firmware operation process. By relying on the alternating operation and update of the two regions, the firmware code update and normal operation can be promoted in parallel.

[0042] After the firmware source code update in the first region is completed, the S110 switches back to the first region to continue running based on the corresponding location.

[0043] This involves corresponding positions, namely the first position and the second position. Specifically, based on the second position of the second region, the system switches back to the first position of the first region to continue running.

[0044] After the original firmware code in the first region is updated, the firmware can switch back to the first position in the first region to continue running based on the correspondence between the first and second positions. This allows the firmware to smoothly switch back from the backup second region to the main running first region. At the same time, it ensures that the firmware still executes the updated code in the core first position after switching running regions. It also ensures that both regions complete the update of the new firmware code and keep the running positions consistent, thus achieving the final stability and functional integrity of the firmware update.

[0045] For example, taking HSM firmware as an example, activating the AB partition mode, the HSM can be divided into an active area (i.e., the first area) and an inactive area (i.e., the second area). The HSM can switch between these two areas. During normal HSM firmware operation, the chip code runs in the active area. When the HSM firmware code needs updating, the code running in the active area accesses the code package in the firmware update package cache, verifies the header string of the code package, and if the verification is successful, extracts the code package from the cache into the HSM's random access memory (RAM). After extracting the cached code package, the HSM erases the Flash in the inactive area and simultaneously writes the code package from the RAM into the inactive area. Once the inactive area completes the code update, the HSM switches to the inactive area. After the HSM returns to normal operation in the inactive area, the firmware update package in RAM is injected into the previously active area through the code running in the inactive area, thus completing the code update of the HSM update package in both the active and inactive areas. By caching the firmware update package in the HSM's RAM, simultaneous updates to the active and inactive areas can be performed, preventing inconsistencies between the two areas' codes. Furthermore, the switching between active and inactive areas ensures the normal operation of the HSM during firmware software updates.

[0046] Through the steps S102-S110 described above, the target code package is obtained from the first buffer area divided within the controller. This eliminates the need for direct writing to the firmware runtime area via external access interfaces, avoiding security risks associated with direct external access and ensuring the update process remains unreliable. By determining the corresponding positions of the original firmware code in the first region and the backup second region and maintaining code consistency, seamless correspondence between firmware runtime positions during the update process is guaranteed. The original firmware code in the second region is updated first based on the target code package, and then the system switches to the second region for execution. This ensures that new code is only enabled after a reliable update, preventing firmware malfunction due to update interruptions or anomalies. Subsequently, the first region is synchronously updated and the system switches back to execution, ensuring stable and reliable updates in both regions. This fully internalized, step-by-step, and switchable firmware update process effectively improves the stability and continuity of the update process, thus solving the technical problem of low update reliability when updating firmware code in related technologies.

[0047] As an optional embodiment, updating the firmware source code of the second region corresponding to the second location based on the target code package includes: loading the target code package into a second cache, wherein the second cache is isolated from the first cache; performing an integrity check on the target code package to obtain a check result, wherein the integrity check is used to verify whether the code in the target code package was modified before being loaded into the second cache; determining whether to perform a code update operation based on the check result; and updating the firmware source code of the second region corresponding to the second location based on the target code package in the second cache if the execution determination result is to perform a code update operation.

[0048] This involves a second cache area, which is a storage area within the controller's storage region used for loading the target code package during firmware updates. This second cache area is physically and / or logically independent of the first cache area, which stores the package to be updated (such as the target code package). It is used only for temporary storage and verification of the target code package during the firmware update process. Specifically, this second cache area can be random access memory (RAM) space.

[0049] This involves isolation settings, which are physical address partitioning and / or logical access control measures applied to the first cache and the second cache, so that the stored data in the two caches (i.e., the first cache and the second cache) do not interfere with each other and the access paths are independent of each other, thus preventing the operation of one cache from affecting the data security of the other cache.

[0050] This involves integrity verification, which is a consistency verification operation performed on the target code package loaded into the second cache. The verification algorithm (such as hash verification) compares the original feature value of the target code package with the feature value after loading to verify whether the code package has been tampered with or damaged during the loading process.

[0051] This involves the verification result, which is the result obtained after performing an integrity check and is used to determine whether the target code package is usable. For example, the verification result includes verification passed or verification failed.

[0052] This involves determining whether to update the original firmware code in the second region, based on the verification result. For example, the determination result may include whether to perform a code update operation or not.

[0053] This involves a code update operation, which is the core action to update the firmware code in the second region by writing the target code package that has passed verification in the second cache to the second location of the second region, overwriting the original firmware code at that location.

[0054] By loading the target code package into a second cache isolated from the first cache, independent temporary storage of the target code package can be achieved, avoiding interference with data in the first cache and ensuring the storage security of the code package during the verification phase. Performing integrity verification on the loaded target code package and obtaining the verification result verifies whether the code package has been tampered with or damaged before loading, filtering out usable target code packages. The execution determination result based on the verification result provides a clear decision-making basis for subsequent update actions, avoiding the use of abnormal code packages for updates. When the execution determination result indicates that a code update operation should be performed, the firmware source code in the second location of the second region is updated based on the verified target code package in the second cache. This ensures that the code package used for the update is complete and usable, allowing the code update operation in the second region to be based on reliable code packages, avoiding update failures or system risks due to damaged or maliciously modified code packages, thereby improving the reliability of firmware code updates.

[0055] As an optional embodiment, if the execution result indicates that a code update operation is to be performed, the firmware source code of the second region corresponding to the second location is updated based on the target code package in the second cache. This includes: splitting the code corresponding to the target code package to obtain multiple first code segments, wherein the multiple first code segments correspond to different functions; parsing the address configurations corresponding to the multiple first code segments from the target code package; retrieving the physical address parameters in the second region; establishing address mapping relationships between the multiple first code segments and the second region based on the address configurations corresponding to the multiple first code segments and the physical address parameters in the second region; and updating the firmware source code of the second region corresponding to the second location based on the multiple first code segments and the address mapping relationships between the multiple first code segments and the second region.

[0056] This involves multiple first code segments, which are several independent code fragments obtained by splitting the target code package according to different functional dimensions. Each first code segment corresponds to a specific function of the firmware (such as an encryption algorithm segment, driver segment, etc.) and is the smallest functional execution unit of the target code package.

[0057] This involves address configuration, which is a storage location rule parsed from the target code package and corresponding to each first code segment. It includes information such as the logical address and address offset that each first code segment should be stored in the firmware running area, and is the core basis for determining the storage location of the code segment.

[0058] This involves physical address parameters, which are inherent hardware-level address information of the second region. These parameters include the starting physical address, address length, address range, and other underlying hardware parameters of the second region, and are the basis for physical addressing when code segments are written into the second region.

[0059] This involves address mapping, which is a correspondence established based on the address configuration of each first code segment and the physical address parameters of the second region. It clarifies the specific physical address location where each first code segment should be written to the second region and is the key logical connection for accurately writing code segments to the second region.

[0060] By splitting the target code package into functionally independent first code segments and parsing their address configurations, and establishing a mapping relationship with the physical address parameters of the second region, it is possible to ensure that each functional code segment is accurately written to the specified physical location in the second region, avoiding address conflicts or functional errors, and realizing modular and precise updates of the firmware code in the second region.

[0061] As an optional embodiment, before obtaining the target code package from the first cache, the method further includes: identifying the package identifier of the candidate code package in the first cache; determining whether the package identifier is a predetermined identifier, and obtaining an identifier determination result; and if the identifier determination result indicates that the package identifier is a predetermined identifier, using the candidate code package as the target code package.

[0062] This involves candidate code packages, which are code packages stored in the first cache and awaiting verification as suitable for firmware code updates.

[0063] This involves a packet identifier, which is an identifier attached to the candidate code packet to uniquely identify it and distinguish different candidate code packets. This packet identifier can be an identifier header string (such as a starting address segment string) added to the candidate code packet. For example, the starting address segment string could be 123456, used to verify that the code injected into the firmware update package cache can be correctly recognized by the firmware code verification.

[0064] This involves a pre-defined identifier, which is a pre-set identifier that meets the update requirements. For example, if the packet identifier after the last self-update was 123456, and a new packet identifier of 123457 is detected in the next self-update detection cycle, triggering a self-update, then 123457 is the pre-defined identifier.

[0065] This includes the identification determination result, which is the result obtained after verifying whether the package identifier of the candidate code package is consistent with the predetermined identifier.

[0066] By identifying the package identifier of candidate code packages in the first buffer and comparing it with a pre-defined identifier that meets the update requirements, it can be ensured that the candidate code package is used as the target code package for subsequent updates only when the source of the candidate code package is legitimate and meets the version requirements (i.e., the identifier determination result is a match). This avoids the injection of illegal or erroneous versions of code into the firmware and ensures the security and reliability of the update process.

[0067] As an optional embodiment, obtaining the target code package from the first cache includes: determining the code update conditions corresponding to the firmware; determining whether the current update conditions of the firmware meet the code update conditions based on the update detection area of ​​the firmware, and obtaining the condition determination result; if the current update conditions meet the code update conditions, obtaining the target code package from the first cache.

[0068] This includes an update detection area, which is a pre-defined area within the firmware specifically designed for periodically detecting firmware update-related status. It can collect the firmware's operating status and update-related information in real time and is the core detection carrier for determining whether the firmware meets the update conditions.

[0069] This includes the current update conditions, which are the actual update-related status information collected in real time by the firmware through the update detection area. This information serves as the actual basis for determining whether the firmware currently meets the update conditions.

[0070] This involves code update conditions, which are standard state requirements that are pre-set for the firmware to meet in order to start the code update process. These conditions serve as a reference standard for determining whether the firmware can perform an update operation.

[0071] This involves determining the conditions, which is the result obtained by comparing the current firmware update conditions with the preset code update conditions.

[0072] For example, a self-update detection area (i.e., an update detection area) can be set up inside the HSM. This self-update detection area periodically checks the header string (i.e., the verification header) of the external cache area (i.e., the firmware update package cache area). When the self-update conditions are met, the HSM activity area is triggered to initiate the self-update process. The triggering conditions can be set according to the actual scenario requirements. For example, if the verification header after the last self-update was 123456, when the self-update detection area detects a new verification header of 123457 in the next self-update period, the self-update conditions are met, and the self-update is triggered.

[0073] By defining the code update conditions corresponding to the firmware, a standardized judgment basis can be provided for firmware self-update. Based on the update detection area, the current update conditions of the firmware are obtained in real time and compared with the code update conditions to obtain the condition determination result. The firmware can autonomously determine whether to enter the update process. When the current update conditions meet the code update conditions, the target code package is obtained from the first cache area. The subsequent update process can be automatically triggered without external intervention, realizing the firmware's autonomous and orderly start of self-update logic, and ensuring that the self-update process is accurately executed when it meets the preset state.

[0074] As an optional embodiment, before obtaining the target code package from the first cache, the method further includes: obtaining multiple second code segments corresponding to the target code package, and storing the multiple second code segments in a third cache in the controller, wherein the third cache is isolated from the first cache; concatenating the multiple second code segments to obtain a package to be verified; determining whether the package to be verified is the same as the target code package, and obtaining a verification result; if the verification result is that the package to be verified is the same as the target code package, storing the package to be verified as the target code package in the first cache.

[0075] This involves multiple second code segments, which are multiple code fragments formed after the target code packet is split. These second code segments are the constituent units of the target code packet and are used for segmented transmission.

[0076] This involves a third cache, an independently partitioned storage area within the controller used to store multiple acquired second code segments. It serves as a temporary area before the code package is formally assembled, and is isolated from the first cache to prevent interference. Furthermore, this third cache is also isolated from the first cache to avoid mutual interference.

[0077] This involves a verification package, which is a complete code package formed by concatenating multiple second code segments according to rules, and is used for consistency comparison with the original target code package.

[0078] This involves verification results, which are the judgment results obtained by comparing whether the package to be verified is the same as the target code package, and are used to confirm that the concatenated code package is complete and error-free.

[0079] By storing multiple second code segments transmitted in segments in a third buffer isolated from the first buffer, the reception and temporary storage of code segments can be completed in an independent environment, avoiding impact on the data security of the first buffer. Multiple second code segments are concatenated to obtain a packet to be verified. The segmented code can be restored into a complete code packet for consistency verification. By comparing the packet to be verified with the original target code packet, the verification result can be obtained, confirming that the concatenated code packet is free of loss or errors. When the verification is consistent, the packet to be verified is stored as the target code packet in the first buffer, ensuring that the code packet entering the subsequent update process is complete and accurate, providing a reliable and correct code data source for firmware self-update.

[0080] As an optional embodiment, updating the firmware source code of the second region corresponding to the second position based on the target code package includes: determining whether the security state of the target code package is a predetermined state, and obtaining a state determination result; if the state determination result indicates that the security state of the target code package is a predetermined state, updating the firmware source code of the second region corresponding to the second position based on the target code package.

[0081] This involves the security status, which refers to the status of the target code package in terms of the trustworthiness of the code source and the compliance of permissions, that is, the legitimacy and authorization status of the target code package itself.

[0082] This involves a predetermined state, which is a pre-set security state that allows the target code package to be used for firmware updates.

[0083] This involves a status determination result, which is the result obtained by comparing the security status of the target code package with the predetermined status (such as "secure" or "insecure"), and is used to determine whether to initiate subsequent firmware source code update operations.

[0084] By determining whether the security status of the target code package is in a predetermined state, and updating the firmware source code in the second region based on the target code package only when the security status meets the predetermined state, it can be ensured that only compliant and trustworthy target code packages can participate in firmware updates, thereby further improving the security and reliability of the firmware self-update process.

[0085] Based on the above embodiments and optional embodiments, an optional implementation method is provided, which is described in detail below.

[0086] In related technologies, firmware may develop security vulnerabilities, functional defects, or fail to meet the upgrade requirements of actual application scenarios during long-term operation, thus necessitating firmware code updates. However, updating firmware code in these technologies suffers from low update reliability.

[0087] There is currently no effective solution to the above problems.

[0088] Specifically, from the perspective of the importance of automotive information security, on the one hand, the deep integration of automobiles and the Internet makes vehicle control systems vulnerable to remote attacks, threatening user safety; on the other hand, the leakage of in-vehicle data not only infringes on user privacy but may also cause economic losses to users. The Hardware Security Module (HSM) for automotive information security is a dedicated hardware device used to generate, store, and manage encryption keys and provide security functions such as encryption and decryption, applied in the field of automotive information security. Currently, most mainstream automotive electronic control chips integrate HSMs. Considering the potential vulnerabilities in the HSM's operating code or practical application needs, HSM firmware software upgrades are required. Currently, the common method for updating HSM firmware software is through the chip's debugging interface, directly updating the HSM firmware software into the HSM. This method requires specific debugging equipment to inject the firmware software. When the automotive controller is already installed on the vehicle, it also needs to be disassembled for injection. Furthermore, based on the information security requirements of the entire vehicle, once the vehicle enters the mass production stage, the controller (ECU) needs to have its debugging interface removed, making firmware software updates impossible.

[0089] In view of this, an optional embodiment of the present invention provides a firmware code update method, which can also be called an information security firmware software update method, and can effectively solve the above-mentioned technical problems.

[0090] Figure 2 This is a schematic diagram of the firmware code update method in an optional embodiment of the present invention, such as... Figure 2 As shown, taking HSM firmware as an example, a firmware update package cache is set up to cache the software packages to be updated. The HSM firmware code accesses the external cache (i.e., the firmware update package cache) internally. The HSM verifies whether the code to be updated (i.e., the firmware update package) is safe and reliable, and updates itself with the safe and reliable code. When a firmware update is needed, the firmware update package is injected into the cache, and the verification header of the firmware update package cache is set to meet the self-update conditions. When the HSM self-update periodically detects the self-update conditions, it triggers the HSM self-update process. The HSM runtime code area begins to call the firmware update package in the firmware update package cache, updating the firmware update package in the firmware update package cache to the HSM's inactive area. After the update is complete, the HSM switches to the inactive area. When the HSM code runs in the inactive area, it updates the previously active area code; thus completing the HSM firmware code update. Based on the above, software updates of the information security HSM firmware do not require debugging interfaces. A detailed description follows.

[0091] A memory segment is allocated within the flash memory of the controller ECU as a firmware update package cache (i.e., the first cache). This cache stores the HSM firmware code to be updated (i.e., the firmware update package, such as the target code package). The code in this firmware update package cache can be updated and flashed by the chip's boot code, injecting the HSM code package into the cache. The firmware update package cache allows for updates to the code within it using normal chip flashing software, facilitating the caching of firmware code into the ECU. Specifically, because the firmware update package cache is partitioned within the flash memory of the controller ECU, it is an internal storage area of ​​the chip, residing within the same hardware as the chip's boot code and HSM operating environment. The data transmission path is short and does not involve external interfaces or devices, reducing the possibility of interference during code package transmission and transfer. Furthermore, the firmware update package cache can be managed by the chip's own access mechanism, thus offering higher security and stability compared to external storage caches.

[0092] For inserting the update package into the identification code, specifically, the update package needs to include a specific identifier header string (i.e., a package identifier), such as the starting address segment string of the update package being 123456. This is used to verify that the code injected into the firmware update package cache can be correctly identified by the HSM firmware code verification. Before the HSM retrieves the update package from the firmware update package cache, it first verifies the header string of the update package in the firmware update package cache. Only when a match is found can the code package (i.e., the update package) be retrieved, thus ensuring the security of the firmware update package retrieval within the HSM and preventing accidental code updates. The HSM firmware code is highly secure; its internal code cannot be updated by other flashing programs. Even through the debug port, it needs to be unlocked before updating. Therefore, the security of software updates is ensured by starting the code update within the HSM firmware.

[0093] The HSM internal self-update detection process specifically includes setting up a self-update detection area within the HSM. This area periodically checks the header string (i.e., the verification header) in the external cache (i.e., the firmware update package cache). When the self-update conditions are met, the HSM activity area is triggered to initiate the self-update process. The triggering conditions can be set according to actual scenario requirements. For example, if the verification header after the last self-update was 123456, and the next self-update detection period detects a new verification header of 123457, the self-update conditions are met, and the self-update is triggered.

[0094] The HSM self-update process specifically includes activating the HSM firmware in AB partition mode. In this mode, the HSM is divided into an active area (i.e., the first area) and an inactive area (i.e., the second area). The HSM can switch between these two areas. During normal HSM firmware operation, the chip code runs in the active area. When the HSM firmware code needs updating, the code running in the active area accesses the code package in the firmware update package cache, verifies the header string of the code package, and if the verification is successful, extracts the code package from the firmware update package cache into the HSM's random access memory (RAM) space. After the HSM completes the extraction of the cached code package, it erases the Flash in the inactive area and simultaneously writes and injects the code package from the RAM space into the inactive area. Once the code update in the inactive area is complete, the HSM switches to run in the inactive area. After the HSM returns to normal operation in the inactive area, the firmware update package in RAM is injected into the previously active area through the code running in the inactive area, thus completing the code update of the HSM update package in both the active and inactive areas. By caching the firmware update package in the HSM's RAM, simultaneous updates to the active and inactive areas can be performed, preventing inconsistencies between the two areas' codes. Furthermore, the switching between active and inactive areas ensures the normal operation of the HSM during firmware software updates.

[0095] The above optional implementation methods can achieve at least the following beneficial effects:

[0096] (1) Compared with related technologies, the present invention obtains the target code package from the first buffer area divided inside the controller, and no longer performs write operations on the firmware running area directly through the external access interface. This avoids the security risks caused by direct external access, which leads to unreliability of the update process. By determining the corresponding position of the firmware original code in the first area and the backup second area and keeping the code consistent, it can ensure that the firmware running position can be seamlessly connected during the update process. Based on the target code package, the firmware original code in the second area is updated first, and then the second area is switched to run after the update is completed. This ensures that the new code is only enabled after the code update is reliable, avoiding the firmware from failing to run properly due to update interruption or abnormality. Then, the first area is updated synchronously and switched back to run, so that both areas complete stable and reliable updates. The entire process realizes internalized, step-by-step, and switchable firmware updates, thereby effectively improving the stability and continuity of the update process. This solves the technical problem of low update reliability when updating firmware code in related technologies.

[0097] (2) Compared with related technologies, the present invention loads the target code package into a second cache area that is isolated from the first cache area, thereby enabling independent temporary storage of the target code package, avoiding interference with the data in the first cache area, ensuring the storage security of the code package during the verification phase, performing integrity verification on the loaded target code package and obtaining the verification result, verifying whether the code package has been tampered with or damaged before loading, filtering out usable target code packages, and determining whether to perform code update operation based on the verification result, which can provide a clear decision basis for whether to perform update action in the future, avoiding the use of abnormal code packages for update, and when the execution determination result is to perform code update operation, updating the firmware original code in the second position of the second area based on the verified target code package in the second cache area, which can ensure that the code package used for update is complete and usable, allowing the code update operation in the second area to be carried out based on reliable code packages, avoiding update failure or system risks due to code package damage or malicious modification, thereby improving the reliability of firmware code update.

[0098] (3) Compared with related technologies, this invention realizes the software code update process of the entire firmware by running independently based on HSM. External control commands will not access the HSM internally, ensuring the security of HSM and effectively preventing malicious attacks on vulnerabilities. It not only solves the problem of insecurity and inconvenience of firmware software update through a single debugging interface, but also ensures the security and independence of HSM. It allows one-way access to external resources of HSM without adding any external access interface to HSM, thereby avoiding the problem of software update directly through external interface, which leads to attacks on HSM vulnerabilities and exposes HSM to security risks.

[0099] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0100] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0101] Example 2

[0102] According to embodiments of the present invention, an apparatus for implementing the above-described firmware code update method is also provided. Figure 3 This is a structural block diagram of a firmware code update apparatus according to an embodiment of the present invention, such as... Figure 3 As shown, the device includes: a first determining module 302, a second determining module 304, a third determining module 306, a fourth determining module 308, and a fifth determining module 310. The device will be described in detail below.

[0103] The first determining module 302 is used to obtain the target code package from the first cache area, wherein the first cache area is the area obtained by dividing the storage area of ​​the controller;

[0104] The second determining module 304 is connected to the first determining module 302 and is used to determine the first position of the firmware source code in the first region and the second position in the second region corresponding to the first position. The second region is a backup operating region of the first region and stores the same firmware source code as the first region.

[0105] The third determining module 306, connected to the second determining module 304, is used to update the firmware source code of the second region corresponding to the second position based on the target code package;

[0106] The fourth determining module 308, connected to the third determining module 306, is used to switch to the second position of the second region to continue running after the firmware source code update of the second region is completed, and to update the firmware source code of the first region.

[0107] The fifth determining module 310, connected to the fourth determining module 308, is used to switch back to the first region to continue running according to the corresponding position after the firmware source code update in the first region is completed.

[0108] It should be noted that the first determining module 302, the second determining module 304, the third determining module 306, the fourth determining module 308, and the fifth determining module 310 mentioned above correspond to steps S102 to S110 in the firmware code update method. The multiple modules and the corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiment 1.

[0109] Example 3

[0110] According to another aspect of the present invention, an electronic device is also provided, comprising: a processor; and a memory for storing processor-executable instructions, wherein the processor is configured to execute instructions to implement the firmware code update method of any of the above embodiments.

[0111] Example 4

[0112] According to another aspect of the present invention, a computer-readable storage medium is also provided, which, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the firmware code update method described above.

[0113] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0114] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0115] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0116] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0117] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0118] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

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

Claims

1. A firmware code update method, characterized in that, include: The target code package is obtained from the first cache area, wherein the first cache area is the area obtained by dividing the storage area of ​​the controller; A first location of the firmware source code in a first region and a second location in a second region corresponding to the first location are determined, wherein the second region is a backup operating region of the first region and the second region stores the same firmware source code as the first region; Based on the target code package, the firmware source code of the second region corresponding to the second position is updated; Once the firmware source code update in the second region is complete, switch to the second location in the second region to continue running, and update the firmware source code in the first region; Once the firmware source code update in the first region is complete, switch back to the first region to continue running based on the corresponding location.

2. The method according to claim 1, characterized in that, The step of updating the firmware source code of the second region corresponding to the second position based on the target code package includes: The target code package is loaded into a second cache area, wherein the second cache area is isolated from the first cache area; The integrity of the target code package is verified to obtain the verification result, wherein the integrity verification is used to verify whether the code in the target code package has been modified before being loaded into the second cache area; Based on the verification result, determine whether to perform the code update operation; If the execution result determines that a code update operation is to be performed, the firmware source code of the second region corresponding to the second location is updated based on the target code package in the second cache.

3. The method according to claim 2, characterized in that, When the execution result is determined to be a code update operation, the firmware source code of the second region corresponding to the second location is updated based on the target code package in the second cache, including: The code corresponding to the target code package is split into multiple first code segments, wherein each of the multiple first code segments corresponds to a different function; Parse the address configurations corresponding to the plurality of first code segments from the target code package; Retrieve the physical address parameters from the second region; Based on the address configurations corresponding to the plurality of first code segments respectively, and the physical address parameters in the second region, an address mapping relationship is established between the plurality of first code segments and the second region respectively; Based on the plurality of first code segments and the address mapping relationship between the plurality of first code segments and the second region respectively, the firmware original code of the second region corresponding to the second position is updated.

4. The method according to claim 1, characterized in that, Before retrieving the target code package from the first cache, the process also includes: Identify the package identifier of the candidate code package in the first cache area; Determine whether the package identifier is a predetermined identifier, and obtain the identifier determination result; If the identification result indicates that the package identifier is a predetermined identifier, the candidate code package is used as the target code package.

5. The method according to claim 1, characterized in that, The step of obtaining the target code package from the first cache includes: Determine the code update conditions corresponding to the firmware; Based on the update detection area of ​​the firmware, it is determined whether the current update conditions of the firmware meet the code update conditions, and the condition determination result is obtained. If the current update conditions meet the code update conditions, the target code package is retrieved from the first cache.

6. The method according to claim 1, characterized in that, Before retrieving the target code package from the first cache, the process also includes: Obtain multiple second code segments corresponding to the target code package, and store the multiple second code segments in a third cache area in the controller, wherein the third cache area is isolated from the first cache area; The multiple second code segments are concatenated to obtain the packet to be verified; Determine whether the package to be verified is the same as the target code package, and obtain the verification result; If the verification result shows that the package to be verified is the same as the target code package, the package to be verified is stored as the target code package in the first cache area.

7. The method according to any one of claims 1 to 6, characterized in that, The step of updating the firmware source code of the second region corresponding to the second position based on the target code package includes: Determine whether the security status of the target code package is a predetermined state, and obtain the status determination result; If the state determination result indicates that the security state of the target code package is a predetermined state, the firmware source code of the second region corresponding to the second position is updated based on the target code package.

8. A firmware code update device, characterized in that, include: The first determining module is used to obtain the target code package from the first cache area, wherein the first cache area is an area obtained by dividing the storage area of ​​the controller; The second determining module is used to determine a first location of the firmware source code in the first region and a second location in the second region corresponding to the first location, wherein the second region is a backup operating region of the first region and the second region stores the same firmware source code as the first region; The third determining module is used to update the firmware source code of the second region corresponding to the second position based on the target code package; The fourth determining module is used to switch to the second position in the second region to continue running after the firmware source code update in the second region is completed, and to update the firmware source code in the first region. The fifth determining module is used to switch back to the first region to continue running based on the corresponding position after the firmware source code update in the first region is completed.

9. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the firmware code update method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the firmware code update method as described in any one of claims 1 to 7.

Images