Software detection method, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a software detection method, electronic equipment and a storage medium, and relates to the field of computers. The software detection method is applied to a first software system in a vehicle, the first software system runs in a first running environment of a processor, a second software system runs in a second running environment of the processor, and the safety level of the first running environment is higher than that of the second running environment. The software detection method comprises the following steps: acquiring detection point operation information sent by a second software system to a first software system; and according to the detection point operation information, determining whether software operation abnormity occurs in the second software system. Wherein the detection point operation information is used for representing the actual operation sequence of the multiple detection points in the second software system according to the time sequence.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technologies, and more particularly, to a software detection method, an electronic device, and a storage medium. Background Art

[0002] With the development of computer technologies, the performance of processors has become increasingly powerful, and the software systems running on processors have also become increasingly complex, posing higher requirements for the secure and reliable operation of software systems. During the operation of a software system, the control flow describes the order of instruction execution in the software. However, in practical applications, due to reasons such as hardware failures, radiation, software defects, and external interferences, the control flow may deviate from the expected situation, such as abnormal jumps, which may further lead to incorrect execution or crashes of software programs and affect the reliability of software systems.

[0003] Therefore, how to perform secure and reliable detection on software systems has become an urgent problem to be solved. Summary of the Invention

[0004] In view of this, embodiments of the present disclosure propose a new technical solution for vehicle software detection.

[0005] According to a first aspect of embodiments of the present disclosure, there is provided a software detection method applied to a first software system that runs in a first operating environment of a processor, and a second software system runs in a second operating environment of the processor, and the security level of the first operating environment is higher than that of the second operating environment; the method includes:

[0006] Obtaining detection point running information sent by the second software system to the first software system; wherein, the detection point running information is used to characterize the actual running order in which multiple detection points in the second software system run in chronological order;

[0007] Determining whether a software running anomaly occurs in the second software system according to the detection point running information.

[0008] Optionally, the detection point running information includes detection identification information of multiple detection points, the multiple detection points include a first detection point and a second detection point that run in chronological order, and the code corresponding to the first detection point is run before the code corresponding to the second detection point; determining whether a software running anomaly occurs in the second software system according to the detection point running information includes:

[0009] Determining whether the actual running order of the first detection point and the second detection point conforms to a set expected running order according to the detection identification information; the expected running order is determined according to detection point registration information sent by the second software system to the first software system during initialization;

[0010] In the case where the actual running order of the first detection point and the second detection point does not conform to the expected running order, it is determined that a software running anomaly occurs in the second software system.

[0011] Optionally, determining whether the actual running order of the first detection point and the second detection point conforms to the set expected running order according to the detection identification information includes:

[0012] Obtaining a set of pre-detection points corresponding to the second detection point according to the detection identification information; wherein, the detection points in the set of pre-detection points are detection points determined based on the detection point registration information that are adjacent to the second detection point and are expected to run before the second detection point;

[0013] In the case where the first detection point belongs to the detection points in the set of pre-detection points, it is determined that the actual running order of the first detection point and the second detection point conforms to the set expected running order; or, in the case where the first detection point does not belong to the detection points in the set of pre-detection points, it is determined that the actual running order of the first detection point and the second detection point does not conform to the set expected running order.

[0014] Optionally, the information transfer between the first running environment and the second running environment is carried out based on a security monitoring call instruction; the obtaining of the detection point running information sent by the second software system to the first software system includes:

[0015] Obtaining the detection point running information sent by the second software system based on the security monitoring call instruction.

[0016] Optionally, the processor is a vehicle processor, the first software system is a vehicle safety monitoring system, and the second software system is an operating system running vehicle autonomous driving software.

[0017] Optionally, the method further includes:

[0018] Obtaining the detection point registration information sent by the second software system; wherein, the detection point registration information includes the detection identification information of the target detection points set in the second software system and the detection identification information of the pre-detection points corresponding to the target detection points, and the target detection points include the first detection point and the second detection point;

[0019] Determining the expected running order of multiple detection points in the second software system according to the detection point registration information; wherein, the expected running order is represented based on the set of pre-detection points corresponding to the target detection points.

[0020] Optionally, the detection identification information includes a function identifier corresponding to a target detection point and a detection point identifier. The function identifier is used to represent the target function where the target detection point is located, and the detection point identifier is used to represent the position or expected execution order of the target detection point within the target function. The same detection point identifier represents different detection points in different target functions. The target detection points include the first detection point and the second detection point.

[0021] Optionally, the detection points set in the second software system include one or more of the following types:

[0022] A first type of detection point set at the head of a function, and the detection point identifier of the first type of detection point is a first preset identifier;

[0023] A second type of detection point set at the tail of a function, and the detection point identifier of the second type of detection point is a second preset identifier;

[0024] A third type of detection point set at other positions except the head and tail of the function. The detection point identifier of the third type of detection point is set to an identifier other than the first preset identifier and the second preset identifier according to the order of the position of the detection point in the function. The detection point identifiers of different third type of detection points in the same function are different; the third type of detection points includes multiple detection points set at the head, tail, and inside of a basic block.

[0025] Optionally, the third type of detection points includes one or more of the following types:

[0026] A fourth type of detection point set before a function call instruction, and the detection point identifier of the fourth type of detection point is a fourth preset identifier;

[0027] A fifth type of detection point set after a function call instruction, and the detection point identifier of the fifth type of detection point is a fifth preset identifier;

[0028] A sixth type of detection point set at other positions except before the function call instruction, after the function call instruction, at the head of the function, and at the tail of the function. The detection point identifier of the sixth type of detection point is set to an identifier other than the first preset identifier, the second preset identifier, the fourth preset identifier, and the fifth preset identifier according to the order of the position of the detection point in the function. The detection point identifiers of different sixth type of detection points in the same function are different.

[0029] According to a second aspect of the embodiments of the present disclosure, a software detection method is provided, which is applied to a second software system. The second software system runs in a second operating environment of a processor, and a first software system runs in a first operating environment of the processor. The security level of the first operating environment is higher than that of the second operating environment. The method includes:

[0030] Sending detection point running information to the first software system, so that the first software system determines whether the second software system has software running anomalies according to the detection point running information; wherein, the detection point running information is used to represent the actual running order of multiple detection points in the second software system running in chronological order.

[0031] According to a third aspect of the embodiments of the present disclosure, an electronic device is provided, including a memory and a processor. The memory is used to store computer instructions. A first software system runs in a first operating environment of the processor, and a second software system runs in a second operating environment of the processor. The security level of the first operating environment is higher than that of the second operating environment;

[0032] The first software system is used to execute the method as described in the first aspect;

[0033] The second software system is used to execute the method as described in the second aspect.

[0034] According to a fourth aspect of the embodiments of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored. The computer program, when executed by a processor, implements the method as described in any one of the first aspect and / or the second aspect.

[0035] Based on the software detection method provided by the embodiments of the present disclosure, the running order of the second software system is detected based on the first software system, which is no longer limited to software detection within the same software system. Moreover, the first software system as the detection party and the second software system as the detected party run in different operating environments of the same processor respectively, thereby enhancing the security and reliability of software detection.

[0036] Through the following detailed description of the exemplary embodiments of the present disclosure with reference to the accompanying drawings, other features and advantages of the present disclosure will become clear. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The drawings incorporated in the specification and constituting a part of the specification illustrate the embodiments of the present disclosure and, together with the description, are used to explain the principles of the present disclosure.

[0038] Figure 1 It is a schematic structural diagram of a processor provided by the embodiments of the present disclosure.

[0039] Figure 2 It is a schematic flowchart of a software detection method provided by an embodiment of the present disclosure.

[0040] Figure 3 It is a schematic flowchart of a software detection method provided by an embodiment of the present disclosure.

[0041] Figure 4 It is a schematic flowchart of a software detection method provided by an embodiment of the present disclosure.

[0042] Figure 5 It is a schematic flowchart of a software detection method provided by an embodiment of the present disclosure.

[0043] Figure 6 It is a schematic structural diagram of an electronic device provided by an embodiment of the present disclosure. Detailed implementation manners

[0044] Now, various exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. It should be noted that: unless otherwise specifically stated, the relative arrangements of components and steps, numerical expressions, and values set forth in these embodiments do not limit the scope of the present disclosure.

[0045] The following description of at least one exemplary embodiment is merely illustrative in nature and in no way serves as a limitation to the present disclosure, its application, or its use.

[0046] Techniques, methods, and devices known to those of ordinary skill in the relevant art may not be discussed in detail, but where appropriate, the above techniques, methods, and devices should be regarded as part of the specification.

[0047] In all the examples shown and discussed here, any specific values should be construed as merely exemplary and not as a limitation. Therefore, other examples of the exemplary embodiments may have different values.

[0048] It should be noted that like reference numerals and letters denote like items in the following figures, and thus, once an item is defined in one figure, it need not be further discussed in subsequent figures.

[0049] It should be noted that actions such as data collection, storage, use, processing, transmission, provision, disclosure, and deletion involved in the present disclosure are all carried out under the premise of complying with relevant data protection regulations and policies of the country or region where the data is located and with the full authorization of the corresponding data owners.

[0050] First, the application scenarios of the embodiments of the present disclosure will be described. During the operation of a software system, the control flow describes the order of instruction execution in the software system. However, in actual applications, due to reasons such as hardware failures, radiation, software defects, and external interference, the control flow may deviate from the expected situation, which may lead to incorrect execution or crashes of software programs, affecting the security and reliability of the software system.

[0051] Taking an autonomous driving vehicle as an example, a complex intelligent driving algorithm software needs to run in the processor of the autonomous driving vehicle (such as an intelligent driving domain controller), and perform functions including perception, decision-making, planning, and control. Once the software system runs abnormally, it will seriously affect the control of the vehicle by the intelligent driving algorithm, reducing the safety and reliability of the autonomous driving vehicle. Therefore, autonomous driving vehicles have higher requirements for software security. For example, for the functional safety standard ISO26262 for automotive electronics, the ASIL level (Automotive Safety Integration Level) is proposed. There are four ASIL levels, namely A, B, C, and D, where A is the lowest level and D is the highest level. The higher the ASIL level, the higher the security requirements for the system. For autonomous driving vehicles, their software systems need to meet at least the safety requirements above ASIL B, and it is necessary to ensure that the software system can still maintain safety functions under foreseeable fault conditions. For some open-source software systems, such as Linux, as an open-source general operating system, although it has a rich ecosystem and powerful computing capabilities, there are great challenges in functional safety certification. It needs to go through a large number of customizations and security enhancements to approach the requirements of ASIL B. Currently, there are no cases in the industry where Linux has passed the functional safety certification. In order to improve the security of the software system and meet the safety requirements of ASIL, it is necessary to detect whether the control flow of the software system deviates from the expected situation.

[0052] In the related art, control flow detection can be performed based on hardware or software methods. Among them, the hardware-based detection method requires adding additional hardware (such as a watchdog) to detect abnormal behaviors such as illegal jumps or infinite loops in the program. If the update signal of the watchdog is not triggered within a predetermined time, the watchdog will consider that the program has an abnormality and will take reset or pre-set processing measures for the system. However, the hardware-based detection method requires changes to the circuit or even the chip architecture, with high costs and lack of generality.

[0053] The software-based detection method can set detection points at key positions in the software program, such as at the entrances and exits of basic blocks in the program, and check whether the control flow meets the expectations through the detection points during program operation. However, since this method involves the software program detecting itself, for example, in the same software stack, using one program to detect another program, it is equivalent to self-supervision, which not only increases the code complexity but also reduces the detection reliability, making it difficult to meet the safety requirements of ASIL. Therefore, how to perform safe and reliable detection on software systems has become an urgent problem to be solved.

[0054] Figure 1 It is a schematic structural diagram of a processor provided by an embodiment of the present disclosure. As Figure 1 shown, a first software system 101 and a second software system 102 can be deployed on the processor 100, and the two software systems can run independently.

[0055] It should be noted that the processor 100 can be various processors in vehicles, robots, or other electronic devices. For example, it can be a Central Processing Unit (CPU), a Graphic Process Unit (GPU), a Neural-network Processing Unit (NPU), a Tensor Processing Unit (TPU), a Data Processing Unit (DPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a System on Chip (SOC), an Application Specific Integrated Circuit (ASIC), a Micro Controller Unit (MCU), or other processors.

[0056] In some examples, the processor 100 may be disposed in a vehicle with an autonomous driving function. For example, it may be an intelligent driving domain controller in the vehicle, and the processor may be used to implement computing tasks or control tasks related to autonomous driving. Among them, autonomous driving is also known as driverless or intelligent driving. A vehicle with an autonomous driving function can perform driving tasks such as environmental perception, decision-making and planning, and control execution. The levels of autonomous driving can refer to the automotive intelligence grading standard formulated by the Society of Automotive Engineers (SAE). For example, the L0 level is manual driving, L1 is assisted driving, L2 is partial autonomous driving, L3 is conditional autonomous driving, L4 is highly autonomous driving, and L5 is fully autonomous driving. The above classification methods for the levels of autonomous driving are only for illustration, and the embodiments of the present disclosure do not limit the classification criteria and levels of autonomous driving.

[0057] In some examples, the above-mentioned first software system and second software system may run in different operating environments within the same processor. For example, the first software system may run in the first operating environment of the processor, and the second software system may run in the second operating environment of the processor.

[0058] The security level of the first operating environment may be higher than that of the second operating environment. The security level may refer to the system or in the processor architecture. The security level can be achieved through hardware mechanisms (such as privilege levels, security extensions) and software mechanisms (such as isolation of the operating system kernel) to achieve the security guarantee ability of the operating environment, such as data protection, fault isolation, and prevention of malicious attacks. For example, the operating environment of the processor may include a Secure World and a Normal World (also known as a common world). The above-mentioned first operating environment may be the operating environment of the Secure World; the above-mentioned second operating environment may be the operating environment of the Normal World.

[0059] Taking this processor as an example of a processor based on the ARM (Advanced RISC Machine) architecture, in CPUs or SOCs with the ARMV8 and higher architecture versions, the concept of Exception Levels (EL) is introduced, and the software execution permissions are divided into four exception levels: EL0, EL1, EL2, and EL3. Each exception level can be further divided into two parts: the Secure World and the Non-Secure World. The Secure World can be a protected operating environment for running code and data with extremely high security requirements. The isolation of the Secure World can be directly supported by hardware, so it can provide higher security than software-level security; the Non-Secure World can be a conventional operating environment for running most user programs and operating systems. Through this design, hardware-level security isolation can be achieved to improve the security of the entire processor. Among them:

[0060] EL3 is the highest exception level and can be in the Secure World. EL3 can achieve the switching between the Secure World and the Non-Secure World, so it is also called the Secure Monitor. Through the EL3 system, it is possible to switch from the Non-Secure World to the Secure World.

[0061] EL2 can be used for virtualization support, such as running a Hypervisor. EL2 can support either the Secure World or the Non-Secure World.

[0062] The two exception levels EL1 and EL0 can run either in the Secure World or in the Non-Secure World. EL1 is usually used for the operating system kernel, while EL0 is usually used for user programs.

[0063] Taking a processor with an ARM architecture as an example, the above-mentioned first operating environment may be the operating environment of the secure world, such as the secure world operating environment of EL3; the above-mentioned second operating environment may be the operating environment of the non-secure world, such as the non-secure world operating environment of EL1. The above-mentioned first software system may be a security monitoring system running in EL3 of the processor, and the second software system runs the operating system in EL1 of the processor, such as the kernel of the Linux operating system. It should be noted that the embodiments of the present disclosure may not rely on a specific hardware platform and can be used in the processor architectures in the related art. The above-mentioned ARMV8 is only an example, and other architectures may also be used. For example, a hypervisor (virtual machine monitor) can be used as the first software system to act as the detector, and the operating system in the guest (virtual machine) can be used as the second software system to act as the detected object. When the software stack in the guest runs to the detection point, it will trap into the hypervisor for inspection. In this way, no matter whether the processor is ARM, X86, MIPS, or RISC-V, the method in the embodiments of the present disclosure can be adopted.

[0064] Furthermore, the information transfer between the above-mentioned first operating environment and the second operating environment can be based on a secure monitor call instruction to achieve secure isolation. Among them, the secure monitor call (SMC) instruction can be an interface instruction for the second operating environment to request services from the first operating environment. For example, it can request services from the secure world from the non-secure world.

[0065] In some examples, the above-mentioned processor may be a vehicle processor, the above-mentioned first software system may be a vehicle security monitoring system, and the second software system may be an operating system running vehicle autonomous driving software (such as the Linux operating system). In this way, through the software detection method provided by the embodiments of the present disclosure, the security and reliability of the autonomous driving software can be improved, so that the autonomous driving software of the vehicle meets the safety requirements of vehicle regulations (such as ASIL B).

[0066] In some embodiments of the present disclosure, the program control flow of the second software system can be detected based on the first software system, thereby enhancing the reliability of software program control flow detection and also improving the reliability of autonomous driving. Continuing as Figure 1 shown, in the target functions to be detected in the second software system (such as target function 1 and target function 2), there are multiple program segments 1023, and detection points (CheckPoint, abbreviated as CP) can be inserted between the program segments, as Figure 1 shown by the detection point request module 1022. Optionally, the detection points can be inserted at any position in the function, not limited to basic blocks.

[0067] The information of the detection points set in the second software system and the functions where they are located can be registered by the detection point registration module 1021 in the first software system. For example, the detection point registration information can be sent to the first software system through the security monitoring call interface 1024, so as to send the information related to the detection points set in the second software system to the first software system. The detection point initialization module 1015 in the first software system can receive and record this detection point registration information.

[0068] When the second software system program runs to a certain detection point, the detection point request module 1022 can send the detection identification information of this detection point (such as function identification and detection point identification) to the first software system through the security monitoring call interface 1024. For example, it can be sent to the detection point detection module 1016 in the first software system. This detection point detection module can determine whether the instruction execution order of the second software system conforms to the set expected execution order according to the received detection identification information. For example, it judges whether its current previous detection point is in the set of previous detection points of this detection point. If the current previous detection point is not included in the set of previous detection points, it can be determined that the instruction execution order of the second software system does not conform to the set expected execution order, and record the software operation exception information. Optionally, the first software system may further include an exception reporting module 1017, which can report this software operation exception information to the control center.

[0069] The above first software system can be a program stack during runtime, running in the secure world, such as running in the EL3 secure world. The CP detection module of the first software system can be used to judge whether a program control flow error has occurred in the CP reported by the second software system. If no program control flow error has occurred, the first software system can not process it, and the second software system also continues to run normally; if a program control flow error has occurred (such as the program execution order does not meet the expectation), the first software system can record the software operation exception information, and can also report the software operation exception information, and the subsequent operations are determined by a higher execution policy. For example, this processor (such as ARM) can report the software operation exception information to other processors (such as MCU), and other processors decide whether to perform exception handling. For example, it can be restarted, or continue to run as it is.

[0070] Figure 2 It is a schematic flowchart of a software detection method provided by an embodiment of the present disclosure. This method can be executed by Figure 1 the first software system and the second software system in the processor shown as Figure 2 shown, and as shown, this method may include the following steps S210 to step S240.

[0071] Step S210, the second software system sends detection point registration information to the first software system.

[0072] Among them, the checkpoint registration information can be used to indicate the expected running order of multiple checkpoints in the second software system.

[0073] In some examples, the above checkpoint registration information may include the detection identification information of the target checkpoint set in the second software system, and may also include the detection identification information of the pre-checkpoint corresponding to the target checkpoint. The pre-checkpoint may be a checkpoint adjacent to the target checkpoint and expected to run before the target checkpoint. The target checkpoint included in the checkpoint registration information may be one or more checkpoints, and the pre-checkpoint corresponding to each target checkpoint may also be one or more. Different target checkpoints may have different corresponding pre-checkpoints. It should be noted that if multiple checkpoints are set in the second software system, multiple checkpoints can be sent at one time, or one checkpoint can be sent at a time and sent in multiple times.

[0074] Step S220, the first software system determines the expected running order of multiple checkpoints in the second software system according to the checkpoint registration information.

[0075] Exemplarily, the first software system can obtain the checkpoint registration information sent by the second software system and determine the expected running order of multiple checkpoints in the second software system according to the checkpoint registration information.

[0076] In some examples, the expected running order can be represented based on the set of pre-checkpoints corresponding to each checkpoint. The first software system can determine the target checkpoints in the second software system and the set of pre-checkpoints corresponding to each target checkpoint according to the checkpoint registration information. The checkpoints in the set of pre-checkpoints corresponding to the target checkpoint are the checkpoints determined based on the checkpoint registration information that are adjacent to the target checkpoint and expected to run before the target checkpoint. The target checkpoint and the corresponding set of pre-checkpoints can be used to detect whether the instruction running order of the second software system conforms to the set expected running order. If it does not conform to the set expected running order, it can be determined that the instruction running order of the second software system is abnormal.

[0077] In some examples, the second software system may send checkpoint registration information to the first software system based on a security monitoring call instruction, and the first software system may also obtain the checkpoint registration information based on the security monitoring call instruction. For example, the second software system may call the SMC API (Secure Monitor Call Application Programming Interface) to send the checkpoint registration information to the first software system. The SMC API may be an interface function encapsulated with the SMC instruction as the core to facilitate the call by the second software system. In this way, the information transfer based on the security monitoring call instruction can improve the efficiency and reliability of the information transfer between the two software systems.

[0078] In some examples, the second software system may execute step S210 during initialization. For example, after the processor is powered on or restarted, the initialization steps of the second software system are executed, and step S210 is executed. In this way, the registration step only needs to be executed once during initialization, and there is no need to register again during the subsequent normal operation of the second software system.

[0079] In other examples, in addition to executing step S210 during initialization, the second software system may also execute step S210 when the duration since the previous registration is greater than a preset re-registration period duration and the load of the processor is less than a preset load threshold. The preset re-registration period duration may be any preset duration, such as 20 minutes, 1 hour, or 5 hours, and the preset load threshold may also be any load less than 90% preset in advance, such as 20%, 50%, or 60%. In this way, the second software system can perform checkpoint registration periodically to improve the reliability of checkpoint registration.

[0080] The above checkpoint registration information may include the detection identification information of the target checkpoint set in the second software system and the detection identification information of the pre-checkpoint corresponding to the target checkpoint.

[0081] A checkpoint (CheckPoint, abbreviated as CP) can be used to verify whether the running order of a software program conforms to expectations, so as to detect control flow errors in the software system. The setting of checkpoints in a software system can usually be based on the control flow graph of the software program. The program is divided into multiple basic blocks, and detection code is inserted at the entrance or exit of the basic block. Setting a checkpoint at the entrance of the basic block can be used to verify whether the program correctly enters a certain basic block. Setting a checkpoint at the exit of the basic block can be used to verify whether the program has completely executed a certain basic block and correctly jumps to the next basic block. For example, the above-mentioned target checkpoints may include checkpoint 1 and checkpoint 2 that are expected to run in chronological order. The code corresponding to checkpoint 1 is expected to be run before the code corresponding to checkpoint 2. If the program does not run in the above-mentioned expected order during actual operation, for example, checkpoint 2 runs before checkpoint 1, it can be determined that there is an abnormality in the software running order.

[0082] In some examples, the detection identification information of the above-mentioned target checkpoints can be used to determine the target function where the target checkpoint is located and its internal position or expected running order in the target function. Exemplarily, the detection identification information may include a function identifier corresponding to the target checkpoint and a checkpoint identifier. The function identifier can be used to represent the target function where the target checkpoint is located, and the checkpoint identifier can be used to represent the position or expected running order of the target checkpoint inside the target function. The same checkpoint identifier can represent different checkpoints in different target functions. The target checkpoints include a first checkpoint and a second checkpoint.

[0083] In one implementation, checkpoints can be set on a function-by-function basis. The checkpoints set in the above-mentioned second software system can be divided into multiple types according to the set positions. For example, it may include one or more of the following first type of checkpoints to the third type of checkpoints:

[0084] The first type of checkpoint set at the head of the function, the checkpoint identifier of the first type of checkpoint is the first preset identifier, and the first preset identifier can be any value set in advance, such as 0x00 or 0x80. This first preset flag can be called CP0. In this way, the checkpoint identifier inserted at the head of the target function is fixed as the first preset identifier (CP0), so as to identify that this is the beginning of the target function.

[0085] A second type of checkpoint is set at the end of the function. The checkpoint identifier of this second type of checkpoint is a second preset identifier, and the second preset identifier can be any value set in advance, such as 0xFF. This second preset flag can be called CP_Exit. In this way, the checkpoint identifier inserted at the end of the target function is fixed as the second preset identifier (CP_Exit), so as to indicate that this is the end of the target function, indicating that the function execution is completed. The end of the function can be the return statement in the function, and this second type of checkpoint can be added before the return statement. The second preset identifier is different from the first preset identifier to distinguish the types of checkpoints, that is, to distinguish whether the checkpoint is set at the head or the end of the function.

[0086] A third type of checkpoint is set at other positions except the head and the end of the function. The checkpoint identifier of this third type of checkpoint can be set as other identifiers except the first preset identifier and the second preset identifier according to the order of the position of the checkpoint in the function. The checkpoint identifiers of different third type of checkpoints in the same function are different. Exemplarily, the checkpoint identifiers of each checkpoint can be set by sequentially increasing a preset step length starting from a third preset identifier according to the position order of the checkpoint in the function. The third preset identifier can be any value set in advance, such as 1 or 0x81. Optionally, the third preset identifier can be equal to the value obtained by adding 1 to the first preset identifier. In this way, the checkpoint identifier of this third type of checkpoint is the checkpoint identifier inside the target function, which can be represented by an internal variable of the target function and only acts on the current target function to be detected, ensuring that the checkpoint identifier (CPn) of each third type of checkpoint is unique within the current target function to be detected. Different target functions can reuse the checkpoint identifier CPn, for example, the checkpoint identifier 0x81 can exist in both functions. In this way, the demand for checkpoint identifiers is reduced, and the checkpoint identifier can be represented based on integer values. Compared with the related art that needs to calculate hash values, the implementation method of this embodiment can significantly reduce the amount of computation, reduce the load of the processor, and thus improve the software detection efficiency.

[0087] Optionally, the position where the third type of checkpoint appears inside the target function is not restricted. For example, the third type of checkpoint can include multiple checkpoints set at the head, the end, and inside the basic block. For example, one or more third type of checkpoints can be set inside the basic block, and the inside of the basic block can be other positions except the head and the end of the basic block.

[0088] The checkpoint identifier of the above-mentioned third type of checkpoint only takes effect inside one function, and different functions can reuse this checkpoint identifier. For example, the checkpoint identifier 0x81 can exist in both functions. In this way, the demand for checkpoint identifiers is reduced, and the checkpoint identifier can be represented based on integer values. Compared with the related art that needs to calculate hash values, the implementation method of this embodiment can significantly reduce the amount of computation, reduce the load of the processor, and thus improve the software detection efficiency.

[0089] Furthermore, the first preset identifiers of the first type of detection points corresponding to different objective functions can be the same. For example, they are all 0x80. The second preset identifiers of the second type of detection points corresponding to different objective functions can also be the same. For example, they are all 0xFF. In this way, the complexity of detection and judgment can be further reduced, and the software detection efficiency can be improved.

[0090] It should be noted that the detection points set in the second software system described above can include one or more of the first to third types of detection points. For example, there can be only the first type of detection point and the second type of detection point, only the first type of detection point and the third type of detection point, or the first type of detection point, the second type of detection point, and the third type of detection point.

[0091] In one implementation, the detection points set in each objective function of the second software system can at least include the first type of detection point and the second type of detection point. In this way, when the first software system receives the second type of detection point, it can apply for the memory resources corresponding to this objective function to store the detection identification information of the detection points of this objective function; when the first software system receives the second type of detection point, it can release the memory resources corresponding to this objective function. In this way, dynamic management of memory resources can be achieved, and the utilization efficiency of memory resources can be improved.

[0092] The number of pre-detection points included in the set of pre-detection points of each target detection point can be one or more, or can be zero (that is, there are no pre-detection points). For example, the above-mentioned first type of detection point is the detection point at the head of the function. Therefore, the set of pre-detection points of this first type of detection point can be an empty set, that is, for the detection point at the head of the function, it is not necessary to detect its running order, but only to detect the running order of other detection points outside the head. For another example, the pre-detection points of the above-mentioned third type of detection point can include the first type of detection point, or can also include other third type of detection points.

[0093] In one implementation, this third type of detection point can be not distinguished, and all detection points inside the function are the third type of detection points.

[0094] In another implementation, this third type of detection point can be further distinguished. For example, it can include one or more of the following fourth to sixth types of detection points:

[0095] The fourth type of detection point set before the function call instruction, the detection point identifier of this fourth type of detection point is the fourth preset identifier, and this fourth preset identifier can be any value set in advance. Optionally, this fourth preset identifier can be a global variable in the second software system, that is, the globally unique identifier FCPm in the second software system.

[0096] The fifth type of checkpoint is set after the function call instruction. The checkpoint identifier of this fifth type of checkpoint is the fifth preset identifier, and the fifth preset identifier can be any value set in advance. Optionally, the fifth preset identifier can be a global variable in the second software system, that is, the globally unique identifier FCPm in the second software system. The fifth preset identifier can be different from the fourth preset identifier.

[0097] The sixth type of checkpoint is set at a position other than before the function call instruction, after the function call instruction, at the function head, and at the function tail. The checkpoint identifier of this sixth type of checkpoint can be set to an identifier other than the first preset identifier, the second preset identifier, the fourth preset identifier, and the fifth preset identifier according to the order of the position of the checkpoint in the function. The checkpoint identifiers of different sixth type of checkpoints in the same function are different.

[0098] In an alternative implementation, if the checkpoint types in the second software system include the above first, second, fourth, fifth, and sixth type of checkpoints, the pre-checkpoint set of the above first type of checkpoint may include the fourth preset identifier and / or the second preset identifier, that is, the pre-checkpoint of the function head checkpoint can be the fourth type of checkpoint before the function call instruction or the second type of checkpoint at the end of other functions. In this way, it is possible to qualitatively determine that the checkpoint before the program runs at the function head is the function call instruction or the end of other functions. Although the precise call relationship cannot be detected, most of the abnormal program running orders can still be detected based on this simplified detection scheme, so that the detection of the running order between functions can be simply and efficiently realized.

[0099] In an alternative implementation, the pre-checkpoint set corresponding to the above fifth type of checkpoint may include the second preset identifier, that is, for the fifth type of checkpoint set after the function call instruction, its pre-checkpoint can be the end of a certain function. In this way, it is possible to qualitatively determine that before the program runs after a function call and the like is the end of a certain function. Although the precise call relationship cannot be detected, most of the abnormal program running orders can still be detected based on this simplified detection scheme.

[0100] In some examples, the fourth preset identifiers of the fourth type of checkpoints corresponding to different target functions may be different, and the fifth preset identifiers of the fifth type of checkpoints corresponding to different target functions may also be different. For example, each fourth preset identifier and fifth preset identifier can be a globally unique identifier in the second software system. In this way, the call relationship of the function can be uniquely determined, and the precise detection of the function call relationship can be realized.

[0101] In some other examples, the fourth preset identifiers of the fourth type of detection points corresponding to different objective functions can be the same. For example, they are all 0xFE. The fifth preset identifiers of the fifth type of detection points corresponding to different objective functions can also be the same. For example, they are all 0xFD. In this way, the detection of function calls can be simplified to a certain extent, the complexity of detection and judgment can be reduced, and the software detection efficiency can be improved.

[0102] In some examples, different types of detection points can adopt the same registration method. For example, a unified registration function can be used to register the target detection points into the first software system.

[0103] In some other examples, the registration methods of different types of detection points can be different.

[0104] For example, the second software system can implement the registration of the first type of detection points through the function func_x_cp_register(CP0,N). Its meaning is that the number of detection points N inserted in the function func_x is registered into the first software system. That is, if the target detection point is the first type of detection point at the head of the function, the detection point registration information can include the detection identification information of the target detection point and the number of detection points set in the target function. The detection identification information can include the detection point identifier of the target detection point and the function identifier of the target function where the target detection point is located.

[0105] The function identifier of the target function, the detection point identifier, and the number of detection points set in the target function. After receiving the detection point registration information, if the target detection point in it is the first type of detection point (i.e., CP0), it indicates that the target detection point is the beginning part of the target function to be detected. At this time, N memory resources corresponding to N detection points can be allocated in the first software system according to the number of detection points N carried in the detection point registration information

[0106] For another example, the registration of other types of detection points except the first type of detection points can be implemented through the function func_x_cp_register(CPn,PRE(CPn)). Its meaning is that the set of pre-detection points of CPn in the function func_x is PRE(CPn), and this relationship is registered into the first software system. That is, if the target detection point is other types of detection points except the first type of detection points, the detection point registration information can include the detection identification information of the target detection point and the set of pre-detection points corresponding to the target detection point. The set of pre-detection points can include the detection identification information of the pre-detection points. Among them, the detection identification information of the target detection point can include the detection point identifier of the target detection point and the function identifier of the target function where the target detection point is located.

[0107] After the first software system receives the checkpoint registration information, if the target checkpoint among them is not a first-type checkpoint, it indicates that the target checkpoint is not the starting part of the target function to be detected. The checkpoint registration information carries relevant information such as the detection identification information of the previous checkpoint. At this time, the detection identification information of the previous checkpoint carried in the checkpoint registration information can be written into the checkpoint data structure with the target checkpoint as the core. The checkpoint data structure can be in the form of a linked list, an array, or a tree structure, etc. The first software system can determine the detection identification information of any checkpoint and the set of previous checkpoints corresponding to this checkpoint through this checkpoint data structure. The checkpoints in the set of previous checkpoints are the checkpoints determined based on the checkpoint registration information that are adjacent to the second checkpoint and are expected to run before the second checkpoint.

[0108] In some examples, the information related to the target checkpoint to be registered, that is, the detection identification information of the target checkpoint set in the second software system and the detection identification information of the previous checkpoint corresponding to the target checkpoint, can be written into the second software system in the form of code. The information of the target checkpoint can be collected by the user, or alternatively, it can be automatically scanned by a code scanning tool. The code scanning tool can parse the code based on a natural language model to obtain the information related to the checkpoint.

[0109] Step S230, the second software system sends checkpoint operation information to the first software system.

[0110] Among them, the checkpoint operation information can be used to represent the actual operation order in which multiple checkpoints in the second software system run in chronological order. The checkpoint operation information can also be referred to as checkpoint request information.

[0111] In some examples, the multiple checkpoints can be the checkpoints that the second software system has already registered with the first software system. For example, they can be the checkpoints among the target checkpoints that have been registered based on steps S210 and S220.

[0112] Step S240, the first software system determines whether the second software system has a software operation anomaly according to the checkpoint operation information.

[0113] Exemplarily, the first software system can obtain the checkpoint operation information sent by the second software system to the first software system and determine whether the second software system has a software operation anomaly according to the checkpoint operation information.

[0114] In some examples, the second software system may send checkpoint registration information to the first software system during initialization, and during the software operation after initialization, send checkpoint operation information to the first software system according to the software operation sequence of the second software system. In this way, the first software system can determine the expected operation sequence of multiple checkpoints of the second software system according to the checkpoint registration information, and determine the actual operation sequence of multiple checkpoints of the second software system according to the checkpoint operation information.

[0115] The actual operation sequence of multiple checkpoints in the second software system may or may not conform to the expected operation sequence. For example, when the control flow deviates from the expectation due to reasons such as hardware failure, radiation, software defect, external interference, etc., the phenomenon that the actual operation sequence of multiple checkpoints does not conform to the expected operation sequence will occur. If the actual operation sequence does not conform to the expected operation sequence, for example, it is different from all the expected sequences given by the expected operation sequence, it can be determined that the second software system has a software operation anomaly; if the actual operation sequence conforms to the expected operation sequence, it can be determined that the software operation is normal.

[0116] Exemplarily, a total of five checkpoints A, B, C, D, and E are set in a certain target function of the second software system, where A is the first type of checkpoint set at the head of the function, and E is the second type of checkpoint set at the tail of the function. The expected operation sequence of each checkpoint is that A runs first, and then B and C are in a selection operation relationship. For example, B runs when the first condition is met, and C runs when the first condition is not met. After B or C runs, D and E are run in sequence. In this way, without considering other checkpoints in the second software system, the set of pre-checkpoints corresponding to A can be empty, the set of pre-checkpoints corresponding to B and C includes A, the set of pre-checkpoints corresponding to D includes B and C, and the set of pre-checkpoints corresponding to E includes D. If during the operation of the second software system, the actual operation sequence of each checkpoint is A->B->D->E, then the actual operation sequence of each checkpoint conforms to the expected operation sequence; if the actual operation sequence of each checkpoint is A->D->E, and checkpoint D runs directly after checkpoint A runs, since A does not belong to the checkpoints in the set of pre-checkpoints of D, it can be determined that the actual operation sequence of checkpoint A and checkpoint D does not conform to the set expected operation sequence, that is, it can be determined that the software operation is abnormal.

[0117] In this way, the detection of the operation sequence of the second software system by the first software system is no longer limited to software detection within the same software system, and the first software system as the detection party and the second software system as the detected party run in different operating environments of the same processor respectively, thereby enhancing the security and reliability of software detection.

[0118] In some embodiments of the present disclosure, the above detection point operation information may include detection identification information of multiple detection points. The multiple detection points may include a first detection point and a second detection point that are run successively in chronological order, and the code corresponding to the first detection point is run before the code corresponding to the second detection point. By way of example, the second software system may first send the detection identification information of the first detection point, then send the detection identification information of the second detection point, and no other detection points are sent between the first detection point and the second detection point. An alternative implementation of the above step S240 may include: determining whether the actual operation order of the first detection point and the second detection point conforms to the set expected operation order according to the detection identification information; in the case where the actual operation order of the first detection point and the second detection point does not conform to the expected operation order, determining that the second software system has a software operation abnormality. Among them, the expected operation order may be determined according to the detection point registration information sent by the second software system to the first software system during initialization.

[0119] In some examples, the expected operation order may be represented based on the set of pre-detection points corresponding to each detection point. By way of example, according to the detection identification information, the set of pre-detection points corresponding to the second detection point can be obtained. The detection points in the set of pre-detection points may be detection points that are adjacent to the second detection point and expected to be run before the second detection point, determined based on the detection point registration information. By way of example, the second software system may determine the set of pre-detection points corresponding to the second detection point according to the detection point data structure recorded during the detection point registration process.

[0120] In the case where the first detection point belongs to the detection points within the set of pre-detection points, it can be determined that the actual operation order of the first detection point and the second detection point conforms to the set expected operation order; or, in the case where the first detection point does not belong to the detection points within the set of pre-detection points, it can be determined that the actual operation order of the first detection point and the second detection point does not conform to the set expected operation order.

[0121] Whether the first detection point belongs to the detection points within the set of pre-detection points can be determined based on the detection identification information. By way of example, the second software system may send the detection identification information of the detection point to the first software system through the detection point operation information. The detection identification information may include the function identification corresponding to the detection point and the detection point identification. Optionally, the detection identification information of one detection point may be included in each detection point operation information. The detection identification information of multiple detection points can be sent through multiple detection point operation information, and the sending order may represent the operation order of the code corresponding to the detection point.

[0122] In some examples, the first software system may obtain the checkpoint operation information sent by the second software system. This checkpoint operation information can be used to characterize the actual operation order in which multiple checkpoints in the second software system are run in chronological order. For example, the checkpoint operation information may include the detection identification information of multiple checkpoints. The multiple checkpoints may include a first checkpoint and a second checkpoint that are run in chronological order, and the code corresponding to the first checkpoint may be run before the code corresponding to the second checkpoint.

[0123] In some examples, the second software system may send the checkpoint operation information to the first software system based on a security monitoring call instruction, and the first software system may also obtain the checkpoint operation information based on the security monitoring call instruction.

[0124] In some instances, when the first software system determines that a software operation exception occurs in the second software system, it may record the software operation exception information. Optionally, this software operation exception information can be used to characterize that the instruction operation order of the second software system does not conform to the set expected operation order.

[0125] In some examples, the first software system receives the checkpoint request information sent by the second software system and parses out the detection identification information of the second checkpoint. This detection identification information includes a checkpoint identifier and a function identifier. Since the first software system may include the detection identification information of the previous checkpoint (such as the first checkpoint) when the program segment where the second checkpoint is located runs. Further, when registering the checkpoint, the first software system initializes the set of pre-checkpoints corresponding to the second checkpoint. The set of pre-checkpoints includes the checkpoint identifiers of all legal pre-checkpoints of the second checkpoint. At this time, it can be checked whether the first checkpoint exists in the set of pre-checkpoints. If the first checkpoint is not included in the set of pre-checkpoints, it means that the instruction operation order of the second software system does not conform to the set expected operation order, that is, an illegal control flow occurs. At this time, the software operation exception information can be recorded. For example, the software operation exception information can be recorded in a log or an alarm message for the administrator of the second software system to query.

[0126] In some examples, the software operation exception information can also be reported to a control center, and the control center can be located in another security domain, such as an external server or another processor such as an MCU.

[0127] In this way, the operation exception of the second software system can be discovered in time, improving the real-time performance of software detection and the reliability of software system operation.

[0128] In an alternative implementation, when the second software system sends the detection identification information of the checkpoint to the first software system according to the software running order, it can also send the thread identification corresponding to the detection identification information. For example, the thread identification can be sent through the checkpoint request information. In a multi-thread scenario, the first software system can check the running order of the checkpoints according to different thread identifications respectively to prevent conflicts caused by multiple threads calling the same function simultaneously.

[0129] Exemplarily, in the case where the above first checkpoint and second checkpoint correspond to the same thread identification, the first software system executes step S240 to determine whether the first checkpoint is included in the set of pre-checkpoints for the second detection; conversely, in the case where the above first checkpoint and second checkpoint correspond to different thread identifications, the first software system can store the corresponding checkpoint information, but there is no need to determine whether the first checkpoint is included in the set of pre-checkpoints for the second detection, that is, only the checkpoints belonging to the same thread identification are detected for the running order.

[0130] In this way, the detection of the software running order can also be realized in a multi-thread scenario, improving the reliability of software detection. It should be noted that the thread identification can be dynamically generated with the creation of the thread, and the thread identification may not need to be included in the checkpoint registration information.

[0131] It should be noted that the method involved in the embodiments of the present disclosure may include one or more of the above steps S210 to S240. For example, steps S230 and S240 can be implemented as independent embodiments, steps S210 and S220 can be implemented as independent embodiments, steps S210 and step S230 can be implemented as independent embodiments, but not limited thereto. Further, the above steps S210 to S240 can be executed in a swapped order or simultaneously.

[0132] Figure 3 is a flowchart of a software detection method provided by an embodiment of the present disclosure. This method can be executed by Figure 1 the first software system in the processor shown as Figure 3 shown. This method may include the following steps S310 to step S320.

[0133]

[0134] Step S310, obtain the checkpoint running information sent by the second software system to the first software system.

[0134] Among them, the first software system and the second software system can run in different operating environments within the same processor respectively. For example, the first software system runs in the first operating environment of the processor, and the second software system runs in the second operating environment of the processor. The security level of the first operating environment is higher than that of the second operating environment.

[0135] In some examples, the checkpoint running information can be used to characterize the actual running order in which multiple checkpoints in the second software system run successively in chronological order. By way of example, the checkpoint running information includes the detection identification information of multiple checkpoints. The multiple checkpoints may include a first checkpoint and a second checkpoint that run successively in chronological order, and the code corresponding to the first checkpoint is run before the code corresponding to the second checkpoint.

[0136] In some examples, the detection identification information includes a function identifier and a checkpoint identifier corresponding to a target checkpoint. The function identifier can be used to characterize the target function where the target checkpoint is located, and the checkpoint identifier can be used to characterize the position or expected running order of the target checkpoint within the target function. The same checkpoint identifier represents different checkpoints in different target functions. The target checkpoints include the first checkpoint and the second checkpoint.

[0137] In some examples, the first software system can obtain the detection identification information sent by the second software system based on a security monitoring call instruction.

[0138] For the optional implementation of step S310, reference can be made to [[ID=!16]]Figure 2 the optional implementation of step S230 in Figure 2 and other related parts in the embodiments involved. Details are not elaborated here.

[0139] Step S320: Determine whether a software running anomaly occurs in the second software system according to the checkpoint running information.

[0140] For the optional implementation of step S320, reference can be made to Figure 2 the optional implementation of step S240 in Figure 2 and other related parts in the embodiments involved. Details are not elaborated here.

[0141] By adopting the above method, the running order of the second software system is detected based on the first software system, which is no longer limited to software detection within the same software system. Moreover, the first software system as the detector and the second software system as the detected system run in different running environments within the same processor, thereby enhancing the security and reliability of software detection.

[0142] In some examples, the first software system may obtain the checkpoint registration information sent by the second software system; determine the expected running order of multiple checkpoints in the second software system according to the checkpoint registration information, and the expected running order may be based on the set of prerequisite checkpoints corresponding to the target checkpoint. Exemplarily, the checkpoint registration information may include the detection identification information of the target checkpoint set in the second software system and the detection identification information of the prerequisite checkpoints corresponding to the target checkpoint. The target checkpoint may include multiple checkpoints, such as a first checkpoint and a second checkpoint that run successively in chronological order.

[0143] Figure 4 is a schematic flowchart of a software detection method provided by an embodiment of the present disclosure. This method may be executed by the second software system in the Figure 1 shown processor, as Figure 4 shown, this method may include the following step S410.

[0144] Step S410, the second software system sends checkpoint running information to the first software system.

[0145] Among them, the checkpoint running information may be used to characterize the actual running order of multiple checkpoints in the second software system running successively in chronological order. The first software system may determine whether the second software system has a software running anomaly according to the checkpoint running information.

[0146] In some instances, multiple checkpoints may be preset in the second software system, and each checkpoint may correspond to different detection identification information. The detection identification information includes the function identification corresponding to the target checkpoint and the checkpoint identification. The function identification may be used to characterize the target function where the target checkpoint is located, and the checkpoint identification may be used to characterize the position or expected running order of the target checkpoint inside the target function. The same checkpoint identification represents different checkpoints in different target functions. The target checkpoint may include a first checkpoint and a second checkpoint that run successively in chronological order.

[0147] In some instances, the above-mentioned multiple checkpoints may include a first checkpoint and a second checkpoint that run successively in chronological order, and the code corresponding to the first checkpoint is run before the code corresponding to the second checkpoint; the detection identification information of the multiple checkpoints is used by the first software system to record software running anomaly information when the first checkpoint does not belong to the checkpoints in the set of prerequisite checkpoints. The software running anomaly information is used to characterize the abnormal running order of the second software system. The checkpoints in the set of prerequisite checkpoints may be the checkpoints determined based on the checkpoint registration information that are adjacent to the second checkpoint and expected to run before the second checkpoint.

[0148] For the optional implementation of this step S410, reference may be made to Figure 2Alternative implementation of step S230, and Figure 2 Other related parts in the embodiments involved will not be elaborated here.

[0149] By using the above method, the running order of the second software system is detected based on the first software system, which is no longer limited to software detection within the same software system. Moreover, the first software system as the detector and the second software system as the detected are respectively running in different running environments that are securely isolated from each other within the same processor, thereby enhancing the reliability of software detection and also improving the reliability of autonomous driving.

[0150] In some examples, the second software system may send checkpoint registration information to the first software system so that the first software system can determine the expected running order of multiple checkpoints in the second software system according to the checkpoint registration information. The expected running order may be represented based on the set of pre-checkpoints corresponding to the target checkpoint. Exemplarily, the checkpoint registration information may include the detection identification information of the target checkpoint set in the second software system and the detection identification information of the pre-checkpoints corresponding to the target checkpoint. The target checkpoint may include multiple checkpoints, such as a first checkpoint and a second checkpoint that run successively in chronological order.

[0151] In this way, the second software system can notify the first software system of the expected running order of multiple checkpoints to achieve software detection.

[0152] In some embodiments of the present disclosure, the second software system may also perform self-detection. Figure 5 It is a flowchart of a software detection method provided by an embodiment of the present disclosure. This method may be executed by Figure 1 the second software system in the shown processor, as Figure 5 shown, this method may include the following steps S510 to step S520.

[0153] Step S510, the second software system determines checkpoint running information.

[0154] Among them, the checkpoint running information may be used to characterize the actual running order of multiple checkpoints in the second software system that run successively in chronological order.

[0155] Step S520, the second software system determines whether there is a software running anomaly in the second software system according to the checkpoint running information.

[0156] In some instances, the checkpoint running information may include the detection identification information of multiple checkpoints. The multiple checkpoints may include a first checkpoint and a second checkpoint that run successively in chronological order, and the code corresponding to the first checkpoint is run before the code corresponding to the second checkpoint.

[0157] In some examples, multiple detection points may be preset in the second software system, and each detection point may correspond to different detection identification information. The detection identification information includes a function identifier corresponding to the target detection point and a detection point identifier. The function identifier can be used to represent the target function where the target detection point is located, and the detection point identifier can be used to represent the position or expected running order of the target detection point inside the target function. The same detection point identifier represents different detection points in different target functions. The target detection point may include a first detection point and a second detection point that run successively in chronological order.

[0158] In one implementation, detection points may be set in units of functions. The detection points set in the second software system can be classified into multiple types according to the set positions. For example, it may include one or more of the first type of detection points to the third type of detection points in the foregoing embodiments. Further, the third type of detection points can be further distinguished. For example, it may include one or more of the fourth to sixth type of detection points in the foregoing embodiments.

[0159] Regarding the specific implementation manner of the detection identification information, reference may be made to the description in the foregoing embodiments of the present disclosure, which will not be elaborated herein.

[0160] In some examples, the second software system can determine whether the actual running order of the first detection point and the second detection point conforms to the set expected running order according to the detection identification information; the expected running order is determined according to the detection point registration information sent by the second software system to the first software system during initialization; in the case where the actual running order of the first detection point and the second detection point does not conform to the expected running order, it is determined that the second software system has a software running anomaly.

[0161] Exemplarily, the set of pre-detection points corresponding to the second detection point can be obtained according to the detection identification information. In the case where the first detection point belongs to the detection points in the set of pre-detection points, it is determined that the actual running order of the first detection point and the second detection point conforms to the set expected running order; or, in the case where the first detection point does not belong to the detection points in the set of pre-detection points, it is determined that the actual running order of the first detection point and the second detection point does not conform to the set expected running order.

[0162] Among them, the detection points in the set of pre-detection points can be the detection points that are adjacent to the second detection point and are expected to run before the second detection point, determined based on the detection point registration information. The detection point registration information can be the detection point registration process inside the second software system. When the second software system is initialized, a detection point data structure of each detection point and its corresponding set of pre-detection points is generated inside the second software system.

[0163] It should be noted that Figure 5For the specific implementation manners of the steps in the illustrated embodiments, reference may be made to the descriptions in the foregoing embodiments of the present disclosure. For example, for the specific implementation manner in step S520 where the second software system determines whether there is a software operation anomaly according to the detection point operation information, reference may also be made to Figure 2 the description in step S240 of the illustrated embodiment where the first software system determines whether there is a software operation anomaly in the second software system according to the detection point operation information, which will not be elaborated herein. Further, Figure 5 The illustrated embodiments may also be combined with any optional steps in the foregoing embodiments of the present disclosure to obtain new embodiments, and the present disclosure makes no limitation thereto.

[0164] By using the above method, detection points are set in units of functions, that is, the detection point identifier only takes effect within one function, and different functions can reuse this detection point identifier. For example, there can be a detection point identifier of 0x81 in both of two functions. In this way, the demand for detection point identifiers is reduced, and this detection point identifier can be represented based on integer values. Compared with the related art where hash values need to be calculated, the implementation manner of this embodiment can significantly reduce the amount of computation, relieve the load on the processor, and thus improve the software detection efficiency.

[0165] Figure 6 is a schematic structural diagram of an electronic device provided by an embodiment of the present disclosure. As Figure 6 shown, the electronic device 1000 may include a memory 1010 and a processor 1020. The memory 1010 may be used to store computer instructions, and the processor 1020 may be used to call computer instructions from the memory 1010 to execute all or part of the steps of any method in the foregoing embodiments of the present disclosure. Among them, the processor may be one or more, and the one or more processors may execute instructions alone or jointly. The memory may also be one or more, and the one or more memories may store the above computer instructions alone or jointly.

[0166] In some examples, a first software system runs in the first operating environment of the processor, and a second software system runs in the second operating environment of the processor. The security level of the first operating environment is higher than that of the second operating environment; the first software system may be used to execute as Figure 3 shown in the method; the second software system may be used to execute as Figure 4 the method.

[0167] In other examples, a second software system may run in the processor, and the second software system may be used to execute as Figure 5 It should be noted that there seems to be a duplicate tag in the original text. I have translated it as "Figure 2" as it is likely a misspelling of which is also "Figure 2". If this is not correct, please provide more context or clarify the issue. shown in the method.

[0168] Embodiments of the present disclosure also provide a vehicle, which may include a memory and a processor. The memory may be used to store computer instructions, and the processor may be used to call the computer instructions from the memory to execute all or part of the steps of any of the methods in the foregoing embodiments of the present disclosure. Wherein, the processor may be one or more, and the one or more processors may execute the instructions alone or jointly. The memory may also be one or more, and the one or more memories may store the above computer instructions alone or jointly. In some examples, the processor in the vehicle may be the processor in the foregoing embodiments of the present disclosure, and the first software system and the second software system may be deployed in the processor.

[0169] The vehicle in the foregoing embodiments of the present disclosure may be an electric vehicle, a hybrid vehicle, a fuel cell vehicle, or other types of vehicles. The vehicle may be an autonomous vehicle or a non-autonomous vehicle.

[0170] Embodiments of the present disclosure also provide a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements any of the methods in the foregoing embodiments of the present disclosure. Optionally, the computer-readable storage medium may be a non-transitory storage medium, but is not limited thereto, and it may also be a transitory storage medium.

[0171] Embodiments of the present disclosure also provide a chip, which may include a processing unit, and the processing unit may be used to execute all or part of the steps of any of the methods in the foregoing embodiments of the present disclosure. The chip may be in the form of an application-specific integrated circuit (ASIC), a system-on-chip (SOC), a field-programmable gate array (FPGA), etc., and this embodiment does not make any limitation thereto. Optionally, the chip may further include a storage unit, and the storage unit may be used to store computer instructions. The processing unit may be used to call the computer instructions from the storage unit to execute all or part of the steps of any of the methods in the foregoing embodiments of the present disclosure.

[0172] Embodiments of the present disclosure also provide a computer program product, which may include a computer program. When the computer program is executed by a processor, it may implement any of the methods in the foregoing embodiments of the present disclosure.

[0173] The present disclosure may be a system, a method, and / or a computer program product. The computer program product may include a computer-readable storage medium, on which computer-readable program instructions for causing a processor to implement any of the methods in the foregoing embodiments of the present disclosure are uploaded.

[0174] A computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example—but not limited to—an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punched card or raised structures in grooves having instructions stored thereon, and any suitable combination of the foregoing. The computer-readable storage medium as used herein is not construed to be an instantaneous signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable), or an electrical signal transmitted through a wire.

[0175] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing / processing devices, or can be downloaded to an external computer or external storage device through a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include a copper transmission cable, an optical fiber transmission, a wireless transmission, a router, a firewall, a switch, a gateway computer, and / or an edge server. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in each computing / processing device.

[0176] The computer program instructions for performing the operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine - related instructions, microcode, firmware instructions, state - setting data, or source code or object code written in any combination of one or more programming languages, which may include object - oriented programming languages - such as Smalltalk, C++, etc., and conventional procedural programming languages - such as the "C" language or similar programming languages. The computer - readable program instructions may be executed entirely on the user's computer, partially on the user's computer, executed as a stand - alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network - including a local area network (LAN) or a wide area network (WAN) - or, alternatively, may be connected to an external computer (e.g., via the Internet service provider through the Internet). In some embodiments, by using the state information of the computer - readable program instructions to customize an electronic circuit, such as a programmable logic circuit, a field - programmable gate array (FPGA), or a programmable logic array (PLA), the electronic circuit can execute the computer - readable program instructions to implement various aspects of the present disclosure.

[0177] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer - readable program instructions.

[0178] These computer - readable program instructions can be provided to a processor of a general - purpose computer, a special - purpose computer, or other programmable data - processing apparatus to produce a machine, such that the instructions, when executed by the processor of the computer or other programmable data - processing apparatus, create a means for implementing the functions / acts specified in one or more blocks of the flowchart and / or block diagram. These computer - readable program instructions can also be stored in a computer - readable storage medium, which instructions cause a computer, a programmable data - processing apparatus, and / or other devices to operate in a particular manner, so that the computer - readable medium storing the instructions comprises a manufacture, which includes instructions for implementing various aspects of the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0179] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other devices to produce a computer-implemented process, such that the instructions executed on the computer, other programmable data processing apparatus, or other devices implement the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0180] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, a segment of a program, or a portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two consecutive blocks may in fact be executed substantially in parallel, or they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified functions or actions, or by a combination of dedicated hardware and computer instructions. It should be noted that implementation by hardware, implementation by software, and implementation by a combination of software and hardware are equivalent.

[0181] The embodiments of the present disclosure have been described above. The above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art in the field without departing from the scope and spirit of the described embodiments. The selection of the terms used herein is intended to best explain the principles of the embodiments, the practical application, or the technical improvement of the technology in the market, or to enable other ordinary skill in the art in the field to understand the embodiments disclosed herein. The scope of the present disclosure is defined by the appended claims.

Claims

1. A software detection method, characterized in that, Applied to a first software system that runs in a first operating environment of a processor, and a second software system runs in a second operating environment of the processor. The security level of the first operating environment is higher than that of the second operating environment. The method includes: Obtain the checkpoint running information sent by the second software system to the first software system; wherein, the checkpoint running information is used to characterize the actual running order of multiple checkpoints in the second software system running successively in chronological order; Determine whether the second software system has software running anomalies according to the checkpoint running information.

2. The method according to claim 1, wherein The checkpoint running information includes the detection identification information of multiple checkpoints. The multiple checkpoints include a first checkpoint and a second checkpoint that run successively in chronological order. The code corresponding to the first checkpoint is run before the code corresponding to the second checkpoint. Determining whether the second software system has software running anomalies according to the checkpoint running information includes: Determine whether the actual running order of the first checkpoint and the second checkpoint conforms to the set expected running order according to the detection identification information; the expected running order is determined according to the checkpoint registration information sent by the second software system to the first software system during initialization; In the case where the actual running order of the first checkpoint and the second checkpoint does not conform to the expected running order, determine that the second software system has software running anomalies.

3. The method according to claim 2, wherein Determining whether the actual running order of the first checkpoint and the second checkpoint conforms to the set expected running order according to the detection identification information includes: Obtain the set of pre-checkpoints corresponding to the second checkpoint according to the detection identification information; wherein, the checkpoints in the set of pre-checkpoints are the checkpoints determined based on the checkpoint registration information and adjacent to the second checkpoint and expected to run before the second checkpoint; In the case where the first checkpoint belongs to the checkpoints in the set of pre-checkpoints, determine that the actual running order of the first checkpoint and the second checkpoint conforms to the set expected running order; or, in the case where the first checkpoint does not belong to the checkpoints in the set of pre-checkpoints, determine that the actual running order of the first checkpoint and the second checkpoint does not conform to the set expected running order.

4. The method according to claim 1, wherein The information transfer between the first operating environment and the second operating environment is based on a security monitoring call instruction. Obtaining the checkpoint running information sent by the second software system to the first software system includes: Obtain the checkpoint running information sent by the second software system based on the security monitoring call instruction.

5. The method according to claim 1, wherein The processor is a vehicle processor, the first software system is a vehicle safety monitoring system, and the second software system is an operating system running vehicle autonomous driving software.

6. The method according to claim 3, wherein The method further includes: Obtain the detection point registration information sent by the second software system; wherein, the detection point registration information includes the detection identification information of the target detection points set in the second software system and the detection identification information of the pre-detection points corresponding to the target detection points, and the target detection points include the first detection point and the second detection point; Determine the expected running order of multiple detection points in the second software system according to the detection point registration information; wherein, the expected running order is represented based on the set of pre-detection points corresponding to the target detection points.

7. The method according to claim 6, characterized in that The detection identification information includes the function identification corresponding to the target detection point and the detection point identification, the function identification is used to characterize the target function where the target detection point is located, the detection point identification is used to characterize the position or the expected running order of the target detection point inside the target function, and the same detection point identification represents different detection points in different target functions, and the target detection points include the first detection point and the second detection point.

8. The method according to any one of claims 1 to 7, characterized in that The detection points set in the second software system include one or more of the following types: The first type of detection point set at the head of the function, and the detection point identification of the first type of detection point is the first preset identification; The second type of detection point set at the tail of the function, and the detection point identification of the second type of detection point is the second preset identification; The third type of detection point set at other positions except the head and the tail of the function, and the detection point identification of the third type of detection point is set to other identifications except the first preset identification and the second preset identification according to the order of the position of the detection point in the function, and the detection point identifications of different third type of detection points in the same function are different; the third type of detection point includes multiple detection points set at the head, tail and inside of the basic block.

9. The method according to claim 8, wherein The third type of detection point includes one or more of the following types: The fourth type of detection point set before the function call instruction, and the detection point identification of the fourth type of detection point is the fourth preset identification; The fifth type of detection point set after the function call instruction, and the detection point identification of the fifth type of detection point is the fifth preset identification; The sixth type of detection point set at other positions except before the function call instruction, after the function call instruction, at the head of the function and at the tail of the function, and the detection point identification of the sixth type of detection point is set to other identifications except the first preset identification, the second preset identification, the fourth preset identification and the fifth preset identification according to the order of the position of the detection point in the function, and the detection point identifications of different sixth type of detection points in the same function are different.

10. A software detection method, characterized in that, Applied to the second software system, the second software system runs in the second operating environment of the processor, the first software system runs in the first operating environment of the processor, and the security level of the first operating environment is higher than that of the second operating environment; the method includes: Send checkpoint running information to the first software system so that the first software system can determine whether the second software system has software running anomalies based on the checkpoint running information; wherein, the checkpoint running information is used to represent the actual running order of multiple checkpoints in the second software system running successively in chronological order.

11. An electronic device, characterized in that, It includes a memory and a processor. The memory is used to store computer instructions. A first software system runs in the first operating environment of the processor, and a second software system runs in the second operating environment of the processor. The security level of the first operating environment is higher than that of the second operating environment; The first software system is used to execute the method according to any one of claims 1 to 9; The second software system is used to execute the method according to claim 10.

12. A computer-readable storage medium, characterized in that, A computer program is stored thereon, and when the computer program is executed by a processor, the method according to any one of claims 1 to 10 is implemented.

Images