Firmware management method, device, storage medium and electronic device

Abstract

The present application proposes a firmware management method, device, storage medium and electronic device, which are applied to a multi-core processor, wherein the multi-core processor includes a trusted core running on the TEE side and a computing core running on the REE side, wherein the computing core is at a first target level and the trusted core is at a second target level, wherein the second target level is higher than the first target level, and when the target core obtains a firmware parameter modification request, the parameter modification interface is called to jump to a third target level, wherein the target core before the jump is either a trusted core or a computing core, and the third target level is higher than the second target level; when the target core before the jump is a trusted core running on the TEE side, the firmware parameter update is completed according to the parameter information to be modified in the firmware parameter modification request, and the updated firmware parameters are used as the startup configuration parameters at the time of restart. This avoids the possibility that the permissions of the operating system running on the computing core on the REE side are cracked and the firmware parameters are maliciously modified.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a firmware management method, device, storage medium and electronic device. Background Art

[0002] Firmware is generally stored in the FLASH chip of the device. Firmware is the software that performs the most basic and lowest-level work of the system. The operating system needs firmware to implement the operation of a specific machine according to the standard device driver protocol. In hardware devices, firmware is the soul of the hardware device. For example, some hardware devices have no other software except firmware, so the firmware determines the function and performance of the hardware device. It should be understood that firmware is designed to control hardware devices. Firmware includes BIOS (Basic Input / Output System) and UEFI (Unified Extensible Firmware Interface.

[0003] In a computer, BIOS (Baseline Input / Output System) or UEFI (Unified Extensible Firmware Interface) is the first program that starts after the computer is powered on. It is the device driver stored inside the device. Taking BIOS as an example, BIOS can interact with the hardware and check if it has any errors. BIOS can call the bootloader program to wake up the operating system sleeping in the hard drive and put the operating system into the random access memory. It can be seen that firmware plays a very important role in the operation of the device.

[0004] Therefore, firmware management has also become a difficult problem that continues to attract the attention of those skilled in the art. Summary of the invention

[0005] The purpose of the present application is to provide a firmware management method, device, storage medium and electronic device to at least partially improve the above-mentioned problems.

[0006] In order to achieve the above purpose, the technical solution adopted in the embodiment of the present application is as follows:

[0007] In a first aspect, an embodiment of the present application provides a firmware management method, which is applied to a multi-core processor, wherein the multi-core processor includes a trusted core running on the TEE side and a computing core running on the REE side, and a software-type parameter modification interface is configured in the multi-core processor, wherein the computing core is at a first target level, and the trusted core is at a second target level, wherein the second target level is higher than the first target level, and the method includes:

[0008] When the target core obtains the firmware parameter modification request, the parameter modification interface is called to jump to the third target level, wherein the target core before the jump is any one of the trusted core or the computing core, and the third target level is higher than the second target level; when the target core before the jump is the trusted core running on the TEE side, the firmware parameter update is completed according to the parameter information to be modified in the firmware parameter modification request, wherein the updated firmware parameters are used as the startup configuration parameters during restart.

[0009] The firmware management method provided in the embodiment of the present application can be directly updated online, with simple update steps, high update efficiency, low update cost, reduced debugging time and wider application scenarios. In addition, when the target core before the jump is a trusted core running on the TEE side, the firmware parameter update is completed according to the parameter information to be modified in the firmware parameter modification request. When the target core before the jump is a computing core running on the REE side, the firmware parameters are not updated. The computing core is at the first target level, the trusted core is at the second target level, and the second target level is higher than the first target level. It should be understood that the root permissions of the operating system (Trust OS) running at the second target level are less likely to be cracked than the root permissions of the operating system (Guest OS) running at the first target level. Even if the root permissions of the operating system (Guest OS) on the REE side are cracked, the firmware parameters are not updated, reducing the possibility of malicious modification of the firmware parameters. The correctness of the firmware parameters plays a key role in whether the device can operate normally. In order to further improve the security of firmware parameters, it is limited that only the third target level (higher than the second target level) after the jump can complete the firmware parameter update according to the parameter information to be modified in the firmware parameter modification request. This avoids the situation where the firmware parameters are arbitrarily changed after the root permission of the operating system (GuestOS) on the REE side is cracked. Optionally, the multi-core processor also includes a first storage unit and a second storage unit, and the trusted core is connected to the first storage unit and the second storage unit respectively; wherein the first storage unit is used to store the firmware parameters, and the second storage unit is used as a running memory; the firmware parameters include at least one configuration parameter list, and the parameter information to be modified includes a list identifier, an offset address, and an update content, and the firmware parameter update is completed according to the parameter information to be modified in the firmware parameter modification request, including:

[0010] Extract the at least one configuration parameter list in the first storage unit to the second storage unit; update the at least one configuration parameter list in the second storage unit according to the list identifier, the offset address and the update content; write the updated at least one configuration parameter list into the first storage unit.

[0011] It should be understood that during a firmware parameter update, only part of the configuration parameter list may be involved. The list identifier and offset address can be used to quickly determine the replacement in the list of parameters that need to be updated, thereby avoiding adjustment of all configuration parameter lists and reducing the adjustment workload.

[0012] Optionally, updating the at least one configuration parameter list in the second storage unit according to the list identifier, the offset address and the update content includes: determining the content to be replaced according to the list identifier and the offset address; replacing the content to be replaced with the update content to complete the update of the at least one configuration parameter list in the second storage unit. Thus, the update of the at least one configuration parameter list is completed quickly and accurately.

[0013] Optionally, after the at least one configuration parameter list in the second storage unit is updated according to the list identifier, the offset address and the update content, the method further includes: generating a check code according to the at least one configuration parameter list after the update; writing the check code into the first storage unit; wherein the check code is used to verify the at least one configuration parameter list when the at least one configuration parameter list is called. The security of the firmware parameters is further improved by the check code, and when the firmware parameters are tampered with, unreasonable changes in the firmware parameters can be discovered in a timely manner.

[0014] Optionally, after updating the at least one configuration parameter list in the second storage unit according to the list identifier, the offset address and the update content, the method further comprises: generating a check code according to the updated at least one configuration parameter list;

[0015] Writing the updated at least one configuration parameter list into the first storage unit includes: pairing the updated at least one configuration parameter list with the verification code to generate a parameter file; and writing the parameter file into the first storage unit.

[0016] Pairing at least one configuration parameter list and the verification code through a parameter file facilitates subsequent calls and avoids separately calling at least one configuration parameter list and the verification code for pairing.

[0017] Optionally, the verification of the at least one configuration parameter list includes: solving the at least one configuration parameter list obtained by calling to obtain a corresponding verification code; if the verification code matches the check code, determining that the at least one configuration parameter list has passed the verification; if the verification code does not match the check code, reporting an error. The rationality of the firmware parameters is ensured to prevent the tampered firmware parameters from affecting the firmware startup.

[0018] In a second aspect, an embodiment of the present application provides a firmware management device, which is applied to a multi-core processor, wherein the multi-core processor includes a trusted core running on the TEE side and a computing core running on the REE side, and a software-type parameter modification interface is configured in the multi-core processor, wherein the computing core is at a first target level, and the trusted core is at a second target level, wherein the second target level is higher than the first target level, and the device includes:

[0019] A receiving unit, used for receiving a firmware parameter modification request;

[0020] a processing unit, configured to call the parameter modification interface to jump to a third target level when the target core obtains a firmware parameter modification request, wherein the target core before the jump is any one of the trusted core or the computing core, and the third target level is higher than the second target level;

[0021] The processing unit is also used to complete the firmware parameter update according to the parameter information to be modified in the firmware parameter modification request when the target core before the jump is a trusted core running on the TEE side, wherein the updated firmware parameters are used as the startup configuration parameters during restart.

[0022] Optionally, the processing unit is further configured to not update firmware parameters when the target core before the jump is a computing core running on the REE side.

[0023] Optionally, the multi-core processor includes a first storage unit and a second storage unit, and the trusted core is connected to the first storage unit and the second storage unit respectively; wherein the first storage unit is used to store the firmware parameters, and the second storage unit is used as a running memory; the firmware parameters include at least one configuration parameter list, and the parameter information to be modified includes a list identifier, an offset address, and an update content;

[0024] The processing unit is also used to extract the at least one configuration parameter list in the first storage unit to the second storage unit; update the at least one configuration parameter list in the second storage unit according to the list identifier, the offset address and the update content; and write the updated at least one configuration parameter list into the first storage unit to complete the firmware parameter update.

[0025] In a third aspect, an embodiment of the present application provides a storage medium on which a computer program is stored, and when the computer program is executed by a processor, the above-mentioned firmware management method is implemented.

[0026] In a fourth aspect, an embodiment of the present application provides an electronic device, comprising: a processor and a memory, wherein the memory is used to store one or more programs; when the one or more programs are executed by the processor, the above-mentioned firmware management method is implemented.

[0027] In order to make the above-mentioned objects, features and advantages of the present application more obvious and understandable, embodiments are given below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0029] Figure 1 A schematic diagram of a hierarchical architecture provided for an embodiment of the present application;

[0030] Figure 2 A schematic diagram of a system on a chip provided in an embodiment of the present application;

[0031] Figure 3 A flowchart of a firmware management method provided in an embodiment of the present application;

[0032] Figure 4 A schematic diagram of the connection relationship between the first storage unit, the second storage unit and the credibility core provided in an embodiment of the present application;

[0033] Figure 5 A schematic diagram of sub-steps of S103 provided in an embodiment of the present application;

[0034] Figure 6 A schematic diagram of sub-steps of S103-2 provided in an embodiment of the present application;

[0035] Figure 7 One of the flowcharts of the firmware management method provided in the embodiment of the present application;

[0036] Figure 8 A schematic diagram of the verification process provided in the embodiment of the present application;

[0037] Fig. 9 A schematic diagram of the composition of the startup firmware provided in an embodiment of the present application;

[0038] Fig.10 A schematic diagram of sub-steps of S103-4 provided in an embodiment of the present application;

[0039] Fig.11 A schematic diagram of a unit of a firmware management device provided in an embodiment of the present application;

[0040] Fig.12 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0041] In the figure: 10 - processor; 11 - memory; 12 - bus; 13 - communication interface; 301 - receiving unit; 302 - processing unit. DETAILED DESCRIPTION

[0042] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various different configurations.

[0043] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for which protection is sought, but merely represents selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

[0044] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0045] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0046] In the description of the present application, it should be noted that the terms "upper", "lower", "inside", "outside", etc. indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, or are the orientations or positional relationships in which the product of the application is usually placed when in use. They are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be understood as a limitation on the present application.

[0047] In the description of this application, it is also necessary to explain that, unless otherwise clearly specified and limited, the terms "disposed" and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be an indirect connection through an intermediate medium, or it can be the internal communication of two elements. For ordinary technicians in this field, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0048] In conjunction with the accompanying drawings, some embodiments of the present application are described in detail below. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0049] With the rapid development of mobile communications and Internet technologies, smart devices are playing an increasingly important role in various fields. Smart devices all use a general operating system (Guest OS). However, some hackers can crack the root permissions of smart devices and steal user data or other key information, resulting in data leakage and abuse. Therefore, how to ensure data security is becoming increasingly important. In order to eliminate such threats, a relatively trusted operating environment (Trusted Execution Environment, TEE) can be provided in the system to run a relatively secure operating system (Trust OS), so that the user's key data or applications can run in a relatively trusted environment. In this way, even if the general operating system is compromised, the intruder cannot directly obtain the user's important information.

[0050] In order to provide a secure operating environment, Arm introduced TrustZone technology from the Armv6 architecture. TrustZone is a trust framework of Arm. In this framework, the Arm core will cooperate with the security extension components to divide the hardware and software resources of the System on Chip (SoC) into a secure world and a non-secure world. When the processor core is in the secure world, it can only run the code on the TEE side of the trusted execution environment and has access to the address space on the REE (Rich Execution Environment) side. When the processor core is in the non-secure world, it can only run the code on the REE side.

[0051] In a possible implementation, the execution level (EL) EL0-EL3 is used to determine the running level of the Arm core, where EL0-EL2 levels are divided into a secure world (TEE side) and a normal world (REE side). Figure 1 shown.

[0052] EL0 is the user mode, running applications.

[0053] EL1 is the operating system kernel mode (OS Kernel mode), which runs the operating system, which is divided into the general operating system (Guest OS) running in the normal world (REE side) (level EL1) and the trusted operating system (Trust OS) running in the secure world (TEE side) (level S-EL1). In practical applications, the first target level proposed in the embodiment of the present application is equivalent to level EL1, and the second target level is equivalent to level S-EL1.

[0054] EL2 is the virtual machine monitor mode, which runs virtual machines.

[0055] EL3 is TrustZone monitor mode, which runs security management and is responsible for switching between the processor's secure world and normal world. The SMC (secure monitor call) instruction interaction mainly refers to the CPU calling the SMC instruction to switch between the trusted execution environment and the general execution environment, and passing parameters through the CPU general registers. In practical applications, the third target level proposed in the embodiment of the present application is equivalent to level EL3.

[0056] It should be understood that the second target level is higher than the first target level, and the third target level is higher than the second target level.

[0057] like Figure 2 As shown, the system on chip includes a multi-core processor (i.e. Figure 2 The multi-core processor includes a trusted core running on the TEE side and a computing core running on the REE side. It should be noted that each core has a configurable running state, namely the trusted state (indicating that the core runs on the TEE side) and the computing state (indicating that the core runs on the REE side). The running state of each core is variable, for example Figure 2 Core 1 in the example is currently a computing core running on the REE side. When its running state changes, core 1 can be changed to a trusted core running on the TEE side. The computing core is at the first target level, and the trusted core is at the second target level, which is higher than the first target level.

[0058] Optionally, a software-type parameter modification interface is configured in the multi-core processor, and the parameter modification interface may be an SMC interface for updating firmware parameters.

[0059] It should be noted that a multi-core processor refers to a processor that integrates two or more complete computing engines (cores). At this time, the processor can support multiple processor cores on the system bus, and the bus controller provides all bus control signals and command signals. In the embodiment of the present application, the multi-core processor includes at least one main core (the computing core running on the REE side) and one trusted core running on the TEE side. Of course, the number of trusted cores and computing cores in multi-core processing can be greater than or equal to 1. When the number of computing cores is greater than 1, one of the computing cores is used as the main core, and the other computing cores are used as slave cores.

[0060] The main core is only allowed to work when powered on, and a series of initializations are performed. The trusted core is started at EL3, and then the main core runs the Guest OS in the REE environment. The trusted core: in the TEE environment, runs the Trust OS after the core is successfully started. The software part of the system needs to include dual systems, namely the Guest OS running in the REE and the Trust OS running in the TEE.

[0061] As mentioned above, a relatively trusted execution environment (TEE) is provided in the system to run a relatively secure operating system (Trust OS), so that the user's key data or applications can run in a relatively trusted environment. Firmware also plays a very important role in the operation of the device. How to manage the firmware in this scenario is the technical problem that this application wants to solve.

[0062] The multi-core processor provided in the embodiment of the present application may be applied to, but is not limited to, Figure 2 For the detailed process of the system on chip shown in the figure, please refer to Figure 3 The implementation steps of the firmware management method may include: S101, S102, S103 and S104, which are described in detail below.

[0063] S101, when the target core obtains a firmware parameter modification request, the parameter modification interface is called to jump to the third target level.

[0064] The target core before the jump is any one of a trusted core or a computing core. The computing core before the jump is at a first target level, the trusted core is at a second target level, the second target level is higher than the first target level, and the third target level is higher than the second target level.

[0065] It should be understood that both the trusted core and the computing core (including the master core and the slave core) can obtain firmware parameter modification requests. The firmware parameter modification situation can be input by the user through the human-computer interaction device or transmitted by other terminals through the communication network.

[0066] It should be understood that no matter the target core is a trusted core running on the TEE side or a computing core running on the REE side, after the jump, the target core runs on the TEE side.

[0067] S102, determining the running state of the target core before the jump.

[0068] The running state includes the trusted state (indicating that the core runs on the TEE side) and the computing state (indicating that the core runs on the REE side). As mentioned above, the running environment on the TEE side is more secure than that on the REE side.

[0069] S103, when the target core before the jump is a trusted core running on the TEE side, the firmware parameter update is completed according to the parameter information to be modified in the firmware parameter modification request.

[0070] The updated firmware parameters are used as the startup configuration parameters during restart.

[0071] It should be understood that when a multi-core processor is started, a series of startup configuration parameters need to be called when the firmware is running.

[0072] S104: When the target core before the jump is a computing core running on the REE side, the firmware parameters are not updated.

[0073] Optionally, if the target core before the jump is a computing core running on the REE side, it means that the firmware parameter modification request is an illegal call request and can be directly discarded or an alarm can be issued to prompt the user that the firmware parameters are being illegally modified.

[0074] It should be understood that the firmware parameters include a series of important parameters required for the firmware to run. When the firmware parameters are maliciously tampered with, the firmware operation will be affected, which may cause the device to start up and fail. Therefore, it is necessary to ensure the security of the firmware parameters. When the firmware parameter modification request is obtained and the jump is made to the third target level, the running state of the target core before the jump needs to be determined. When the target core before the jump is a trusted core running on the TEE side, the firmware parameter update is completed according to the parameter information to be modified in the firmware parameter modification request. When the target core before the jump is a computing core running on the REE side, the firmware parameters are not updated. It should be understood that the computing core is at the first target level, the trusted core is at the second target level, and the second target level is higher than the first target level. It should be understood that the root permissions of the operating system (Trust OS) running on the trusted core at the second target level are less likely to be cracked than the root permissions of the operating system (Guest OS) running on the computing core at the first target level. Even if the root permissions of the operating system (Guest OS) on the REE side are cracked, the firmware parameters are not updated, reducing the possibility of malicious modification of the firmware parameters. As mentioned above, the correctness of firmware parameters plays a key role in whether the device can operate normally. In order to further improve the security of firmware parameters, it is limited that only the third target level (higher than the second target level) after the jump can complete the firmware parameter update according to the parameter information to be modified in the firmware parameter modification request. This avoids the situation where the firmware parameters are arbitrarily changed after the root permission of the operating system (Guest OS) on the REE side is cracked.

[0075] It should be noted that the "and / or" relationship between S103 and S104, that is, the firmware management method provided in the embodiment of the present application may include S103 and S104 at the same time, or only include any one step of S103 and S104. If S103 is included, S104 is not included; if S104 is included, S103 is not included. The above all belong to possible implementation methods provided in the embodiments of the present application.

[0076] In a possible implementation, during the development and debugging phase, developers may need to frequently update the boot firmware stored in the flash chip, or after the firmware is released, they may need to upgrade the firmware. One way to update the firmware is to burn the flash offline. If it is a flash chip, the flash chip needs to be removed and then put into the burner for burning. After the burning is completed, the flash chip needs to be put back and restarted. The burning time is long and a lot of time is wasted. Alternatively, a flash emulator can be used during the development and debugging phase. The burning is fast, but it is expensive and can only be used for development and debugging. The actual application still requires a flash chip.

[0077] Compared with the above-mentioned update method, the firmware management method provided in the embodiment of the present application can be directly updated online, with simple update steps, high update efficiency, low update cost, reduced debugging time and wider application scenarios. In addition, when the target core before the jump is a trusted core running on the TEE side, the firmware parameter update is completed according to the parameter information to be modified in the firmware parameter modification request. When the target core before the jump is a computing core running on the REE side, the firmware parameters are not updated. Even if the root authority of the operating system (Guest OS) on the REE side is cracked, the firmware parameters are not updated, reducing the possibility of the firmware parameters being maliciously modified. Thereby avoiding the situation where the firmware parameters are arbitrarily changed after the root authority of the operating system (Guest OS) on the REE side is cracked, further ensuring the security of the firmware parameters.

[0078] In summary, the embodiment of the present application provides a firmware management method, which is applied to a multi-core processor, the multi-core processor includes a trusted core running on the TEE side and a computing core running on the REE side, the multi-core processor is configured with a software type parameter modification interface, the computing core is at the first target level, the trusted core is at the second target level, and the second target level is higher than the first target level, including: when the target core obtains a firmware parameter modification request, calling the parameter modification interface to jump to the third target level, the target core before the jump is any one of the trusted core or the computing core, and the third target level is higher than the second target level; when the target core before the jump is a trusted core running on the TEE side, according to the parameter information to be modified in the firmware parameter modification request, the firmware parameter update is completed, and the updated firmware parameters are used as the startup configuration parameters at restart. The firmware management method provided by the embodiment of the present application can be directly updated online, with simple update steps, high update efficiency, low update cost, reduced debugging time and wider application scenarios.

[0079] Optionally, after completing the firmware parameter update, the firmware management method further includes: restarting the firmware. It should be understood that the configuration parameters after the restart are the modified firmware parameters.

[0080] Optionally, the multi-core processor further includes a first storage unit and a second storage unit. The first storage unit and the second storage unit may be Figure 2 The first storage unit is any one of the secure memory, shared memory and common memory in the storage unit. Optionally, the first storage unit is the secure memory, and the second storage unit is the shared memory or the common memory.

[0081] For example, the first storage unit is FLASH flash memory, which is a type of memory device, "Flash". Flash memory is a non-volatile memory that can retain data for a long time even without current supply. Its storage characteristics are equivalent to hard disks. This characteristic is the basis for flash memory to become the storage medium of various portable digital devices. The second storage unit is the running memory.

[0082] Please refer to Figure 4 , the trusted core running on the TEE side is connected to the first storage unit and the second storage unit respectively; wherein the first storage unit is used to store firmware parameters, and the second storage unit is used as a running memory; the firmware parameters include at least one configuration parameter list, and the parameter information to be modified includes a list identifier, an offset address, and an update content. Figure 3 In S103, the present application embodiment also provides a possible implementation method, please refer to Figure 5 , S103 includes: S103-1, S103-2 and S103-4, which are described in detail below.

[0083] S103-1, extract at least one configuration parameter list in the first storage unit to the second storage unit.

[0084] Optionally, the startup configuration data (e.g., the configured frequency) may be fixed as a list in a fixed format, referred to as a configuration parameter list. The firmware parameters are stored in the first storage unit in the form of a configuration parameter list. In one possible implementation, the number of configuration parameter lists is greater than or equal to 1, and each configuration parameter list is used to store corresponding firmware parameters.

[0085] Optionally, at least one configuration parameter list is stored in a first designated address interval of the first storage unit. When the firmware is started, at least one configuration parameter list can be extracted in the first designated address interval to complete parameter configuration.

[0086] Because the write operation of any flash device (first storage unit) can only be performed in an empty or erased unit, when updating the firmware parameters, it is necessary to first extract at least one configuration parameter list in the first storage unit to the second storage unit.

[0087] S103-2, updating at least one configuration parameter list in the second storage unit according to the list identifier, the offset address and the update content.

[0088] Optionally, the list identifier may be an index number for indicating a list storing parameters to be updated, the offset address indicates an offset distance between the parameter to be updated and the head address or tail address of the list, and the update content may be a new value.

[0089] It should be understood that during a firmware parameter update, only part of the configuration parameter list may be involved. The list identifier and offset address can be used to quickly determine the replacement in the list of parameters that need to be updated, thereby avoiding adjustment of all configuration parameter lists and reducing the adjustment workload.

[0090] S103-4, writing the updated at least one configuration parameter list into the first storage unit.

[0091] Optionally, before S103 - 4 , it is necessary to erase at least one configuration parameter list originally stored in the first storage unit, and then write the updated at least one configuration parameter list into the first storage unit to complete the firmware parameter update.

[0092] about Figure 5 In S103-2, the present application embodiment also provides a possible implementation method, please refer to Figure 6 , S103-2 includes: S103-2A and S103-2B, which are described in detail below.

[0093] S103-2A, determining the content to be replaced according to the list identifier and the offset address.

[0094] Optionally, firstly, the configuration parameter list to be adjusted is determined according to the list identifier, such as table K; secondly, the target address interval in table K is determined by the offset address, and the content corresponding to the target address interval is the content to be replaced.

[0095] S103-2B, replacing the content to be replaced with the updated content, so as to complete the update of at least one configuration parameter list in the second storage unit.

[0096] Optionally, the updated at least one configuration parameter will be written into the first storage unit to complete the firmware parameter update.

[0097] exist Figure 5 On the basis of how to further improve the security of firmware parameters, the embodiment of the present application also provides a possible implementation method, please refer to Figure 7 After S103-2, the firmware management method further includes: S105 and S106, which are described in detail below.

[0098] S105: Generate a verification code according to the updated at least one configuration parameter list.

[0099] Optionally, a pre-configured verification code generation rule (such as a hash algorithm) is called to process the updated at least one configuration parameter list to generate a verification code. It should be understood that when a hacker modifies the firmware parameters by cracking the system, because he does not understand the verification code generation rule, he will not be able to adaptively adjust the verification code, and he may even miss the verification code.

[0100] The verification code is used to verify at least one configuration parameter list when at least one configuration parameter list is called. For the verification code verification process, please refer to the following Figure 8 The description in .

[0101] S106, writing the verification code into the first storage unit.

[0102] Optionally, the check code is stored in a second designated address interval in the first memory, and the second designated address interval may be adjacent to the first designated address interval or may not be adjacent to the first designated address interval, which is not limited here.

[0103] Optionally, before S106, the check code originally stored in the second designated address interval in the first storage unit needs to be erased, and then the check code corresponding to the updated configuration parameter list is written into the second designated address interval.

[0104] Optionally, refer to Figure 8 , the step of verifying at least one configuration parameter list includes: S201, S202, S203 and S204, which are explained below.

[0105] S201, solving at least one configuration parameter list obtained by calling to obtain a corresponding verification code.

[0106] Optionally, when the firmware is powered on, a configuration parameter list and a corresponding verification code need to be extracted from the first storage unit. The configuration parameter list is then processed according to a pre-configured verification code solution rule to generate a verification code. If a manual is required, the verification code solution rule corresponds to the verification code generation rule, and the two can be the same or different.

[0107] S202, determine whether the verification code matches the check code. If yes, execute S203; if no, execute S204.

[0108] Optionally, when the matching degree between the verification code and the check code is greater than a preset matching degree threshold, it can be determined that the verification code and the check code match. The matching degree threshold may be 95% or 100%, which may be set in advance according to the application scenario.

[0109] It should be understood that when the firmware parameters are updated by the firmware management method provided by the embodiment of the present application, the verification code will also be changed accordingly. When the firmware parameters are called, the generated verification code should match the verification code in the first storage unit. At this time, it means that the verification is passed, that is, S203 is executed, and the firmware startup can be completed through the obtained firmware parameters. When the verification code and the verification code do not match, it means that the firmware parameters may have been maliciously tampered with. At this time, the firmware cannot be started, so an error needs to be reported, that is, S204 is executed. Through this implementation method, the security of the firmware can be improved.

[0110] S203: Determine whether at least one configuration parameter list passes verification.

[0111] Optionally, after passing the verification, the parameter configuration required for this execution is obtained from the parameter interface to perform a series of initializations, start the kernel, load the Trust OS image to start the Trust OS, and load the Guest OS image to start the Guest OS.

[0112] S204, error.

[0113] Please refer to Fig. 9 Regarding the boot firmware component stored in the first storage unit (Flash chip), the present application embodiment also provides a possible implementation method. Fig. 9 As shown in the figure, the boot firmware consists of: firmware (the first program to run after power-on), parameter files and OS images. The parameter files include a list of all configuration parameters (a series of important parameters that need to be called when the firmware is running, such as the configured frequency, etc.) and a checksum.

[0114] exist Figure 5 On the basis of how to further improve the security of firmware parameters, the embodiment of the present application also provides a possible implementation method, please refer to Fig.10 After S103-2, S103 also includes: S103-3, S103-4 includes: S103-4A and S103-4B, which are described in detail below.

[0115] S103-3, generating a verification code according to the updated at least one configuration parameter list.

[0116] Specifically, it is the same as S105 in the previous text.

[0117] S103 - 4A, pair the updated at least one configuration parameter list with the verification code to generate a parameter file.

[0118] Optionally, the parameter file generated by pairing. It should be understood that each configuration parameter list may correspond to a different check code, or at least one configuration parameter list may correspond to a check code. The parameter file may include multiple configuration parameter lists, multiple check codes, and the corresponding relationship between the configuration parameter lists and the check codes, or may include multiple configuration parameter lists and a check code, which is not limited here.

[0119] S103-4B, write the parameter file into the first storage unit.

[0120] Optionally, the parameter file is written into the third designated address interval of the first storage unit. Before S103-4B, the third designated address interval of the first storage unit needs to be erased to erase the originally stored parameter file.

[0121] It should be understood that after at least one configuration parameter list and a verification code paired parameter file are stored in the first storage unit, when the parameter file is retrieved, at least one configuration parameter list and a verification code can be obtained at the same time without the need for two separate retrievals, thereby simplifying the firmware parameter acquisition process.

[0122] See also Fig.11 , Fig.11 A firmware management device is provided in an embodiment of the present application. Optionally, the firmware management device is applied to the multi-core processor described above.

[0123] The firmware management device includes: a receiving unit 301 and a processing unit 302 .

[0124] The receiving unit 301 is used to receive a firmware parameter modification request;

[0125] The processing unit 302 is used to call the parameter modification interface to jump to the third target level when the target core obtains the firmware parameter modification request, wherein the target core before the jump is any one of the trusted core and the computing core, and the third target level is higher than the second target level;

[0126] The processing unit 302 is also used to complete the firmware parameter update according to the parameter information to be modified in the firmware parameter modification request when the target core before the jump is a trusted core running on the TEE side, wherein the updated firmware parameters are used as the startup configuration parameters during restart.

[0127] Optionally, the processing unit 302 is further configured to not update the firmware parameters when the target core before the jump is a computing core running on the REE side.

[0128] Optionally, the multi-core processor includes a first storage unit and a second storage unit, and the trusted core is connected to the first storage unit and the second storage unit respectively; wherein the first storage unit is used to store firmware parameters, and the second storage unit is used as a running memory; the firmware parameters include at least one configuration parameter list, and the parameter information to be modified includes a list identifier, an offset address, and an update content;

[0129] The processing unit 302 is also used to extract at least one configuration parameter list in the first storage unit to the second storage unit; update at least one configuration parameter list in the second storage unit according to the list identifier, offset address and update content; and write the updated at least one configuration parameter list into the first storage unit.

[0130] Optionally, the processing unit 302 may execute the above-mentioned S101 - S106 .

[0131] It should be noted that the firmware management device provided in this embodiment can execute the method flow shown in the above method flow embodiment to achieve the corresponding technical effect. For the sake of brief description, for parts not mentioned in this embodiment, reference can be made to the corresponding contents in the above embodiment.

[0132] The embodiment of the present application also provides a storage medium, which stores computer instructions and programs, which, when read and run, execute the firmware management method of the above embodiment. The storage medium may include memory, flash memory, registers, or a combination thereof.

[0133] An electronic device is provided below, the electronic device comprising: Figure 2 The multi-core processor shown can implement the above firmware management method; for details, please refer to Fig.12 The electronic device includes: a multi-core processor 10, a memory 11, and a bus 12. The multi-core processor 10 may be a CPU. The memory 11 is used to store one or more programs. When the one or more programs are executed by the multi-core processor 10, the firmware management method of the above embodiment is executed.

[0134] like Fig.12 As shown, the electronic device includes a multi-core processor 10, a memory 11, and a bus 12. The multi-core processor 10 and the memory 11 are connected via the bus 12, and the multi-core processor 10 is used to execute executable modules stored in the memory 11, such as computer programs.

[0135] The memory 11 may include a high-speed random access memory (RAM), and may also include a non-volatile memory, such as at least one disk memory.

[0136] The bus 12 may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus. Figure 7 Although only one bidirectional arrow is used in the figure, it does not mean that there is only one bus 12 or only one type of bus 12 .

[0137] The memory 11 is used to store programs, such as programs corresponding to the firmware management device. The firmware management device includes at least one software function module that can be stored in the memory 11 in the form of software or firmware or fixed in the operating system (OS) of the electronic device. After receiving the execution instruction, the multi-core processor 10 executes the program to implement the firmware management method.

[0138] Possibly, the electronic device provided in the embodiment of the present application further includes a communication interface 13. The communication interface 13 is connected to the multi-core processor 10 via a bus. The electronic device can interact with other terminals via the communication interface 13.

[0139] It should be understood that Fig.12 The structure shown is only a schematic diagram of a portion of the electronic device. The electronic device may also include Fig.12 More or fewer components as shown, or with Fig.12 Different configurations are shown. Fig.12 Each component shown in the figure can be implemented by hardware, software or a combination thereof.

[0140] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to the multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or the flowchart, and the combination of boxes in the block diagram and / or the flowchart can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0141] In addition, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0142] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0143] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

[0144] It will be apparent to those skilled in the art that the present application is not limited to the details of the exemplary embodiments described above, and that the present application can be implemented in other specific forms without departing from the spirit or essential features of the present application. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the present application is defined by the appended claims rather than the above description, and it is intended that all changes falling within the meaning and scope of the equivalent elements of the claims be included in the present application. Any reference numeral in a claim should not be considered as limiting the claim to which it relates.

Claims

1. A firmware management method, characterized in that: The method is applied to a multi-core processor, the multi-core processor includes a trusted core running on the TEE side and a computing core running on the REE side, the multi-core processor is configured with a software-type parameter modification interface, the computing core is at a first target level, the trusted core is at a second target level, and the second target level is higher than the first target level, the method includes: When the target core obtains the firmware parameter modification request, the parameter modification interface is called to jump to the third target level, wherein the target core before the jump is any one of the trusted core or the computing core, and the third target level is higher than the second target level; When the target core before the jump is a trusted core running on the TEE side, the firmware parameter update is completed according to the parameter information to be modified in the firmware parameter modification request, wherein the updated firmware parameters are used as the startup configuration parameters at the time of restart; The multi-core processor also includes a first storage unit and a second storage unit, and the trusted core is connected to the first storage unit and the second storage unit respectively; wherein the first storage unit is used to store the firmware parameters, and the second storage unit is used as a running memory; the firmware parameters include at least one configuration parameter list, and the parameter information to be modified includes a list identifier, an offset address, and an update content, and completing the firmware parameter update based on the parameter information to be modified in the firmware parameter modification request includes: extracting the at least one configuration parameter list in the first storage unit to the second storage unit; updating the at least one configuration parameter list in the second storage unit according to the list identifier, the offset address, and the update content; and writing the updated at least one configuration parameter list into the first storage unit.

2. The firmware management method according to claim 1, characterized in that: The method further comprises: When the target core before the jump is a computing core running on the REE side, the firmware parameters are not updated.

3. The firmware management method according to claim 1, characterized in that: After updating the at least one configuration parameter list in the second storage unit according to the list identifier, the offset address and the update content, the method further includes: generating a verification code according to the updated at least one configuration parameter list; The verification code is written into the first storage unit; wherein the verification code is used to verify the at least one configuration parameter list when the at least one configuration parameter list is called.

4. The firmware management method according to claim 3, characterized in that: The verifying the at least one configuration parameter list comprises: Solve at least one configuration parameter list obtained by calling to obtain a corresponding verification code; In a case where the verification code matches the check code, determining that the at least one configuration parameter list passes verification; In the case where the verification code does not match the check code, an error is reported.

5. A firmware management device, characterized in that: The device is applied to a multi-core processor, the multi-core processor includes a trusted core running on the TEE side and a computing core running on the REE side, the multi-core processor is configured with a software-type parameter modification interface, the computing core is at a first target level, the trusted core is at a second target level, the second target level is higher than the first target level, and the device includes: A receiving unit, used for receiving a firmware parameter modification request; a processing unit, configured to call the parameter modification interface to jump to a third target level when the target core obtains a firmware parameter modification request, wherein the target core before the jump is any one of the trusted core or the computing core, and the third target level is higher than the second target level; The processing unit is further used to complete the firmware parameter update according to the parameter information to be modified in the firmware parameter modification request when the target core before the jump is a trusted core running on the TEE side, wherein the updated firmware parameters are used as the startup configuration parameters at the time of restart; The multi-core processor also includes a first storage unit and a second storage unit, and the trusted core is connected to the first storage unit and the second storage unit respectively; wherein the first storage unit is used to store the firmware parameters, and the second storage unit is used as a running memory; the firmware parameters include at least one configuration parameter list, and the parameter information to be modified includes a list identifier, an offset address, and an update content, and completing the firmware parameter update based on the parameter information to be modified in the firmware parameter modification request includes: extracting the at least one configuration parameter list in the first storage unit to the second storage unit; updating the at least one configuration parameter list in the second storage unit according to the list identifier, the offset address, and the update content; and writing the updated at least one configuration parameter list into the first storage unit.

6. The firmware management device according to claim 5, characterized in that: The processing unit is further configured to not update firmware parameters when the target core before the jump is a computing core running on the REE side.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 4 is implemented.

8. An electronic device, characterized in that: include: A multi-core processor and a memory, wherein the memory is used to store one or more programs; When the one or more programs are executed by the multi-core processor, the method according to any one of claims 1 to 4 is implemented.

Images