A method and apparatus for improving system trusted boot determination

Abstract

The application relates to the technical field of computer software security, in particular to an implementation method and device for improving system trusted startup certainty. An asymmetric multiprocessor core architecture is adopted, one processor core is bound as a secure core of a trusted domain, the secure core is shielded during normal domain startup, the remaining processor cores run the normal domain and can switch between the normal domain and the secure domain; a task scheduler is constructed on the secure core, priority is divided according to real-time properties of security services and scheduling management is conducted; when the normal domain task requests a security service, the trusted domain migrates the corresponding task to the secure core and immediately returns a request response, releases the normal domain processor core, and the task initiating the request is converted into a blocked state; the secure core executes the security service and notifies the normal domain after ending to process the execution result; the application can control the switching execution time of the normal domain and the trusted domain, meets the requirement of an embedded real-time system on certainty, and eliminates the threat of cache side channel attacks.

Description

Technical Field

[0001] This invention relates to the field of computer software security technology, and specifically to a method and apparatus for improving the deterministic reliability of system startup. Background Technology

[0002] Embedded systems are widely used in equipment, communications, industrial manufacturing, and home appliances. The increasingly complex implementation of software functions and network interconnection have brought information security threats, making it a common need to ensure the reliability of the system startup and operation process.

[0003] However, embedded real-time systems have strict requirements for real-time performance and determinism, and the execution of security mechanisms must not violate the system's deterministic requirements.

[0004] Existing technologies utilize the trusted root and trusted execution environment of hardware security capabilities to introduce a trusted boot mechanism: the system is divided into a trusted domain and a normal domain. The trusted domain performs sensitive operations and provides security services, while the normal domain communicates with the trusted domain through a specific entry point to invoke security services and cannot directly access the memory space of the trusted domain. From power-on, the system sequentially verifies the integrity and legitimacy of the executable image. Upon successful verification, execution control is transferred, gradually building a chain of trust. The trusted domain is triggered by the normal domain and lacks proactive task scheduling capabilities. The normal domain invokes the security verification service using a synchronous invocation protocol, entering the highest security privilege state (EL3) through a specific entry point, switching the processor core to a secure state to execute the security verification service, and switching back to a non-secure state after service execution to return to the normal domain to continue execution.

[0005] However, the above solution has the following problems: the ordinary domain and the trusted domain share the processor core, and synchronously calling security instructions causes the system to switch to the trusted domain to execute security services. Once an execution error occurs, the time to return to the ordinary domain is uncontrollable, affecting the real-time performance and determinism of the system. Furthermore, when sensitive operation data is filled into the cache, it competes with the ordinary domain for cache space, posing a cache side-channel attack threat. Summary of the Invention

[0006] In view of the problems mentioned in the prior art, the present invention proposes a method and apparatus for improving the deterministic reliability of system startup, so as to solve the problems in the background art.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: This invention proposes a method for improving the deterministic reliability of system startup, comprising: Based on an asymmetric multiprocessor core architecture, one processor core is bound to a secure core that runs a trusted domain. The secure core is transparent to the ordinary domain and is shielded when the ordinary domain starts up. The remaining processor cores are configured to run the ordinary domain and can switch between the ordinary domain and the secure domain. A task scheduler is built on the security kernel. The execution priority is divided according to the real-time attributes of each security service. The task scheduler is used to schedule and manage the security service tasks according to the priority. When a task in the ordinary domain requests a security service, the trusted domain responds to the request, migrates the task corresponding to the requested security service to the security core, and returns a request response to the ordinary domain, so that the ordinary domain releases the processor core it occupies, and the task that initiated the request is converted to a blocked state. The task scheduler schedules the security kernel to execute the migrated security service and notifies the ordinary domain after the security service is completed, so that the ordinary domain can process the execution result of the security service.

[0008] As a further improvement to the present invention, it also includes: During the system power-on startup process, the digital signature of the image to be loaded is verified based on the public key certificate PKI system to verify the legitimacy of the image to be loaded; The certificate verification information is linked to the trusted domain mirror in the form of a special segment. The trusted domain acts as a verification server and verifies the legality of the public key used to verify the digital signature based on the certificate verification information.

[0009] As a further improvement of the present invention, the trusted domain verifies the legality of the public key used to verify the digital signature based on the certificate verification information, including: After power-on, the trusted domain extracts the certificate verification information from the special segment from the trusted domain image; The trusted domain verifies whether the currently used public key was issued by a certificate authority based on the certificate verification information, and the public key certificate is bound to the public key used to verify the digital signature; After successful verification, the trusted domain uses a public key to verify the digital signature of the subsequent images to be loaded.

[0010] As a further improvement of the present invention, the certificate verification information is linked to the trusted domain mirror in the form of a special segment, including: The certificate verification information is linked as an independent data segment to the trusted domain image, and the data segment is loaded into the memory space of the trusted domain along with the trusted domain image.

[0011] As a further improvement of the present invention, the scheduling and management of security service tasks according to priority includes: The security services are scheduled to be executed on the security core in descending order of priority.

[0012] As a further improvement of the present invention, scheduling the security services in descending order of priority includes: The task scheduler allocates the security service to a task queue with the corresponding priority based on the real-time attribute of the security service; The security core schedules and executes the security services in each of the task queues in descending order of priority.

[0013] As a further improvement of the present invention, when the security service is executed on the security core, it uses a cache exclusively owned by the security core. The cached data generated during the execution is retained in the cache of the security core, and the processor core running the ordinary domain cannot access the cached data.

[0014] As a further improvement of the present invention, the security kernel is transparent to ordinary domains, including: The ordinary domain communicates with the trusted domain through a specific entry point, and the memory access range of the ordinary domain does not include the memory space of the trusted domain. As a further improvement of the present invention, the trusted domain responds to the request by migrating the task corresponding to the requested security service to the security kernel and returning a request response to the ordinary domain, including: The task in the ordinary domain is trapped in the trusted domain through a specific entry point; After receiving the request, the trusted domain transmits the security service task corresponding to the request and the data corresponding to the task to the task queue of the security core; The trusted domain returns a request response to the ordinary domain, the request response indicating that the request has been received by the trusted domain.

[0015] This invention proposes a device for improving the deterministic reliability of system startup, based on an asymmetric multiprocessor core architecture, comprising: A configuration module is used to bind one processor core as a secure core running a trusted domain. The secure core is transparent to the ordinary domain and is masked when the ordinary domain starts up. The remaining processor cores are configured to run in the ordinary domain and can switch between the ordinary domain and the secure domain. The scheduling module is used to build a task scheduler on the security kernel, divide the corresponding execution priorities according to the real-time attributes of each security service, and manage the security service tasks according to priority through the task scheduler. The request processing module is used to, when a task in the ordinary domain requests a security service, the trusted domain responds to the request, migrates the task corresponding to the requested security service to the security core, and returns a request response to the ordinary domain, so that the ordinary domain releases the processor core it occupies, and the task that initiated the request is converted to a blocked state; The scheduling module is also used to schedule the security core to execute the migrated security service through the task scheduler, and notify the ordinary domain after the security service is executed so that the ordinary domain can process the execution result of the security service.

[0016] Compared with the prior art, the present invention achieves the following technical effects: In this invention, after the trusted domain responds to a request, it migrates the task corresponding to the security service to the secure core and returns a request response to the ordinary domain. This causes the ordinary domain to release the processor core it occupies, and the single task that initiated the request is put into a blocked state. The processor core of the ordinary domain has been released while waiting for the security service to execute and can schedule other tasks. The operation of the ordinary domain is no longer dependent on the execution progress of the security service. Even if the security service fails to execute on the secure core, only the single request task in the blocked state is affected, not the entire ordinary domain. This makes the switching execution time between the ordinary domain and the trusted domain controllable, meeting the strict requirements of embedded real-time systems for real-time performance and determinism. At the same time, this application binds a processor core to a secure core running the trusted domain based on an asymmetric multiprocessor core architecture. This core is transparent to the ordinary domain and is shielded when the ordinary domain starts. Sensitive operations of the security service are migrated to this secure core for execution. The cache filling of sensitive data occurs in the secure core, which is imperceptible and cannot be run by the ordinary domain. There is no cache contention between the ordinary domain and the security service at the hardware core level, thus eliminating the attack surface of cache side-channel attacks and further improving the security of the system.

[0017] Furthermore, compared to existing solutions where trusted domains are triggered by ordinary domains and lack proactive task scheduling capabilities, this application constructs a task scheduler on the security kernel, divides execution priorities according to the real-time attributes of security services, and performs scheduling management. This allows the execution order of multiple concurrent security service requests to be determined by priority, enabling security services with high real-time requirements to be executed quickly, further enhancing the predictability of security service execution time. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the overall process of the present invention; Figure 2 This is a schematic diagram of the trusted boot function of the present invention; Figure 3 This is a schematic diagram of the asynchronous call protocol for secure services in this invention; Figure 4 This is a schematic diagram of the trusted boot public key certificate of the present invention. Detailed Implementation

[0019] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of the invention. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0020] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0021] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0022] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection, an electrical connection, or a communication connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0023] In this invention, unless otherwise explicitly specified and limited, "above" or "below" the second feature can include direct contact between the first and second features, or contact between the first and second features through another feature between them. Furthermore, "above," "over," and "on top" of the second feature includes the first feature being directly above or diagonally above the second feature, or simply indicates that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature includes the first feature being directly above or diagonally above the second feature, or simply indicates that the first feature is at a lower horizontal level than the second feature.

[0024] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0025] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0026] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0027] The accompanying drawings illustrate various structural schematic diagrams according to embodiments disclosed in this invention. These drawings are not to scale, and some details have been enlarged for clarity, and some details may have been omitted. The shapes of the various regions and layers shown in the drawings, as well as their relative sizes and positional relationships, are merely exemplary and may deviate from reality due to manufacturing tolerances or technical limitations. Furthermore, those skilled in the art can design regions / layers with different shapes, sizes, and relative positions as needed.

[0028] See Figure 1 This implementation proposes a method to improve the deterministic reliability of system startup, including: Based on an asymmetric multiprocessor core architecture, one processor core is bound to a secure core that runs a trusted domain. The secure core is transparent to the ordinary domain and is shielded when the ordinary domain starts up. The remaining processor cores are configured to run the ordinary domain and can switch between the ordinary domain and the secure domain. A task scheduler is built on the security kernel. The execution priority is divided according to the real-time attributes of each security service. The task scheduler is used to schedule and manage the security service tasks according to the priority. When a task in the ordinary domain requests a security service, the trusted domain responds to the request, migrates the task corresponding to the requested security service to the security core, and returns a request response to the ordinary domain, so that the ordinary domain releases the processor core it occupies, and the task that initiated the request is converted to a blocked state. The task scheduler schedules the security kernel to execute the migrated security service and notifies the ordinary domain after the security service is completed, so that the ordinary domain can process the execution result of the security service.

[0029] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0030] Step 1: Configure processor cores based on the asymmetric multiprocessor architecture. In the multi-core processor of the embedded real-time system, select one processor core and bind it as a secure core dedicated to the trusted domain. The secure core is transparent to the ordinary domain. When the ordinary domain starts up, it excludes the secure core from the set of schedulable processor cores by configuring the startup parameters of the asymmetric multiprocessor architecture. This makes the ordinary domain's operating system unaware of the secure core's existence and unable to schedule any ordinary domain tasks to execute on the secure core. The remaining processor cores are configured to run in the ordinary domain. These processor cores have the ability to switch between the ordinary domain and the secure domain. That is, when an ordinary domain task needs to initiate a security service request, the processor core can temporarily switch to the secure domain state to complete the request transmission, and then switch back to the ordinary domain state to continue executing the ordinary domain task.

[0031] It's important to clarify that the transparency of the secure core to the ordinary domain has the following implications. Firstly, at the processor core resource level, the secure core is not recognized as an available computing resource by the ordinary domain's task scheduler. The ordinary domain cannot schedule any ordinary domain tasks on the secure core, ensuring that all the secure core's computing resources are used for the security services of the trusted domain. Secondly, at the memory access level, the ordinary domain communicates with the trusted domain through a specific entry point. The ordinary domain's memory access scope does not include the trusted domain's memory space; that is, the ordinary domain cannot directly read or write the memory areas owned by the trusted domain. The trusted domain's memory space is physically isolated from the ordinary domain, either through a hardware memory management unit.

[0032] Through the above configuration, the trusted domain and the ordinary domain achieve spatial isolation at the physical level. Each domain has its own independent computing and cache resources and does not interfere with the other. This provides a hardware foundation for the implementation of subsequent asynchronous call protocols and cuts off the path of cache side-channel attacks, because the cache data generated when the security service is executed is filled in the cache exclusively owned by the security core, and the processor core running in the ordinary domain cannot physically access this cache data.

[0033] like Figure 2 As shown, the system in this embodiment includes multiple processor cores, one of which is bound as a secure core dedicated to running the trusted domain; the remaining processor cores are configured as ordinary cores, running the ordinary domain. Multiple user tasks run in the ordinary domain. When these tasks need to call security services, the secure core and ordinary cores each have independent cache resources. The execution of the security service is entirely completed on the secure core. The instructions are trapped in the trusted domain, and the trusted domain forwards the security service request to the secure core for execution.

[0034] Step 2: Build a task scheduler on the security kernel. This task scheduler is used to assign corresponding execution priorities to security services based on their real-time attributes, and to schedule and manage security service tasks according to the assigned priorities.

[0035] As a specific implementation, the task scheduler can allocate security services to task queues of corresponding priorities based on their real-time attributes, with each priority level corresponding to an independent task queue. When executing security services, the security kernel schedules and executes the security services in each task queue sequentially, from highest to lowest priority. For example, during trusted boot, image signature verification is a critical step determining whether the system can continue booting and has the highest real-time requirements, thus being classified as a high-priority task; while some non-critical configuration query-type security services can be classified as low-priority tasks. The task scheduler on the security kernel ensures that high-priority tasks are scheduled and executed first, thereby guaranteeing a rapid response for critical security services.

[0036] It should be noted that the purpose of building an independent task scheduler on the security kernel in this application is to enable the trusted domain to have the ability to actively schedule tasks. Unlike existing technologies, the execution order of security services is no longer determined by the calling order of ordinary domains. This allows the trusted domain to arrange the execution order according to the real-time requirements of the security service itself, further enhancing the predictability of the execution time of the security service.

[0037] Step 3: Establish an asynchronous invocation protocol for security services. When a task on the ordinary domain needs to request a security service, the task enters the trusted domain through a specific entry point (such as a security monitoring invocation command). After receiving the request, the trusted domain passes the corresponding security service task, along with its input parameters and context data, to the task queue of the security kernel for scheduling and execution. After the security service task is successfully migrated to the security kernel, the trusted domain immediately returns a request response to the ordinary domain, indicating that the security service request has been successfully received by the trusted domain.

[0038] Upon receiving the response to the request, the requesting task switches from the running state to the blocked state, and the processor core previously occupied by that task is released, allowing other ready tasks in the normal domain to continue execution. Specifically, while the security service is executing on the security core, the processor core in the normal domain continues to execute other normal domain tasks. When the task scheduler on the security core schedules the security service task according to priority, the security core executes the security service, and intermediate data and calculation results generated during execution are stored in a cache exclusively for the security core.

[0039] After the security service is completed, the security kernel sends an execution result notification to the normal domain through the inter-kernel interrupt mechanism. This notification carries the execution status information of the security service (such as success or failure) and the execution result data. Upon receiving the inter-kernel interrupt, the normal domain wakes up the corresponding task that was previously in a blocked state according to the notification content. The woken-up task obtains the execution result and continues to execute the subsequent processing flow.

[0040] like Figure 3 As shown, in the normal domain, when a task needs to call a security service, the task initiates a security service request through a specific entry point (e.g., a security monitoring call command). Upon receiving the request, the trusted domain migrates the corresponding security service task, along with its input parameters and context data, to the task queue of the security kernel for scheduling and execution. It then returns a request response to the normal domain, indicating that the security service request has been successfully received by the trusted domain. Upon receiving the request response, the normal domain switches the requesting task from the running state to the blocked state, and the processor core previously occupied by the task is released, allowing other ready tasks in the normal domain to continue execution. Specifically, while the security service is executing on the security kernel, the processor core in the normal domain is not idle or exclusively occupied, but continues to execute other normal domain tasks. When the task scheduler on the security kernel schedules the security service task according to priority, the security kernel executes the security service. After completion, it sends an execution result notification to the normal domain via an inter-core interrupt. This notification carries the execution status information and execution result data of the security service. After receiving the inter-core interrupt, the normal domain wakes up the corresponding task that was previously blocked according to the notification content. The woken-up task obtains the execution result and continues to execute the subsequent processing flow.

[0041] To more clearly illustrate the difference between the asynchronous call protocol of this application and the existing synchronous call protocol: In the existing synchronous call protocol, after a normal domain task initiates a security service request, the current processor core switches to the security state to execute the security service. During the service execution, the processor core is fully occupied, and the normal domain must block and wait until the security service is completed and switches back to the non-security state. Only then can the processor core continue to execute the normal domain task. Once the security service execution is abnormal or takes too long, the overall scheduling of the normal domain is severely affected.

[0042] In the asynchronous call protocol of this application, after a task in the ordinary domain initiates a security service request, the trusted domain only needs to migrate the task to the secure kernel and immediately return a response. The processor core of the ordinary domain is then released and can execute other tasks. Only the single task that initiated the request enters a blocked state to wait for notification. The security service executes independently on the secure kernel, and after execution, it notifies the ordinary domain to wake up the corresponding task through an inter-kernel interrupt. Through the above asynchronous call protocol, the overall operation of the ordinary domain is no longer dependent on the execution progress of the security service. Even if the security service encounters an error or its execution time exceeds expectations on the secure kernel, the affected scope is limited to the single requesting task in the blocked state, rather than the entire ordinary domain. This makes the switching execution time between the ordinary domain and the trusted domain controllable, meeting the real-time and deterministic requirements of embedded real-time systems.

[0043] In some embodiments of this application, the aforementioned asynchronous security service invocation protocol can be specifically applied to the trusted boot scenario of an embedded system. During system power-on startup, the startup task in the ordinary domain needs to call the image signature verification service provided by the trusted domain to verify the legitimacy of the lower-level startup image to be loaded. According to the asynchronous invocation protocol of this application, the startup task initiates a signature verification request to the trusted domain through a specific entry point. After receiving the request, the trusted domain migrates the signature verification task to the secure core and immediately returns a response to the startup task. The startup task then enters a blocked state and releases the processor core it occupies. The processor core can then continue to execute other startup preparation tasks (such as initializing peripherals, loading insecure configurations, etc.).

[0044] The task scheduler on the secure core identifies the signature verification service as a high-real-time security service, assigns it to a high-priority task queue, and executes it first. After the secure core completes the signature verification, it notifies the ordinary domain via an inter-core interrupt. The ordinary domain then wakes up the startup task and retrieves the verification result. If the verification passes, the startup task continues loading the next-level image; if the verification fails, the startup task executes the corresponding exception handling procedure. Throughout this process, the processor cores in the ordinary domain are not idle while waiting for the signature verification result, but continue to advance other startup preparation work, thereby shortening the overall system startup time and ensuring the determinism of the startup process.

[0045] Step 4: Construct a trusted public key certificate verification mechanism for booting. During system power-on startup, the trusted domain needs to perform digital signature verification on each level of the image to be loaded to verify the image's legitimacy and integrity. Digital signature verification relies on the public key; if the public key itself is tampered with or replaced, the entire verification mechanism will lose its trusted foundation. Therefore, this application adopts the concept of the Public Key Certificate (PKI) system to ensure the legitimacy of the public key.

[0046] Specifically, the administrators maintaining the trusted domain environment act as Certificate Authorities (CAs), while the trusted domain itself acts as a certificate verification server. During the compilation or building phase of the trusted domain image, certificate verification information is linked as a separate data segment to the executable file of the trusted domain image. This data segment contains certificate verification information signed by the CA, used to verify the legitimacy of the public key. Because this data segment is linked inside the trusted domain image, attackers cannot replace or tamper with this certificate verification information without compromising the integrity of the trusted domain image. When the system powers on, the trusted domain is loaded and started first. The trusted domain extracts the certificate verification information from its own image's special data segment and verifies whether the currently used public key was indeed issued by a legitimate CA. After successful verification, the trusted domain uses the public key to verify the digital signatures of subsequent images at each level to be loaded. Only after the signature verification passes can execution control be transferred, thus constructing a complete trusted startup chain.

[0047] like Figure 4 As shown, the Certificate Authority (CA) holds the root certificate and the CA's private key. It uses the CA's private key to sign the certificate verification information and links the signed information to a special segment in the Trusted Domain (TDN) image. When the system starts, the certificate verification information in the TDN image is loaded into the TDN's memory space. The TDN uses its built-in root certificate to verify the signature of the certificate verification information, thereby confirming the legitimacy of the public key.

[0048] Once verified, the public key can be used to verify the digital signatures of subsequent boot images at each level. Through this mechanism, the legitimacy of the public key is reliably guaranteed at the source of trusted booting. Any tampering with the public key will compromise the integrity of the trusted domain image or the signature of the certificate verification information, thus being detected by the trusted domain and rejected from booting, ensuring that the root of trust in the entire trusted booting chain is secure and authentic.

[0049] In some embodiments of this application, the specific implementation of linking certificate verification information to the trusted domain image in the form of a special segment is as follows: When compiling the trusted domain image, the certificate verification information is placed in a designated segment of the executable file via a linker script. This segment is marked as a special type in the file format. When the system loads the trusted domain image, the loader identifies this special segment and loads it into a designated address in the trusted domain's memory space. After the trusted domain starts, it retrieves the certificate verification information by reading this address and performs public key validity verification accordingly. This implementation ensures the integrity of the certificate verification information without requiring additional hardware secure storage, reducing the complexity and cost of system implementation.

[0050] Taking an embedded real-time controller in an industrial field as an example, after the device is powered on, the trusted root code runs first, loads and verifies the trusted domain image, and then the trusted domain starts on the bound security kernel to complete the task scheduler initialization and root certificate loading.

[0051] The real-time operating system in the ordinary domain boots on the remaining processor cores. During the boot process, the kernel image and driver images that need to be loaded are submitted to the trusted domain asynchronously for signature verification. After the request is submitted, the processor cores in the ordinary domain can execute other boot processes such as hardware initialization and peripheral driver loading in parallel without waiting for the verification result. The security core, on the other hand, schedules and executes image verification tasks according to priority. After verification is completed, it notifies the ordinary domain, and the ordinary domain loads the corresponding image after confirming that the verification has passed. Compared with the traditional synchronous verification boot method, the asynchronous parallel mode effectively shortens the overall system boot time, and the verification process does not block other initialization tasks in the ordinary domain.

[0052] During normal device operation, real-time control tasks are scheduled and executed on the ordinary domain core at fixed intervals. When the device receives a remote firmware upgrade package, the upgrade management task in the ordinary domain initiates a signature verification request. The request is submitted and immediately returns, and the upgrade management task enters a blocked state. However, the processor core can still schedule the real-time control task to run, and the control cycle will not be affected by firmware verification. The security core performs signature and integrity verification of the upgrade package in the background. Sensitive operations such as key calculations are completed in the security core's dedicated cache. Attackers cannot probe the cache access sequence through the ordinary domain task, ensuring key security. After verification, the security core notifies the ordinary domain, the upgrade management task is awakened, and subsequent upgrade procedures are executed based on the verification results. Throughout the entire process, the operation of the core control task is completely unaffected by security service calls, meeting the deterministic requirements of a hard real-time system.

[0053] If data corruption occurs during the verification process, causing computational anomalies, the security kernel will capture the anomaly and return an error message. Upon receiving the error, the upgrade task in the ordinary domain will indicate upgrade failure and re-download the upgrade package. The real-time control task will continue to run normally, preventing system freezes or control interruptions. Furthermore, because the public key is verified through a certificate system, even if an attacker tampers with the upgrade package and its corresponding public key, they will be unable to pass the certificate verification process and implant malicious firmware into the device, thus ensuring the device's startup and operational security.

[0054] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. It will be apparent to those skilled in the art that the invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the scope of the invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0055] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can be appropriately combined to form other embodiments that can be understood by those skilled in the art. The above content is only for illustrating the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. Any modifications made based on the technical concept proposed in this invention shall fall within the scope of protection of the claims of this invention.

Claims

1. A method for improving the deterministic reliability of system startup, characterized in that, include: Based on an asymmetric multiprocessor core architecture, one processor core is bound to a secure core that runs a trusted domain. The secure core is transparent to the ordinary domain and is shielded when the ordinary domain starts up. The remaining processor cores are configured to run the ordinary domain and can switch between the ordinary domain and the secure domain. A task scheduler is built on the security kernel. The execution priority is divided according to the real-time attributes of each security service. The task scheduler is used to schedule and manage the security service tasks according to the priority. When a task in the ordinary domain requests a security service, the trusted domain responds to the request, migrates the task corresponding to the requested security service to the security core, and returns a request response to the ordinary domain, so that the ordinary domain releases the processor core it occupies, and the task that initiated the request is converted to a blocked state. The task scheduler schedules the security kernel to execute the migrated security service and notifies the ordinary domain after the security service is completed, so that the ordinary domain can process the execution result of the security service.

2. The method for improving the deterministic reliability of system startup according to claim 1, characterized in that, Also includes: During the system power-on startup process, the digital signature of the image to be loaded is verified based on the public key certificate PKI system to verify the legitimacy of the image to be loaded; The certificate verification information is linked to the trusted domain mirror in the form of a special segment. The trusted domain acts as a verification server and verifies the legality of the public key used to verify the digital signature based on the certificate verification information.

3. The method for improving the deterministic reliability of system startup according to claim 2, characterized in that, The trusted domain verifies the legitimacy of the public key used to verify the digital signature based on the certificate verification information, including: After power-on, the trusted domain extracts the certificate verification information from the special segment from the trusted domain image; The trusted domain verifies whether the currently used public key was issued by a certificate authority based on the certificate verification information, and the public key certificate is bound to the public key used to verify the digital signature; After successful verification, the trusted domain uses a public key to verify the digital signature of the subsequent images to be loaded.

4. The method for improving the deterministic reliability of system startup according to claim 2, characterized in that, The certificate verification information is linked to the trusted domain mirror in the form of a special segment, including: The certificate verification information is linked as an independent data segment to the trusted domain image, and the data segment is loaded into the memory space of the trusted domain along with the trusted domain image.

5. The method for improving the deterministic reliability of system startup according to claim 1, characterized in that, The priority-based scheduling and management of security service tasks includes: The security services are scheduled to be executed on the security core in descending order of priority.

6. The method for improving the deterministic reliability of system startup according to claim 5, characterized in that, The process of scheduling the security services in descending order of priority includes: The task scheduler allocates the security service to a task queue with the corresponding priority based on the real-time attribute of the security service; The security core schedules and executes the security services in each of the task queues in descending order of priority.

7. The method for improving the deterministic reliability of system startup according to claim 1, characterized in that, When the security service is executed on the security core, it uses a cache exclusively for the security core. The cached data generated during the execution process is retained in the cache of the security core, and the processor core running the ordinary domain cannot access the cached data.

8. The method for improving the deterministic reliability of system startup according to claim 1, characterized in that, The security kernel is transparent to ordinary domains, including: The ordinary domain communicates with the trusted domain through a specific entry point, and the memory access range of the ordinary domain does not include the memory space of the trusted domain.

9. The method for improving the deterministic reliability of system startup according to claim 1, characterized in that, The trusted domain responds to the request by migrating the task corresponding to the requested security service to the security kernel and returning a request response to the ordinary domain, including: The task in the ordinary domain is trapped in the trusted domain through a specific entry point; After receiving the request, the trusted domain transmits the security service task corresponding to the request and the data corresponding to the task to the task queue of the security core; The trusted domain returns a request response to the ordinary domain, the request response indicating that the request has been received by the trusted domain.

10. An apparatus for improving the deterministic reliability of system startup, characterized in that, Based on an asymmetric multiprocessor core architecture, including: A configuration module is used to bind one processor core as a secure core running a trusted domain. The secure core is transparent to the ordinary domain and is masked when the ordinary domain starts up. The remaining processor cores are configured to run in the ordinary domain and can switch between the ordinary domain and the secure domain. The scheduling module is used to build a task scheduler on the security kernel, divide the corresponding execution priorities according to the real-time attributes of each security service, and manage the security service tasks according to priority through the task scheduler. The request processing module is used to, when a task in the ordinary domain requests a security service, the trusted domain responds to the request, migrates the task corresponding to the requested security service to the security core, and returns a request response to the ordinary domain, so that the ordinary domain releases the processor core it occupies, and the task that initiated the request is converted to a blocked state; The scheduling module is also used to schedule the security core to execute the migrated security service through the task scheduler, and notify the ordinary domain after the security service is executed so that the ordinary domain can process the execution result of the security service.

Images