Processor program signature verification method, related equipment and computer readable storage medium

Abstract

The invention provides a processor program signature verification method, related equipment and a computer readable storage medium, and is applied to the technical field of computers, the method is applied to a system on chip, the system on chip comprises a bus monitoring module, at least one main processor and at least one coprocessor, any one of the processors needing signature verification in the main processors and the coprocessors serves as a target processor, the bus monitoring module calls a target signature verification program corresponding to the target processor, signature verification is conducted on a program to be subjected to signature verification of the target processor through the obtained target signature verification program, and the signature verification result of the program to be subjected to signature verification is marked; according to the invention, the bus monitoring module is additionally arranged in the system on chip, and the verification and signature of the processor program corresponding to each processor are completed by the bus monitoring module, so that the system has important significance for improving the operation safety of the SoC.

Description

Technical Field

[0001] The present application relates to the field of computer technologies, and in particular, to a method for verifying a signature of a processor program, related devices, and a computer-readable storage medium. Background Art

[0002] A System on Chip (SoC) integrates a main processor and a coprocessor inside. By sharing the work of the main processor through the coprocessor, it can ensure that the main processor has more resources to handle core tasks.

[0003] In practical applications, before the SoC runs, it is necessary to verify the signatures of the processor programs corresponding to each processor. The programs to be verified corresponding to each processor are different. Correspondingly, the signature verification programs required by each processor will naturally be different. As the SoC develops towards more cores and higher parallelism, more and more processors are integrated inside the SoC, and more and more processor programs need to be verified. Therefore, how to verify the signature of the processor program and improve the security of the SoC has become one of the technical problems that need to be solved urgently by those skilled in the art. Summary of the Invention

[0004] In view of this, the present application is committed to providing a method for verifying a signature of a processor program, related devices, and a computer-readable storage medium. A bus monitoring module is integrated in the system on chip, and the bus monitoring module verifies the signatures of the programs related to the main processor and the coprocessor, which helps to improve the security of the SoC.

[0005] In a first aspect, the present application provides a method for verifying a signature of a processor program, which is applied to a system on chip. The system on chip includes a bus monitoring module, at least one main processor, and at least one coprocessor. The method includes the following steps executed by the bus monitoring module:

[0006] Call a target signature verification program corresponding to a target processor, where the target processor is any one of the processors that need to be verified among the at least one main processor and the at least one coprocessor;

[0007] Verify the program to be verified of the target processor through the target signature verification program;

[0008] Mark the signature verification result of the program to be verified.

[0009] In an optional implementation manner, the system on chip includes a pre-created signature verification program library. The signature verification program library includes at least one signature verification program, and each signature verification program is linked to a call port;

[0010] The step of calling the target signature verification program corresponding to the target processor includes:

[0011] Determine a target call port corresponding to the target processor based on a preset mapping relationship, where the preset mapping relationship includes the corresponding relationships between each of the main processors and each of the coprocessors and each call port;

[0012] Access the target call port to obtain a target signature verification program linked to the target call port.

[0013] In an optional implementation manner, the system-on-chip further includes a read-only memory, and the signature verification program library is stored in the read-only memory.

[0014] In an optional implementation manner, the system-on-chip further includes a status register group, the status register group includes at least one status register, and each status register corresponds to one of the main processors or the coprocessors;

[0015] Mark the signature verification result of the program to be verified, including:

[0016] If the program to be verified passes the signature verification, write a first value to the status register corresponding to the target processor;

[0017] If the program to be verified fails the signature verification, write a second value to the status register corresponding to the target processor.

[0018] In an optional implementation manner, the first value is used to trigger the target processor to load the program to be verified;

[0019] The second value is used to indicate that the program to be verified fails the signature verification.

[0020] In an optional implementation manner, when the signature verification result indicates that the program to be verified passes the signature verification, the method further includes:

[0021] Configure the storage address of the program to be verified so that the target processor loads the program to be verified according to the storage address.

[0022] In an optional implementation manner, the system-on-chip further includes an address register group, the address register group includes at least one address register, and each address register corresponds to one of the main processors or the coprocessors;

[0023] Configuring the storage address of the program to be verified includes:

[0024] Move the program to be verified to a secure memory;

[0025] Write the storage address of the program to be verified in the secure memory into the address register corresponding to the target processor.

[0026] In an alternative embodiment, the calling of the target signature verification program corresponding to the target processor includes:

[0027] Determine whether the system-on-chip supports trusted authentication;

[0028] If the system-on-chip supports trusted authentication, call the target signature verification program corresponding to the target processor;

[0029] If the system-on-chip does not support trusted authentication, mark the signature verification programs corresponding to the at least one main processor and the at least one coprocessor as signature verification successful.

[0030] In an alternative embodiment, the system-on-chip further includes a system controller, and the bus monitoring module is configured with a power policy unit. After the system-on-chip is powered on, the power policy unit drives the bus monitoring module to start before the system controller;

[0031] Before determining whether the system-on-chip supports trusted authentication, the method further includes:

[0032] Perform signature verification on the signature verification programs of the bus monitoring module and the system controller.

[0033] In an alternative embodiment, the system-on-chip further includes a system controller, and the system controller is configured with a power policy unit. After the system-on-chip is powered on, the power policy unit drives the system controller to start, and the system controller performs signature verification on the signature verification program of the bus monitoring module.

[0034] In a second aspect, the present application provides a bus monitoring module, which is configured to execute the processor program signature verification method according to any one of the first aspects of the present application.

[0035] In a third aspect, the present application provides a system-on-chip, including: an on-chip network, at least one main processor, at least one coprocessor, and the bus monitoring module according to the second aspect of the present application, wherein,

[0036] Each of the main processors, each of the coprocessors, and the bus monitoring module are respectively mounted on the on-chip network.

[0037] In a fourth aspect, the present application provides an electronic device, including: the system-on-chip according to the third aspect of the present application.

[0038] In a fifth aspect, the present application provides a computer-readable storage medium, storing a computer program, and when the computer program is executed, it implements the processor program signature verification method according to any one of the first aspects of the present application.

[0039] Based on the above, the processor program signature verification method provided by this application is applied to a system-on-chip. The system-on-chip includes a bus monitoring module, at least one main processor, and at least one coprocessor. Taking any one of the processors that need signature verification among the main processors and coprocessors as the target processor, the bus monitoring module calls the target signature verification program corresponding to the target processor, uses the obtained target signature verification program to verify the program to be verified of the target processor, and marks the signature verification result of the program to be verified. This application adds a bus monitoring module to the system-on-chip, and the bus monitoring module completes the signature verification of the processor programs corresponding to each processor, which is of great significance for improving the running security of the SoC. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0041] Figure 1 is a structural block diagram of a system-on-chip provided by this application.

[0042] Figure 2 is a flowchart of a processor program signature verification method provided by this application.

[0043] Figure 3 is a flowchart of another processor program signature verification method provided by this application.

[0044] Figure 4 is a flowchart of a program loading method provided by this application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0045] The following will clearly and completely describe the technical solutions in the embodiments of this application with reference to the drawings in the embodiments of this application. Obviously, the described embodiments are only some embodiments of this application, rather than all embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of this application.

[0046] A coprocessor is a processor defined relative to the main processor inside the system-on-chip. Through the coprocessor, processing tasks that the main processor cannot execute or execute with low efficiency are performed, such as signal transmission between devices, management of access devices, graphics processing tasks, and audio processing tasks. Through the cooperation of the main processor and the coprocessor, it can be ensured that the main processor has more resources to handle core tasks.

[0047] In practical applications, before the SoC runs, it is necessary to verify the signatures of the processor programs corresponding to each processor. The programs to be signature-verified corresponding to each processor are different. Correspondingly, the signature-verification programs required for each processor will naturally also be different. As the SoC develops towards more cores and higher parallelism, more and more processors are integrated inside the SoC, and more and more processor programs need to be signature-verified. Therefore, how to verify the signatures of processor programs and improve the security of the SoC has become one of the technical problems that need to be urgently solved by those skilled in the art.

[0048] To solve the above problems, the present application provides a method for verifying the signature of a processor program, which is applied to the system-on-chip provided by the present application. Combining Figure 1 As shown, the system-on-chip provided by the present application includes an on-chip network 10, a system controller 20, at least one main processor 30 (shown as 2 in the figure), at least one co-processor 40 (shown as 2 in the figure), and a bus monitoring module 50.

[0049] The on-chip network 10 serves as a data interaction channel and can realize data interaction between any two or more modules mounted on the on-chip network 10. For example, the system controller 30 sends a start instruction to the main processor 30 through the on-chip network 10, and indicates the storage address of the first instruction to be loaded first after the main processor 30 is started through the start instruction. For another example, the bus monitoring module 50 monitors the data interaction process between the main processor 30 and the co-processor 40 through the on-chip network 10. For yet another example, the non-secure memory 60 and the secure memory 70 outside the system-on-chip are also respectively mounted on the on-chip network 10. Based on this, some modules inside the system-on-chip can perform data reading and writing operations on the non-secure memory 60 or the secure memory 70 through the on-chip network 10. As for other functions of the on-chip network 10, they can be implemented with reference to related technologies and will not be elaborated here.

[0050] In the system-on-chip provided by the present application, the system controller 20 is specifically used to provide a power management function for all power-consuming loads of the system-on-chip, and strip the system security-related functions integrated in the system controller 20 in related technologies, such as program signature verification, data encryption, and other functions. In practical applications, one or more system controllers can be set inside the system-on-chip. In the case of setting multiple system controllers, one of them is used as the main system controller, and the rest are used as auxiliary system controllers. Each system controller is responsible for the power management of the corresponding power-consuming load. The main system controller executes the control system startup firmware after the system-on-chip is powered on, and controls the startup of other system controllers after the startup is completed. After all system controllers are started up, they jointly are responsible for the power supply of each part of the system-on-chip. As for the functional division between each system controller, it can be implemented with reference to related technologies, and the present application does not make any limitations on this.

[0051] The main processor 30 is generally used to carry the operating system and application programs, execute most of the tasks at the application layer, and interact with users for necessary information. In the case of setting a coprocessor in the system-on-chip, it can also cooperate with the coprocessor to complete more system tasks. It should be emphasized that, as mentioned above, there is at least one main processor in the system-on-chip. Based on this, in the case of setting two or more main processors in the system-on-chip, one of the main processors is used to execute the startup program of the system-on-chip and starts up prior to other main processors. Correspondingly, the firmware program related to the main processor for executing the startup program is also the first to be verified for signature. After the signature verification is successful, the main processor for executing the startup program starts up. Then, the module for loading the signature verification (i.e., the bus monitoring module 50 in this application) will verify the signature of the relevant firmware programs of other main processors. Therefore, the object of signature verification in this application does not include the main processor for executing the startup program, but is limited to other main processors other than the main processor for executing the startup program. This premise applies to all subsequent embodiments provided in this application, and the subsequent content will not be repeated.

[0052] As mentioned above, the coprocessor is a processor defined relative to the main processor inside the system-on-chip, and is used to execute processing tasks that the main processor cannot execute or execute with low efficiency. Therefore, in actual applications, the specific functions implemented by the system-on-chip are different, and the number of coprocessors 40 set and their specific functions will also be different. This application does not limit the specific setting of coprocessors in the system-on-chip. Common coprocessors can include: input / output processors, image processors, peripheral controllers, etc., which will not be elaborated one by one here. It should be noted that all coprocessors in the system-on-chip belong to the object of signature verification in this application.

[0053] The bus monitoring module 50 is a newly added functional module in the system-on-chip provided in this application, and can be used to execute the processor program signature verification method provided in each subsequent embodiment of this application to verify the signature of the programs to be verified for the main processor and the coprocessor. Further, the bus monitoring module 50 can also monitor the bus information transmitted in the on-chip network 10, extract the target bus data in the bus information according to the preset screening conditions, and resend the target bus data to the on-chip network 10 when needed. Based on this, without the need for relevant software or functional units to execute the process, the target bus data for implementing the specified function can be provided to the relevant parties, thus saving the time required for the relevant software or functional units to generate the resend data and improving the efficiency of providing the resend data.

[0054] Further, in Figure 1In the shown system on chip, a network on chip 10 is further mounted with a non-secure memory 60 and a secure memory 70. It can be understood that, in terms of the storage medium used by the memories, there is no essential difference between the non-secure memory 60 and the secure memory 70. For example, both can choose Flash memories. The main difference between the two lies in the security requirements for the data access process. The security requirements for accessing the secure memory 70 are higher than those for the non-secure memory 60. It should be noted that, in Figure 1 the shown system on chip, both the non-secure memory 60 and the secure memory 70 are shown by taking external memories outside the system on chip as examples. In another alternative embodiment, the non-secure memory 60 and the secure memory 70 can also be internal memories provided inside the system on chip.

[0055] As for the specific applications of the non-secure memory 60 and the secure memory 70 in this application, they will be elaborated in the subsequent content and will not be described in detail here.

[0056] Furthermore, the system on chip provided by this application further includes a register bank 80. The register bank 80 includes multiple registers for implementing different functions. Different information is recorded through the registers, and other modules in the system on chip can perform different operations based on the information recorded by the registers. As for the specific composition and functions of the register bank 80, they will be elaborated in detail in the subsequent content and will not be described in detail here.

[0057] Based on the system on chip provided in the above embodiment, this application provides a method for verifying and signing a processor program, which is applied to Figure 1 the shown system on chip, and is specifically applied to the bus monitoring module in the system on chip. Compared with the prior art, this application adds a bus monitoring module in the system on chip, and the bus monitoring module completes the verification and signing of the processor programs corresponding to each processor, improving the running security of the SoC.

[0058] Refer to Figure 2 As shown, the method for verifying and signing a processor program provided by this application may include the following steps.

[0059] S100: Invoke the target verification and signing program corresponding to the target processor.

[0060] After the system on chip is powered on, the system controller and the bus monitoring module usually start prior to each main processor and co-processor. Based on this, the system controller provides power management for each internal module in the chip, and the bus monitoring module verifies and signs the programs to be verified related to each module. After the verification and signing pass, each related module starts in sequence according to the established startup process.

[0061] Regarding the startup sequence of the system controller and the bus monitoring module, it depends on the settings of the Power Policy Unit (PPU). The Power Policy Unit is a component dedicated to power management in the system-on-chip. In this application, the Power Policy Unit can be integrated into the system controller or the bus monitoring module. Different integration positions of the Power Policy Unit will result in different startup sequences for the system controller and the bus monitoring module.

[0062] After the system-on-chip is powered on, the Power Policy Unit, as the core component of power management, starts up prior to other components within the system-on-chip. After the Power Policy Unit starts up, if it is integrated into the bus monitoring module, it preferentially powers the bus monitoring module, and the bus monitoring module is reset and released prior to the system controller, that is, it completes startup prior to the system controller. Correspondingly, if the Power Policy Unit is integrated into the system controller, after the Power Policy Unit starts up, it preferentially powers the system controller. The system controller is reset and released prior to the bus monitoring module. After the system controller completes startup, it further powers the bus monitoring module to drive the bus monitoring module to be reset and released, completing the startup of the bus monitoring module.

[0063] In practical applications, the programs that need to be verified for signature during the operation of each processor are different. Correspondingly, the signature verification programs required by each processor (i.e., the programs used to verify the signature of the program to be verified for signature) will naturally be different. Therefore, when verifying the signature of the program to be verified for signature of different processors, the bus monitoring module needs to call the corresponding signature verification program to complete the signature verification. In this application, any one of the main processor and the coprocessor that need to be verified for signature integrated in the system-on-chip is used as the target processor. After the bus monitoring module starts up, it immediately calls the target signature verification program corresponding to the target processor. It should be noted again that the main processor responsible for executing the startup program has completed signature verification before executing this method. Therefore, the target processor mentioned in this application does not include the main processor responsible for executing the startup program. Regarding the signature verification process of the main processor responsible for executing the startup program, it can be implemented with reference to related technologies, and this application will not expand on this.

[0064] In related technologies, the signature verification programs corresponding to each processor are usually managed by the processor itself. When a module responsible for signature verification (such as the system controller) verifies the signature of a certain processor, it needs to first access the storage space corresponding to the corresponding processor to obtain the corresponding signature verification program, and then execute the obtained signature verification program to complete the signature verification of the program to be verified for signature of the processor. Obviously, the method for verifying the signature of the processor program provided by related technologies has a cumbersome process, and the signature verification programs are scattered in each processor, which is not conducive to the unified management and call of the signature verification programs.

[0065] Compared with the related art, the present application provides a preferred way to call the signature verification program. Specifically, a signature verification program library is pre-created in the system-on-chip, and all the signature verification programs corresponding to each processor are stored in the signature verification program library to achieve centralized management of the signature verification programs. In practical applications, to ensure the security of the signature verification program, the signature verification program library can be stored in the ROM (Read Only Memory) of the system-on-chip to reduce the risk of the signature verification program being tampered with. Further, storing the signature verification program library in the ROM also helps to reduce the occupancy of the SRAM (Static Random-Access Memory) storage space of the system-on-chip. At the same time, a call port is allocated to each signature verification program, and each call port is respectively linked to the corresponding signature verification program. By accessing any call port, the signature verification program linked to this port can be called.

[0066] Further, to facilitate the access to the call ports, the present application also provides a preset mapping relationship, which includes the corresponding relationships between each main processor and each coprocessor and each call port. In practical applications, there are various specific implementation ways of the preset mapping relationship. It can be an array or a linked list. Of course, other ways can also be adopted, which will not be listed one by one here. Without exceeding the core idea of the present application, it also belongs to the scope protected by the present application.

[0067] Based on the above content, the bus monitoring module determines the target call port corresponding to the target processor based on the foregoing preset mapping relationship, and then accesses this target call port to obtain the target signature verification program linked to the target call port.

[0068] S110. Verify the program to be signature-verified of the target processor through the target signature verification program.

[0069] The bus monitoring module executes the target signature verification program to verify the program to be signature-verified corresponding to the target processor. As for the specific process of verifying the program to be signature-verified through the target signature verification program, it can be implemented with reference to the related art and will not be elaborated here.

[0070] S120. Mark the signature verification result of the program to be signature-verified.

[0071] After completing the signature verification of the program to be signature-verified, the bus monitoring module further marks the signature verification result of the program to be signature-verified. It can be understood that the signature verification result of the program to be signature-verified includes two possibilities. One is that the signature verification is successful, and the other is that the signature verification fails. Based on this, in practical applications, the two signature verification results can be marked in different ways.

[0072] In an alternative embodiment, the successful signature verification of the program to be verified is characterized by a first numerical value, such as 1. Correspondingly, the failure of the signature verification of the program to be verified is characterized by a second numerical value, such as 0.

[0073] As described above, the system-on-chip provided by the present application is further configured with a register bank, which includes a status register bank. The status register bank includes at least one status register, and each status register corresponds to a main processor or a coprocessor, and there is a one-to-one correspondence between the status register and each processor. Based on this, if the signature verification of the program to be verified is successful, the first numerical value is written into the status register corresponding to the target processor; on the contrary, if the signature verification of the program to be verified fails, the second numerical value is written into the status register corresponding to the target processor to complete the marking of the signature verification result of the program to be verified.

[0074] In practical applications, after the signature verification of the program to be verified is successful, the corresponding processor will further load the program to be verified, thereby completing the startup process of the processor. Based on this, the first numerical value used to characterize the successful signature verification of the program to be verified can also be used to trigger the target processor to load the program to be verified. As for the process of the target processor loading the program to be verified based on the first numerical value, it will be elaborated in detail in the subsequent content and will not be described in detail here.

[0075] In summary, the present application adds a bus monitoring module in the system-on-chip, and the bus monitoring module completes the signature verification of the processor programs corresponding to each processor, meeting the signature verification requirements of the SoC for the processor programs, and is of great significance for improving the running security of the SoC.

[0076] Furthermore, in the prior art, with the increase of power-consuming loads such as coprocessors and main processors inside the system-on-chip, the power supply requirements that the system control processor (SCP, or system control processor) in the system-on-chip needs to process are increasing, resulting in the increasingly complex power management function of the system controller. On this basis, due to the unclear internal function division of the system-on-chip, the system controller is also responsible for system security-related functions, such as performing signature verification of security-related programs and important firmware, etc. This leads to the continuous increase in the complexity of the system controller in terms of design and operation, etc., bringing great challenges to the design and maintenance of the system controller and even the system-on-chip, and consuming a large amount of human and material resources.

[0077] Compared with the prior art, a bus monitoring module is newly added to the system-on-chip in the present application, and the bus monitoring module performs the signature verification work that was previously performed by the system controller in the prior art. That is, the bus monitoring module shares the tasks of the system controller, simplifies the functions of the system controller, enables the system controller to focus on power management tasks, realizes the dedicated use of the system controller for its core function, simplifies the design and maintenance difficulty of the system controller, and saves a large amount of manpower and material resources.

[0078] Furthermore, the signature verification programs corresponding to each processor are centrally managed in a signature verification program library, which can not only standardize the calling process of the signature verification programs, but also effectively improve the calling efficiency and signature verification efficiency of each signature verification program.

[0079] In the related art, before the system-on-chip powers on and runs, the firmware required for the startup of various types of processors within the system-on-chip is stored in a non-secure memory, such as a non-secure FLASH memory. If the non-secure memory is maliciously attacked, the stored firmware is very likely to be tampered with. Once the corresponding processor loads the tampered firmware, it may seriously affect the operating performance of the processor and the system security.

[0080] Based on this, in an application scenario, the system-on-chip has a high security requirement. Before starting the system, it is necessary to verify the credibility of the entire system, that is, it is necessary to perform signature verification on the startup firmware of various types of processors within the system-on-chip. Only when it is determined that the firmware is secure, the processor is allowed to load the signed firmware. Correspondingly, in another application scenario, the system-on-chip has a low security requirement. Of course, it is also possible that the system-on-chip can ensure the security of the firmware through other means. For example, the firmware is stored in a secure memory. In this application scenario, it is not necessary to verify the credibility of the entire system before the system-on-chip starts.

[0081] To meet the above actual application requirements, the present application provides another method for verifying the processor program. Refer to Figure 3 As shown, the method for verifying the processor program provided in this embodiment includes the following steps.

[0082] S200. Determine whether the system-on-chip supports trusted authentication. If yes, execute S210; if no, execute S240.

[0083] To meet the above actual application scenario requirements, after the bus monitoring module powers on and starts, it first determines whether the system-on-chip to which it belongs supports trusted authentication. It can be understood that if the system-on-chip supports trusted authentication, it is necessary to perform signature verification on the program to be signed involved in the startup process of various types of processors in the system-on-chip. On the contrary, if the system-on-chip does not support trusted authentication, the above signature verification process is not required.

[0084] As an alternative implementation, during the manufacturing process of the system-on-chip, according to the chip specifications and user requirements, chip information is programmed into the efuse (one-time programmable memory). The information records whether the system-on-chip supports trusted authentication. The bus monitoring module can determine whether the system-on-chip supports trusted authentication by reading the chip information recorded in the efuse.

[0085] Of course, the bus monitoring module can also determine whether the system-on-chip supports trusted authentication through other means, which will not be elaborated here one by one. Without exceeding the core idea of this application, it also falls within the scope of protection of this application.

[0086] As mentioned above, when the bus monitoring module is configured with a power policy unit, after the system-on-chip is powered on, the power policy unit drives the bus monitoring module to start before the system controller. Therefore, before the bus monitoring module determines whether the system-on-chip supports trusted authentication, it can first verify the signature of the programs to be signed of the bus monitoring module itself and the system controller. Among them, the programs to be signed corresponding to the bus monitoring module itself can include a management protocol parsing and processing program, a basic function program, a function program for calling other ROM interfaces, etc. The programs to be signed of the system controller can include a power management function firmware, a power management protocol parsing and processing firmware, etc. Of course, in actual applications, other programs can also be included, which will not be listed one by one here.

[0087] Correspondingly, when the system controller is configured with a power policy unit, after the system-on-chip is powered on, the power policy unit drives the system controller to start. The system controller verifies the signature of the programs to be signed of the bus monitoring module. After successful signature verification, it drives the bus monitoring module to start, and then executes this step.

[0088] S210. Invoke the target signature verification program corresponding to the target processor.

[0089] In an alternative implementation, the specific implementation of S210 can refer to Figure 2 the relevant content of S100 in the illustrated embodiment, which will not be repeated here.

[0090] S220. Verify the signature of the program to be signed of the target processor through the target signature verification program.

[0091] In an alternative implementation, the specific implementation of S220 can refer to Figure 2 the relevant content of S110 in the illustrated embodiment, which will not be repeated here.

[0092] S230. Mark the signature verification result of the program to be signed.

[0093] In an alternative implementation, the specific implementation of S230 can refer to Figure 2The relevant content of S120 in the illustrated embodiment will not be repeated here.

[0094] S240, Mark all the programs to be verified corresponding to at least one main processor and at least one co-processor as successfully verified.

[0095] In practical applications, the operation of some software (including system software and application software) depends on the verification result of the program to be verified in the system-on-chip. Usually, only when the program to be verified is successfully verified can the corresponding software be normally started and run. Based on this, when it is determined that the system-on-chip does not support trusted authentication, the bus monitoring module marks all the programs to be verified loaded in the system-on-chip as successfully verified. For the aforementioned software, all the programs to be verified in the system-on-chip are successfully verified, and the corresponding software can be normally started and run. Of course, in fact, the aforementioned software does not perceive whether the relevant programs to be verified in the system-on-chip are truly verified successfully.

[0096] Continuing with the previous example, as a possible implementation manner, a status register group is configured in the system-on-chip. Each status register in the status register group corresponds to a main processor or a co-processor, and there is a one-to-one correspondence between the status register and each processor. Based on this, the bus monitoring module can mark the programs to be verified corresponding to each processor as successfully verified by writing a first value to the status register corresponding to each processor.

[0097] S250, Configure the storage address of the program to be verified when the verification result indicates that the program to be verified is successfully verified.

[0098] First of all, it should be noted that in combination with Figure 3 as shown, whether the programs to be verified of each processor are successfully verified when the system-on-chip supports trusted authentication, or the programs to be verified of each processor are marked as successfully verified when the system-on-chip does not support trusted authentication, this step needs to be continued.

[0099] It can be understood that the normal operation of each processor in the system-on-chip depends on the corresponding program to be verified. After the program to be verified is successfully verified, the processor needs to execute the corresponding program to be verified to achieve the established function, and the access and execution of any program code are inseparable from the storage address. Based on this, the storage address mentioned in this embodiment is the storage address of the program to be verified, and the target processor can load the program to be verified that has been successfully verified according to the storage address configured by the bus monitoring module.

[0100] In an alternative embodiment, the register bank of the system-on-chip further includes an address register bank. Similar to the aforementioned status register bank, the address register bank includes at least one address register, and each address register corresponds to a main processor or a coprocessor, that is, there is a one-to-one correspondence between the address register and the processor. As mentioned above, the program to be verified is stored in the non-secure memory before the verification is successful. Therefore, after the program to be verified passes the verification, the bus monitoring module first moves the program to be verified to the secure memory and writes the storage address of the program to be verified in the secure memory into the address register corresponding to the target processor, completing the configuration of the above memory address.

[0101] In summary, compared with the prior art, the present application adds a bus monitoring module in the system-on-chip, and the bus monitoring module completes the verification of the programs of each processor, which helps to simplify the functions of the system controller, enables the system controller to focus on the power management task, realizes the dedicated use of the system controller, simplifies the design and maintenance difficulty of the system controller, and saves a lot of manpower and material resources.

[0102] Furthermore, by this method, for a system-on-chip that supports trusted authentication, the programs corresponding to each processor are respectively verified and the true verification results are marked. For a system-on-chip that does not support trusted authentication, the programs corresponding to each processor are respectively marked as verified successfully. With such settings, for software that depends on the verification results of the programs, it can be respectively applied to a system-on-chip that supports trusted authentication and a system-on-chip that does not support trusted authentication, without the need to develop different software for the two types of system-on-chips. Therefore, by this method, the usage range of the software can be significantly improved, the development cycle and cost of the software can be reduced, and at the same time, the system-on-chip can be compatible with more types of software.

[0103] After the bus monitoring module completes the verification of the programs to be verified corresponding to each processor, if the verification is successful (including being marked as verified successfully), each processor can load the corresponding program to start. Taking the aforementioned target processor as an example, the startup process of the target processor is briefly introduced below.

[0104] See Figure 4 , the startup process of the target processor may include the following steps.

[0105] S300. Obtain the verification result of the program to be verified.

[0106] As mentioned above, the verification result of the program to be verified of the target processor is stored in the status register corresponding to the target processor. Based on this, the target processor can obtain the verification result of the program to be verified by accessing the corresponding status register.

[0107] S310. Determine whether the program to be verified for signature is successfully verified for signature. If so, execute S320; if not, execute S350.

[0108] If the first value indicating successful signature verification is stored in the status register, it is determined that the program to be verified for signature is successfully verified for signature, and S320 is executed. On the contrary, if the second value indicating failed signature verification is stored in the status register, it is determined that the program to be verified for signature fails in signature verification, and S350 is executed.

[0109] S320. Obtain the storage address of the program to be verified for signature.

[0110] In an optional implementation, the register set of the system-on-chip further includes an address register set. The address register set includes at least one address register, and each address register corresponds to a main processor or a coprocessor, that is, there is a one-to-one correspondence between the address register and the processor. As described above, the program to be verified for signature is stored in the non-secure memory before successful signature verification. Therefore, after the program to be verified for signature passes the signature verification, the bus monitoring module first moves the program to be verified for signature to the secure memory and writes the storage address of the program to be verified for signature in the secure memory into the address register corresponding to the target processor.

[0111] The target processor accesses the address register corresponding to the target processor to obtain the stored storage address.

[0112] S330. Determine whether the storage address is valid. If so, execute S340; if not, execute S350.

[0113] After obtaining the storage address of the program to be verified for signature (which is actually a program that has passed the signature verification), the target processor first determines whether the obtained storage address is valid. For example, determine whether the storage address is within the address range corresponding to the secure memory, or determine whether the format of the storage address is correct, etc. In practical applications, the determination of whether the storage address is valid can refer to other related technologies, and this application does not make specific limitations on this process. When the storage address is valid, the target processor continues to execute S340; otherwise, it continues to execute S350.

[0114] S340. Load the program to be verified for signature according to the storage address.

[0115] After determining that the storage address is valid, the target processor can jump to the storage address and execute the program to be verified for signature stored at this address until the target processor completes startup.

[0116] S350. Exit.

[0117] Combined with Figure 4As shown, when the signature verification of the program to be verified fails or the obtained storage address is invalid, the target processor exits the current startup process and enters the power-off or sleep state, waiting for the next wake-up.

[0118] The present application also provides a bus monitoring module, which is configured to execute the processor program signature verification method provided in any of the foregoing embodiments.

[0119] The present application also provides an electronic device, including the system-on-chip provided in the foregoing embodiments.

[0120] In some embodiments, the present embodiment also provides a computer-readable storage medium, such as a floppy disk, an optical disc, a hard disk, a flash memory, a USB flash drive, an SD (Secure Digital Memory Card) card, an MMC (Multimedia Card) card, etc. One or more instructions for implementing the above steps are stored in the computer-readable storage medium. When the one or more instructions are executed by one or more processors, the processors execute the processor program signature verification method described above. For the relevant specific implementation, please refer to the foregoing description and will not be elaborated here.

[0121] In addition to the above methods and devices, the embodiments of the present application may also be a computer program product, which includes computer program instructions. When the computer program instructions are run by a processor, the processor executes the steps in the processor program signature verification method according to various embodiments of the present application described in the above content of this specification.

[0122] The computer program product can be written in any combination of one or more programming languages to write program code for performing the operations of the embodiments of the present application. The programming languages include object-oriented programming languages, such as Java, C++, etc., and also include conventional procedural programming languages, such as the "C" language or similar programming languages. The program code can be executed completely on the user computing device, partially on the user device, executed as an independent software package, partially on the user computing device and partially on a remote computing device, or completely on a remote computing device or server.

[0123] Those skilled in the art can understand that the content disclosed in the present disclosure can have various variations and improvements. For example, the various devices or components described above can be implemented by hardware, or can be implemented by software, firmware, or some or all of the combinations of the three.

[0124] In addition, although the present disclosure makes various references to certain units in the systems according to embodiments of the present disclosure, any number of different units may be used and run on the client and / or the server. The units are merely illustrative, and different aspects of the systems and methods may use different units.

[0125] Flowcharts are used in the present disclosure to illustrate the steps of the methods according to embodiments of the present disclosure. It should be understood that the preceding or subsequent steps are not necessarily carried out precisely in sequence. On the contrary, the steps may be processed in reverse order or simultaneously. At the same time, other operations may also be added to these processes.

[0126] Those of ordinary skill in the art can understand that all or part of the steps in the above methods can be completed by instructing relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium, such as a read-only memory, etc. Optionally, all or part of the steps of the above embodiments can also be implemented using one or more integrated circuits. Accordingly, each module / unit in the above embodiments can be implemented in the form of hardware or in the form of a software functional module. The present disclosure is not limited to any specific form of combination of hardware and software.

[0127] Unless otherwise defined, all terms used herein have the same meaning as commonly understood by those of ordinary skill in the art to which the present disclosure pertains. It should also be understood that terms such as those defined in a general dictionary should be interpreted as having a meaning consistent with their meaning in the context of the relevant art, and should not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0128] The above is an illustration of the present disclosure and should not be considered a limitation thereof. Although several exemplary embodiments of the present disclosure have been described, those skilled in the art will readily understand that many modifications can be made to the exemplary embodiments without departing from the novel teachings and advantages of the present disclosure. Therefore, all such modifications are intended to be included within the scope of the present disclosure as defined by the claims. It should be understood that the above is an illustration of the present disclosure and should not be considered limited to the specific embodiments disclosed, and modifications to the disclosed embodiments and other embodiments are intended to be included within the scope of the appended claims. The present disclosure is defined by the claims and their equivalents.

Claims

1. A processor program signature verification method, characterized in that: Applied to a system on chip, the system on chip includes a bus snooping module, at least one main processor and at least one coprocessor, and the method includes the following steps performed by the bus snooping module: Calling a target signature verification program corresponding to a target processor, where the target processor is any one of the at least one main processor and the at least one coprocessor that needs signature verification; Verifying the signature of the program to be verified of the target processor by using the target signature verification program; Mark the signature verification result of the signature verification program.

2. The method according to claim 1, characterized in that The system on chip includes a pre-created signature verification program library, the signature verification program library includes at least one signature verification program, and each of the signature verification programs is linked to a call port; The calling of the target signature verification program corresponding to the target processor includes: Determine a target call port corresponding to the target processor based on a preset mapping relationship, wherein the preset mapping relationship includes a correspondence between each of the main processors and each of the coprocessors and each of the call ports; Access the target call port to obtain the target signature verification program linked to the target call port.

3. The method according to claim 2, characterized in that The system on chip also includes a read-only memory, and the signature verification program library is stored in the read-only memory.

4. The method according to claim 1, characterized in that: The system on chip further includes a status register group, the status register group includes at least one status register, each of the status registers corresponds to one of the main processors or the coprocessor; Mark the verification result of the signature verification procedure, including: If the signature verification of the program to be verified succeeds, writing a first value into a status register corresponding to the target processor; If the signature verification of the program to be verified fails, a second value is written to a status register corresponding to the target processor.

5. The method according to claim 4, characterized in that The first value is used to trigger the target processor to load the program to be verified; The second value is used to indicate that the signature verification procedure fails.

6. The method according to claim 1, characterized in that When the signature verification result indicates that the signature verification of the to-be-verified signature program is successful, the method further includes: The storage address of the program to be verified is configured so that the target processor loads the program to be verified according to the storage address.

7. The method according to claim 6, characterized in that The system on chip further comprises an address register group, wherein the address register group comprises at least one address register, and each of the address registers corresponds to one of the main processors or the coprocessors; Configuring the storage address of the program to be verified includes: Moving the program to be verified to a secure storage; The storage address of the program to be verified in the secure memory is written into the address register corresponding to the target processor.

8. The method according to claim 1, characterized in that The calling of the target signature verification program corresponding to the target processor includes: Determining whether the system on chip supports trusted authentication; If the system on chip supports trusted authentication, calling the target signature verification program corresponding to the target processor; If the system on chip does not support trusted authentication, the programs to be verified corresponding to the at least one main processor and the at least one coprocessor are marked as successfully verified.

9. The method according to claim 8, characterized in that The system on chip further includes a system controller, and the bus monitoring module is configured with a power policy unit, and after the system on chip is powered on, the power policy unit drives the bus monitoring module to start before the system controller; Before determining whether the system on chip supports trusted authentication, the method further includes: The bus monitoring module and the program to be verified of the system controller are verified.

10. The method according to claim 8, characterized in that The system on chip also includes a system controller, and the system controller is configured with a power policy unit. After the system on chip is powered on, the power policy unit drives the system controller to start, and the system controller verifies the signature of the program to be verified of the bus monitoring module.

11. A bus monitoring module, characterized in that: The bus monitoring module is configured to execute the processor program signature verification method according to any one of claims 1 to 10.

12. A system on chip, characterized in that: include: A network on chip, at least one main processor, at least one coprocessor and a bus snooping module as claimed in claim 11, wherein: Each of the main processors, each of the coprocessors and the bus monitoring module is mounted on the on-chip network respectively.

13. An electronic device, characterized in that: include: The system on chip as claimed in claim 12.

14. A computer-readable storage medium, characterized in that: A computer program is stored, and when the computer program is executed, the processor program signature verification method according to any one of claims 1 to 10 is implemented.

Images