Method and system for formalized verification of LiteOS-M kernel from source code to architecture layer, computer equipment and medium

Abstract

The invention discloses a formalized verification method and system for a LiteOS-M kernel from a source code to an architecture layer, computer equipment and a medium, and the method comprises the steps: defining a basic model of the LiteOS-M kernel, defining corresponding variables and channels based on the basic model according to a verification demand of a to-be-verified attribute, and establishing a corresponding APA verification model, the attributes to be verified comprise concurrency and scheduling attributes, security and isolation attributes and performance attributes; performing mathematical description on the to-be-verified attribute to form a property protocol, and converting the property protocol into a linear sequential logic formula through deductive reasoning; and performing formalized verification on the to-be-verified attribute based on the linear sequential logic formula. According to the method, the system to be verified can be effectively split and combined according to the relation from top to bottom, the corresponding abstract function model is constructed, and the consistency from the LiteOS-M kernel source code to the security function is verified.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of operating system formal verification, and particularly relates to a method and system for formal verification of LiteOS-M kernel from source code to architecture layer, computer device and medium. BACKGROUND

[0002] LiteOS-M kernel is a lightweight Internet of Things operating system kernel for IoT field, supporting operating system basic components such as task management, memory management, time management, communication mechanism, interrupt management, queue management, event management and timer, and better supporting low-power consumption scenarios, and playing an important role in Internet access devices. The security problems and defects of LiteOS-M kernel may cause serious consequences, so it is very important to analyze and test the security of the Internet of Things operating system and improve its stability and reliability. The formal verification and security certification of the Internet of Things operating system have achieved good results abroad, but from a technical point of view, operating system security certification and source code level formal verification are still challenges. SUMMARY

[0003] In view of the above defects of the prior art, the present application provides a method and system for formal verification of LiteOS-M kernel from source code to architecture layer, computer device and medium, and the technical solutions adopted by the present application are as follows: In a first aspect, the present application provides a robot operation method based on KaiHong OS, which comprises: Defining a basic model of LiteOS-M kernel, based on the basic model, defining corresponding variables and channels according to the verification requirements of the to-be-verified properties, and establishing a corresponding APA verification model, wherein the to-be-verified properties include concurrency and scheduling properties, security and isolation properties, and performance properties; Mathematically describing the to-be-verified properties to form property specifications, and converting the property specifications into linear temporal logic formulas through deductive reasoning; Formally verifying the to-be-verified properties based on the linear temporal logic formulas.

[0004] In an implementation mode, the basic model of LiteOS-M kernel is defined, which comprises: CSP modeling is performed on the overall architecture of LiteOS-M kernel to clearly define the architecture level relationship and core interaction logic; CSP modeling is performed on the key sub-modules to obtain the basic model.

[0005] In an implementation mode, the key sub-modules include a memory management module, an interrupt management module, a task management module, and a synchronization and communication module.

[0006] In an implementation, CSP modeling is performed on the key sub-modules to obtain a basic model, including: The running mechanism of the source code of the key sub-modules is analyzed, and corresponding parameters are defined; The running mechanism and data structure of the key sub-modules are modeled at a certain level of abstraction.

[0007] In an implementation, the property specification is converted into a linear temporal logic formula through deductive reasoning, including: The property specification is expressed as a linear temporal logic formula, and a constraint condition corresponding to the linear temporal logic formula is defined, the constraint condition including: a task type, a global variable initial value, and a module interaction rule; All possible states of the constraint condition model are listed, including positive example states conforming to expectations and negative example states to be avoided.

[0008] In an implementation, the formal verification is performed on the to-be-verified attribute based on the linear temporal logic formula, including: For concurrency and scheduling attributes, the reachability checking method is used to verify whether the PAT verification model can reach an expected state under a specified constraint condition based on the linear temporal logic formula and all possible states; For security and isolation attributes, it is determined whether the PAT verification model meets the isolation requirement based on the linear temporal logic formula and all possible states; For performance attributes, it is determined whether the task execution efficiency and resource occupation conform to the property specification by detecting the PAT verification model based on the performance index defined in the linear temporal logic formula.

[0009] In an implementation, the method further includes: A bounded model checker tool is used to perform static formal verification on the LiteOS-M kernel source code.

[0010] In a second aspect, an embodiment of the present application further provides a system for formal verification of a LiteOS-M kernel from source code to an architecture layer, wherein the system is used to implement the steps of the formal verification method of the LiteOS-M kernel from source code to the architecture layer as described in any of the above embodiments, and the system includes: A model establishing module is configured to define a basic model of the LiteOS-M kernel, define corresponding variables and channels based on the basic model according to verification requirements of to-be-verified attributes, and establish a corresponding APA verification model, wherein the to-be-verified attributes include: concurrency and scheduling attributes, security and isolation attributes, and performance attributes. A mathematical description module is configured to perform mathematical description on the to-be-verified attributes, form a property specification, and convert the property specification into a linear temporal logic formula through deductive reasoning. a formal verification module configured to perform formal verification on the to-be-verified property based on the linear temporal logic formula.

[0011] In a third aspect, an embodiment of the present application further provides a computer device, wherein the computer device comprises a memory, a processor, and a program of formal verification of LiteOS-M kernel from source code to architecture layer stored in the memory and capable of running on the processor, and the processor implements the steps of the method of formal verification of LiteOS-M kernel from source code to architecture layer in any of the above solutions when executing the program of formal verification of LiteOS-M kernel from source code to architecture layer.

[0012] In a fourth aspect, an embodiment of the present application further provides a computer readable storage medium, wherein the computer readable storage medium stores a program of formal verification of LiteOS-M kernel from source code to architecture layer, and the program of formal verification of LiteOS-M kernel from source code to architecture layer implements the steps of the method of formal verification of LiteOS-M kernel from source code to architecture layer in any of the above solutions on the computer readable storage medium.

[0013] Advantages: Compared with the prior art, the present application provides a method of formal verification of LiteOS-M kernel from source code to architecture layer, which first defines a basic model of LiteOS-M kernel, defines corresponding variables and channels according to verification requirements of to-be-verified properties based on the basic model, and establishes a corresponding APA verification model, wherein the to-be-verified properties include concurrency and scheduling properties, security and isolation properties, and performance properties. Then, the to-be-verified properties are mathematically described to form property specifications, and the property specifications are converted into linear temporal logic formulas through deductive reasoning. Finally, formal verification is performed on the to-be-verified properties based on the linear temporal logic formulas. The present application can effectively split and combine to-be-verified systems in a top-down relationship, construct corresponding abstract functional models, and verify the consistency of LiteOS-M kernel source code to security functions. BRIEF DESCRIPTION OF DRAWINGS

[0014] Figure 1 An application environment diagram of the method of formal verification of LiteOS-M kernel from source code to architecture layer provided by an embodiment of the present application.

[0015] Figure 2 A flowchart of a preferred embodiment of the method of formal verification of LiteOS-M kernel from source code to architecture layer provided by an embodiment of the present application.

[0016] Figure 3 A principle diagram of the method of formal verification of LiteOS-M kernel from source code to architecture layer provided by an embodiment of the present application.

[0017] Figure 4 The flowchart illustrates the specific application of the LiteOS-M kernel formal verification method from source code to the architecture layer provided in this embodiment of the invention.

[0018] Figure 5 This is an architecture diagram of a robot operating system based on KaiHong OS provided for an embodiment of the present invention.

[0019] Figure 6 A schematic block diagram of a computer device provided for an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0021] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content, operations, or steps, nor does it require execution in the described order. For example, some operations or steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0022] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. For example, the first control information and the second control information are only used to distinguish different control information and do not limit their order. Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or the order of execution, and that the words "first" and "second" do not necessarily imply that they are different. It should also be understood that the terms "and / or" as used in this specification and the appended claims refer to any combination of one or more of the associated listed items and all possible combinations, and include such combinations.

[0023] To address the problems of existing technologies, this invention provides a method for formal verification of the LiteOS-M kernel from source code to the architecture layer. In specific application, a basic model of the LiteOS-M kernel is first defined. Based on this basic model, corresponding variables and channels are defined according to the verification requirements of the attributes to be verified, and a corresponding APA verification model is established. The attributes to be verified include: concurrency and scheduling attributes, security and isolation attributes, and performance attributes. Then, the attributes to be verified are mathematically described to form property specifications, which are then transformed into linear temporal logic formulas through deductive reasoning. Finally, formal verification of the attributes to be verified is performed based on the linear temporal logic formulas. This embodiment can effectively decompose and combine the system to be verified in a top-down manner, constructing a corresponding abstract functional model to verify the consistency from the LiteOS-M kernel source code to security functions.

[0024] This embodiment provides a method for formal verification of the LiteOS-M kernel from source code to the architecture layer. This method for formal verification of the LiteOS-M kernel from source code to the architecture layer can be applied to… Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104, or it can be placed in the cloud or on other network servers. The formal verification method for the LiteOS-M kernel, from source code to the architecture layer, can be executed via terminal 102 or server 104, or it can be executed collaboratively by terminal 102 and server 104.

[0025] The terminal 102 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, IoT device, or portable wearable device. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices, etc.

[0026] Server 104 can be an independent physical server, a cloud server, or a service node in a blockchain system, where the service nodes in the blockchain system form a peer-to-peer network.

[0027] In addition, server 104 can also be a server cluster consisting of multiple physical servers, which can be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0028] Terminal 102 and server 104 can be connected via Bluetooth, USB (Universal Serial Bus) or network, etc., and this application does not impose any restrictions.

[0029] In some embodiments, such as Figure 2 The diagram illustrates a method for formal verification of the LiteOS-M kernel, from source code to the architecture layer. This method can be applied to terminals for controlling robots; these terminals can be intelligent products such as computers. Specifically, the method includes the following steps: Step S100: Define the basic model of the LiteOS-M kernel. Based on the basic model, define the corresponding variables and channels according to the verification requirements of the attributes to be verified, and establish the corresponding APA verification model. The attributes to be verified include: concurrency and scheduling attributes, security and isolation attributes, and performance attributes.

[0030] Specifically, this embodiment performs CSP modeling on the overall LiteOS-M kernel architecture, clarifying the hierarchical relationships and core interaction logic. Then, CSP modeling is performed on key sub-modules to obtain the basic model. The basic model of the LiteOS-M kernel constructed in this embodiment is the core foundation for all subsequent verification work, and its quality directly affects the accuracy and efficiency of the verification results. Figure 3 As shown, the LiteOS-M kernel's overall architecture adopts a layered design, comprising the application layer, kernel service layer, and hardware abstraction layer from top to bottom. The kernel service layer is the core, containing key sub-modules such as task management, memory management, interrupt management, synchronization, and communication. The core of CSP architecture modeling is to clarify the interaction relationships and data flow between modules, and to define global interaction channels and core state variables.

[0031] like Figure 4 As shown, this step uses the CSP modeling language to model the basic architecture and key sub-modules of the LiteOS-M kernel. Specifically, the modeling process first analyzes the LiteOS-M kernel's source code architecture and extracts the core interaction logic: the application layer calls the kernel service layer's functions through system call interfaces; the various modules of the kernel service layer interact and collaborate through internal interfaces; the hardware abstraction layer provides hardware adaptation support for the kernel service layer, shielding hardware differences. Key sub-modules include a memory management module, an interrupt management module, a task management module, and a synchronization and communication module. The modeling process for each key sub-module follows the flow of "source code analysis → parameter definition → logic abstraction → CSP implementation." This embodiment analyzes the source code operation mechanism of the key sub-modules and defines the corresponding parameters. Then, the operation mechanism and data structure of the key sub-modules are modeled at a certain level of abstraction.

[0032] The following uses the task management module as an example to explain the modeling process in detail: First, the source code execution mechanism of the LiteOS-M kernel task management module is analyzed: The task management module is responsible for tasks such as creation, scheduling, deletion, suspension, and wake-up. Its core data structures include the Task Control Block (TCB), the ready queue, and the blocked queue. The core execution mechanism is priority-based preemptive scheduling, where higher-priority tasks can preempt the CPU usage rights of lower-priority tasks. Task states include ready, running, blocked, and suspended. Based on the above analysis, the core parameters of the task management module are defined as follows: Task parameters: TaskID (unique task identifier), Priority (task priority, range 0-31, 0 is the highest priority), State (task status: Ready, Running, Blocked, Suspended), Entry (task entry function address), StackSize (task stack size), TCBPtr (task control block pointer). Queue parameters: ReadyQueue (ready queue, sorted by priority), BlockedQueue (blocked queue, categorized by blocking reason); Scheduling parameters: SchedulingPolicy (PriorityPreemptive), CurrentTask (Current running task ID).

[0033] Then, the core operating mechanism of the task management module is abstracted, and the following core logic is extracted. The operating mechanism and data structure of the key sub-modules are modeled at a certain level of abstraction, as follows: Task creation: The application layer calls the osThreadCreate interface, the module initializes the task TCB, sets the task status to Ready, and adds the task to the ready queue of the corresponding priority. Task scheduling: When there is a high-priority task in the ready queue, the scheduler is triggered, the current task context is saved, the task is switched to the high-priority task, and the CurrentTask is updated. Task blocking: When a task calls osThreadSuspend or waits for a resource (such as a semaphore), its state changes to Blocked, it is removed from the ready queue and added to the blocked queue; Task wake-up: When the blocking condition is released (such as semaphore release), the task state switches to Ready, is removed from the blocking queue, and added to the ready queue. If the priority is higher than the current task, scheduling is triggered.

[0034] Similarly, other key sub-modules are the same as those mentioned above. They all extract core logic through source code analysis, define key parameters, and implement abstract models using the CSP language to ensure the consistency between the models of each module and the actual operating mechanism of the kernel, while controlling the complexity of the models and laying the foundation for subsequent verification.

[0035] Furthermore, PAT (Process Analysis Toolkit) is an automated verification tool that supports concurrent modeling languages ​​such as CSP. It features model checking, reachability analysis, and deadlock detection, effectively handling verification issues in concurrent systems. This embodiment, based on the established base model and considering the requirements of the attributes to be verified, supplements the definition of variables and channels, and writes verification model code recognizable by the PAT tool. The attributes to be verified include concurrency and scheduling attributes, security and isolation attributes, and performance attributes. This embodiment allows for the definition of specific variables and channels for the verification requirements of each type of attribute. Then, the base model is integrated with the supplemented variables and channels to write the PAT verification model code.

[0036] Step S200: Mathematically describe the attribute to be verified to form a property specification, and transform the property specification into a linear temporal logic formula through deductive reasoning.

[0037] Property specifications are explicit descriptions of specific attributes that a system should satisfy, requiring precision and unambiguity. This step first mathematically describes the attributes to be verified, forming property specifications, and then transforms them into LTL (Linear Temporal Logic) formulas through deductive reasoning for automated verification by the PAT tool. Based on the application scenarios and core requirements of the LiteOS-M kernel, property specifications are formulated for three types of attributes to be verified: (1) Property specification of concurrency and scheduling attributes Rule 1 (No Deadlock): Within the verification time window, the kernel system never reaches a state where all tasks are blocked and no tasks are ready; that is, the kernel will not get stuck in a deadlock.

[0038] Rule 2 (Priority Preemption): After a high-priority task enters the ready state, if the currently running task is a low-priority task, the high-priority task should preempt the CPU within a limited time.

[0039] Rule 3 (Fairness of Task Scheduling): In the absence of a high-priority task ready, tasks of the same priority should be scheduled in FIFO order, and the number of times each task is scheduled should not differ by more than 1.

[0040] (2) Property specifications for security and isolation attributes Rule 1 (Memory Access Isolation): Tasks may only access their authorized memory address ranges, and unauthorized memory access requests should be rejected.

[0041] Rule 2 (Permissions cannot be tampered with): Resource access permissions for tasks can only be modified through the system authorization interface, and permissions cannot be elevated through illegal means.

[0042] Protocol 3 (Data Transmission Security): When tasks transmit data through synchronization and communication modules, the data can only be received by the target task and cannot be stolen by other tasks.

[0043] (3) Property specifications of performance attributes Specification 1 (Task Response Time): The response time (from readiness to start of execution) for high-priority tasks shall not exceed 10ms, for medium-priority tasks it shall not exceed 20ms, and for low-priority tasks it shall not exceed 50ms.

[0044] Specification 2 (Scheduling Delay): The delay from triggering to completing the task switching by the scheduler shall not exceed 3ms.

[0045] Specification 3 (Resource Utilization): The CPU utilization rate shall not be less than 60% within the verification time window (for high-load scenarios).

[0046] LTL formulas describe the dynamic behavior of a system using timing operators, commonly including: always, eventually, next time step, and until. Combining the mathematical description of the aforementioned property reduction, deductive reasoning transforms it into LTL formulas (Linear Temporal Logic formulas). Furthermore, this embodiment defines corresponding constraints for each LTL formula, for example: Task type constraints: TaskSet = {T1 (high priority, task type: interrupt handling), T2 (medium priority, task type: data acquisition), T3 (medium priority, task type: data processing), T4 (low priority, task type: log reporting)}.

[0047] Module interaction rules: Only the task management module can trigger the scheduler, only the memory management module can handle memory access requests, and the synchronization and communication module only forwards data with clearly defined target tasks.

[0048] Finally, enumerate all possible states of the model under the constraints (i.e., corresponding states). Figure 4 The model's expected states (including positive and negative example states) are as follows: In a normal state (concurrency and scheduling attributes): when T1 (priority 0) is ready, T2 (priority 1) is running. Within 5ms, T1 preempts T2 and starts running. T2 and T3 of the same priority run alternately, and the scheduling count is 5 times for each.

[0049] Counterexample state (concurrency and scheduling attributes): After T1 is ready, T2 continues to run for more than 5ms without being preempted; the difference in the number of scheduling times between T2 and T3 is 2.

[0050] Step S300: Perform formal verification of the attribute to be verified based on the linear time-series logic formula.

[0051] This embodiment loads the established PAT verification model and LTL formula using the PAT tool, and performs formal verification for three types of attributes to be verified. Specifically, for concurrency and scheduling attributes, based on the linear time-series logic formula and all possible states, this embodiment uses a reachability check method to verify whether the PAT verification model can achieve the expected state under specified constraints. For security and isolation attributes, based on the linear time-series logic formula and all possible states, this embodiment determines whether the PAT verification model meets the isolation requirements. For performance attributes, based on the performance indicators defined in the linear time-series logic formula, the PAT verification model is used to detect whether the execution efficiency and resource consumption of the verification task conform to the property specification.

[0052] In practical applications, this embodiment performs formal verification on three types of attributes to be verified, including reachability checks, deadlock detection, and attribute satisfaction checks, as detailed below: For concurrency and scheduling property verification, the goal is to verify whether the kernel meets the requirements for deadlock-free operation, priority preemption, and scheduling fairness. The verification process includes: opening the PAT tool and importing the PAT verification model code (.csp file); in the "Property" panel of the PAT tool, entering the LTL formulas corresponding to the concurrency and scheduling properties, and then configuring the verification parameters: verification time window MaxTime=1000ms, unlimited state search depth, and enabling the "deadlock detection" function; running the verification, the PAT tool will automatically traverse the model's state space and check whether the LTL formulas are satisfied.

[0053] For security and isolation attribute verification, the goal is to verify whether the kernel meets the specifications for memory access isolation, non-tamperable permissions, and secure data transmission. The verification process includes: importing the model code containing security verification logic into the PAT tool; inputting the LTL formulas corresponding to the security and isolation attributes; and configuring the verification parameters: enabling "illegal access detection" and recording memory access logs and permission change logs. Next, the verification is run, and the PAT tool will check whether all memory access requests and permission change operations comply with the specifications.

[0054] For performance attribute verification, the goal is to verify whether the kernel meets specifications regarding task response time, scheduling latency, and resource utilization. The verification process includes: importing the model code containing performance statistics logic into the PAT tool; inputting the LTL formulas corresponding to the performance attributes; then configuring the verification parameters: enabling the "Time Statistics" function to record task start / end times and scheduling trigger / completion times. Running the verification, the PAT tool will calculate performance metrics and check for compliance with the specifications.

[0055] CBMC (C Bounded Model Checker) is an open-source bounded model checker that supports static formal verification of C language source code. It can detect common memory safety issues such as array boundary overflows, null pointer dereferences, dangling pointer accesses, and integer overflows. This step uses CBMC to perform static verification of the LiteOS-M kernel source code, supplementing the verification of the underlying implementation's security. Specifically, the verification scope includes core files related to memory management, task management, and interrupt management in the LiteOS-M kernel source code, including `los_memory.c` (memory management), `los_task.c` (task management), and `los_interrupt.c` (interrupt management). CBMC configuration includes enabling array boundary checks, enabling pointer safety checks, enabling integer overflow checks, setting the verification depth to ensure sufficient coverage of execution paths, and generating a verification report recording the detected issues and their locations. Developers can use the CBMC verification report to locate and fix underlying security flaws in the source code, ensuring the fundamental memory safety of the kernel source code.

[0056] In summary, this invention provides a basic verification framework for the formal verification of common lightweight operating systems. Furthermore, this framework is not limited to single model detection but also involves source code-level detection, enabling multi-level verification from code abstraction modeling to specific source code.

[0057] Based on the above embodiments, the present invention also provides a system for formal verification of the LiteOS-M kernel from source code to the architecture layer, which is used to implement the steps in the above method embodiments. Figure 5As shown, the system includes a model building module 10, a mathematical description module 20, and a formal verification module 30. Specifically, the model building module 10 defines the basic model of the LiteOS-M kernel. Based on this basic model, it defines corresponding variables and channels according to the verification requirements of the attributes to be verified, and establishes a corresponding APA verification model. The attributes to be verified include concurrency and scheduling attributes, security and isolation attributes, and performance attributes. The mathematical description module 20 performs a mathematical description of the attributes to be verified, forming property specifications, and transforms these property specifications into linear temporal logic formulas through deductive reasoning. The formal verification module 30 performs formal verification of the attributes to be verified based on the linear temporal logic formulas.

[0058] In some embodiments, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a method for formal verification of the LiteOS-M kernel from source code to the architecture layer. The display unit of the computer device is used to form a visually visible image. It can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0059] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0060] In some embodiments, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps: Define the basic model of the LiteOS-M kernel. Based on the basic model, define the corresponding variables and channels according to the verification requirements of the attributes to be verified, and establish the corresponding APA verification model. The attributes to be verified include: concurrency and scheduling attributes, security and isolation attributes, and performance attributes. The attribute to be verified is mathematically described to form a property specification, and the property specification is transformed into a linear temporal logic formula through deductive reasoning. The attribute to be verified is formally verified based on the linear time-series logic formula.

[0061] It should be noted that the user information (including but not limited to user device function information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0062] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0063] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0064] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

[0065] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for formal verification of the LiteOS-M kernel from source code to the architecture layer, characterized in that, The method includes: Define the basic model of the LiteOS-M kernel. Based on the basic model, define the corresponding variables and channels according to the verification requirements of the attributes to be verified, and establish the corresponding APA verification model. The attributes to be verified include: concurrency and scheduling attributes, security and isolation attributes, and performance attributes. The attribute to be verified is mathematically described to form a property specification, and the property specification is transformed into a linear temporal logic formula through deductive reasoning. The attribute to be verified is formally verified based on the linear time-series logic formula.

2. The method for formal verification of the LiteOS-M kernel from source code to architecture layer according to claim 1, characterized in that, Define the basic model of the LiteOS-M kernel, including: CSP modeling was performed on the overall architecture of the LiteOS-M kernel to clarify the hierarchical relationships and core interaction logic. CSP modeling is performed on key sub-modules to obtain the basic model.

3. The method for formal verification of the LiteOS-M kernel from source code to the architecture layer according to claim 2, characterized in that, The key sub-modules include: memory management module, interrupt management module, task management module, and synchronization and communication module.

4. The method for formal verification of the LiteOS-M kernel from source code to the architecture layer according to claim 3, characterized in that, CSP modeling is performed on key sub-modules to obtain the basic model, including: Analyze the source code execution mechanism of key sub-modules and define the corresponding parameters; The operating mechanism and data structure of key sub-modules are modeled at a certain level of abstraction.

5. The method for formal verification of the LiteOS-M kernel from source code to the architecture layer according to claim 1, characterized in that, The property specification is transformed into a linear temporal logic formula through deductive reasoning, including: The property specification is expressed as a linear temporal logic formula, and the constraints corresponding to the linear temporal logic formula are defined. The constraints include: task type, initial value of global variable, and module interaction rules. List all possible states of the constraint model, including positive examples that meet expectations and negative examples that need to be avoided.

6. The method for formal verification of the LiteOS-M kernel from source code to the architecture layer according to claim 1, characterized in that, Formal verification of the attribute to be verified is performed based on the linear time-series logic formula, including: For concurrency and scheduling attributes, based on linear time-series logic formulas and all possible states, a reachability verification method is adopted to verify whether the PAT verification model can reach the expected state under specified constraints. Based on the linear time-series logic formula and all possible states, we determine whether the PAT verification model meets the isolation requirements for security and isolation properties. For performance attributes, based on the performance indicators defined in the linear time-series logic formula, the PAT verification model is used to detect whether the execution efficiency and resource consumption of the verification task conform to the property specification.

7. The method for formal verification of the LiteOS-M kernel from source code to the architecture layer according to claim 1, characterized in that, The method further includes: Static formal verification of the LiteOS-M kernel source code was performed using a bounded model checker tool.

8. A system for formal verification of the LiteOS-M kernel from source code to the architecture layer, characterized in that, The system is used to implement the steps of the method for formal verification of the LiteOS-M kernel from source code to architecture layer as described in any one of claims 1-7, the system comprising: The model building module is used to define the basic model of the LiteOS-M kernel. Based on the basic model, corresponding variables and channels are defined according to the verification requirements of the attributes to be verified, and a corresponding APA verification model is established. The attributes to be verified include: concurrency and scheduling attributes, security and isolation attributes, and performance attributes. The mathematical description module is used to mathematically describe the attribute to be verified, form a property specification, and transform the property specification into a linear temporal logic formula through deductive reasoning. The formal verification module is used to perform formal verification on the attribute to be verified based on the linear time-series logic formula.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a program for formal verification of the LiteOS-M kernel from source code to the architecture layer, stored in the memory and executable on the processor. When the processor executes the program for formal verification of the LiteOS-M kernel from source code to the architecture layer, it implements the steps of the method for formal verification of the LiteOS-M kernel from source code to the architecture layer as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program for formal verification of the LiteOS-M kernel from source code to the architecture layer, the program for formal verification of the LiteOS-M kernel from source code to the architecture layer implementing the steps of the method for formal verification of the LiteOS-M kernel from source code to the architecture layer as described in any one of claims 1-7 on the computer-readable storage medium.

Images