Formal verification method of memory management module and related device

Abstract

The invention discloses a formalized verification method of a memory management module and a related device, and relates to the technical field of operating system security, and the formalized verification method comprises the following steps: based on a demand document, a design document and a source code, sequentially constructing a demand layer formalized model, a design layer formalized model and an implementation layer formalized model in an interactive theorem prover, and on the basis of the demand document, constructing a demand layer formalized protocol in the interactive theorem prover, and completing the proving of the demand layer formalized protocol in the interactive theorem prover. And establishing a first refinement relationship between the design layer formalized model and the demand layer formalized model, and completing the certification of the first refinement relationship in the interactive theorem prover. And establishing a second refinement relationship between the implementation layer formalized model and the design layer formalized model, and completing the proof of the second refinement relationship in the interactive theorem prover. If the formalized specification, the first refinement relation and the second refinement relation are proved, it is judged that the memory management module passes formalized verification.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of operating system security, and particularly relates to a formal verification method of a memory management module and a related device. BACKGROUND

[0002] In a scenario with extremely high requirements for operating system reliability, a memory management module of an operating system needs to meet the determinacy requirements of the operating system on the basis of providing basic memory services. SUMMARY

[0003] In view of the above problems, the present application provides a formal verification method of a memory management module and a related device. The specific scheme is as follows:

[0004] The first aspect of the present application provides a formal verification method of a memory management module, comprising:

[0005] obtaining a requirement document, a design document and source code of a memory management module to be verified;

[0006] based on the requirement document, the design document and the source code, sequentially constructing a requirement layer formalization model, a design layer formalization model and an implementation layer formalization model in an interactive theorem prover;

[0007] The requirement layer formalization model is used to formally describe, in a meta language, algorithms and data structures of memory management operations defined in the requirement document, so as to define the functions of the memory management operations, the memory management operations including initialization operations, memory allocation operations and memory release operations.

[0008] The design layer formalization model is used to formally describe, in a meta language, algorithms and data structures of the memory management operations defined in the design document, so as to define the functions of the memory management operations.

[0009] The implementation layer formalization model is used to formally model functions of memory management operations defined in the source code in a state monoid of the interactive theorem prover, so as to define the functions of the memory management operations.

[0010] based on the requirement document, constructing a requirement layer formalization specification in the interactive theorem prover, and completing the proof of the requirement layer formalization specification in the interactive theorem prover; wherein the requirement layer formalization specification is used to formally describe, in a meta language, a plurality of requirement layer system properties defined in the requirement document, the requirement layer system properties including a plurality of functional correctness properties and a plurality of security properties.

[0011] establishing a first refinement relationship between the design layer formal model and the requirement layer formal model, and completing the proof of the first refinement relationship in the interactive theorem prover to confirm that the design layer formal model satisfies all the requirement layer formal specifications of the requirement layer formal model;

[0012] establishing a second refinement relationship between the implementation layer formal model and the design layer formal model, and completing the proof of the second refinement relationship in the interactive theorem prover to confirm that the implementation layer formal model satisfies all the requirement layer formal specifications of the design layer formal model;

[0013] If the formal specification, the first refinement relationship and the second refinement relationship are all proved, it is determined that the memory management module passes the formal verification, and the formal specification includes the requirement layer formal specification.

[0014] In a possible implementation,

[0015] In a possible implementation, the requirement layer system attributes include a plurality of functional correctness attributes and a plurality of security attributes, and the constructing, based on the requirement document, a requirement layer formal specification in the interactive theorem prover includes:

[0016] In the interactive theorem prover, each of the functional correctness attributes defined in the requirement document is described in a meta language to obtain a functional correctness specification for each of the memory management operations, and the plurality of functional correctness attributes include a correctness attribute of a function of each of the memory management operations.

[0017] In the interactive theorem prover, each of the security attributes defined in the requirement document is described in a meta language to obtain a security specification for each of the memory management operations, and the plurality of security attributes include memory total conservation, memory block non-overlapping and non-repeated release.

[0018] In a possible implementation, the formal verification method of the memory management module further includes:

[0019] constructing, based on the requirement document, a design layer formal specification in the interactive theorem prover, where the design layer formal specification is used to describe, in a meta language, a plurality of design layer system attributes defined in the design document, and the design layer system attributes include system attributes different from the requirement layer system attributes.

[0020] completing the proof of the design layer formal specification in the interactive theorem prover.

[0021] In a possible implementation, the formal verification method of the memory management module further includes:

[0022] Based on the source code, an implementation layer formal specification is constructed in the interactive theorem prover, wherein the implementation layer formal specification is used to describe a plurality of implementation layer system properties defined in the source code in a state monad formalization, and the implementation layer system properties include system properties different from the requirement layer system properties;

[0023] The proof of the implementation layer formal specification is completed in the interactive theorem prover.

[0024] In a possible implementation, if the requirement layer formal specification, the first refinement relationship and the second refinement relationship are all proved, it is determined that the memory management module passes the formal verification, comprising:

[0025] If the formal specification, the first refinement relationship and the second refinement relationship are all proved, it is determined that the memory management module passes the formal verification, and the formal specification further includes the design layer formal specification and the implementation layer formal specification.

[0026] In a possible implementation, the first refinement relationship between the design layer formal model and the requirement layer formal model is established, and the proof of the first refinement relationship is completed in the interactive theorem prover, comprising:

[0027] The first refinement relationship is established by defining a first mapping function, wherein the first mapping function is used to map a memory block structure in the design layer formal model to a memory block representation in the requirement layer formal model;

[0028] It is proved that the memory management operation in the design layer formal model is consistent with the corresponding memory management operation defined in the requirement layer formal model after being converted by the first mapping function.

[0029] In a possible implementation, the second refinement relationship between the implementation layer formal model and the design layer formal model is established, and the proof of the second refinement relationship is completed in the interactive theorem prover, comprising:

[0030] The second refinement relationship is established by defining a second mapping function, wherein the second mapping function is used to map a memory block structure represented by a state monad in the implementation layer formal model to a memory block data structure in the design layer formal model;

[0031] It is proved that the memory management operation of the implementation layer formal model is consistent with the corresponding memory management operation of the design layer formal model after being converted by the second mapping function.

[0032] The second aspect of the present application provides a formal verification device of a memory management module, comprising:

[0033] a source file acquisition unit, configured to acquire a requirement document, a design document and source code of a memory management module to be verified;

[0034] a formal modeling unit, configured to sequentially construct a requirement layer formal model, a design layer formal model and an implementation layer formal model in an interactive theorem prover based on the requirement document, the design document and the source code;

[0035] The requirement layer formal model is configured to formally describe, in a meta language, algorithms and data structures of memory management operations defined in the requirement document, so as to define functions of the memory management operations, the memory management operations including initialization operations, memory allocation operations and memory release operations.

[0036] The design layer formal model is configured to formally describe, in a meta language, algorithms and data structures of the memory management operations defined in the design document, so as to define functions of the memory management operations.

[0037] The implementation layer formal model is configured to formally model functions of memory management operations defined in the source code in a state monoid of the interactive theorem prover, so as to define functions of the memory management operations.

[0038] a first proving unit, configured to construct a requirement layer formal specification in the interactive theorem prover based on the requirement document, and complete proving of the requirement layer formal specification in the interactive theorem prover; the requirement layer formal specification is configured to formally describe, in a meta language, a plurality of requirement layer system properties defined in the requirement document, the requirement layer system properties including a plurality of functional correctness properties and a plurality of security properties.

[0039] a second proving unit, configured to establish a first refinement relationship between the design layer formal model and the requirement layer formal model, and complete proving of the first refinement relationship in the interactive theorem prover, so as to confirm that the design layer formal model satisfies all the requirement layer formal specifications of the requirement layer formal model.

[0040] a third proving unit, configured to establish a second refinement relationship between the implementation layer formal model and the design layer formal model, and complete proving of the second refinement relationship in the interactive theorem prover, so as to confirm that the implementation layer formal model satisfies all the requirement layer formal specifications of the design layer formal model.

[0041] The verification result determination unit is configured to determine that the memory management module passes the formal verification if the formal specification, the first refinement relationship and the second refinement relationship are all proved, and the formal specification comprises the requirement layer formal specification.

[0042] The third aspect of the present application provides a computer program product, comprising computer readable instructions, which, when executed on an electronic device, enable the electronic device to implement the formal verification method of the memory management module of the first aspect or any implementation manner of the first aspect.

[0043] The fourth aspect of the present application provides an electronic device, comprising at least one processor and a memory connected with the processor, wherein:

[0044] The memory is configured to store a computer program;

[0045] The processor is configured to execute the computer program, so that the electronic device can implement the formal verification method of the memory management module of the first aspect or any implementation manner of the first aspect.

[0046] According to the technical scheme, the formal verification method of the memory management module and the related device are provided. The requirement document, the design document and the source code of the memory management module to be verified are obtained. Based on the requirement document, the design document and the source code, the requirement layer formalization model, the design layer formalization model and the implementation layer formalization model are sequentially constructed in the interactive theorem prover. The requirement layer formalization model is used to describe the algorithm and the data structure of the memory management operation defined in the requirement document in the meta language, so as to define the function of the memory management operation, and the memory management operation includes the initialization operation, the memory allocation operation and the memory release operation. The design layer formalization model is used to describe the algorithm and the data structure of the memory management operation defined in the design document in the meta language, so as to define the function of the memory management operation. The implementation layer formalization model is used to model the function of the memory management operation defined in the source code in the state monoid of the interactive theorem prover, so as to define the function of the memory management operation. The requirement layer formalization specification is constructed in the interactive theorem prover based on the requirement document, and the proof of the requirement layer formalization specification is completed in the interactive theorem prover. The requirement layer formalization specification is used to describe the plurality of requirement layer system properties defined in the requirement document in the meta language, and the requirement layer system properties include the plurality of functional correctness properties and the plurality of security properties. The first refinement relationship between the design layer formalization model and the requirement layer formalization model is established, and the proof of the first refinement relationship is completed in the interactive theorem prover, so as to confirm that the design layer formalization model satisfies all the requirement layer formalization specifications of the requirement layer formalization model. The second refinement relationship between the implementation layer formalization model and the design layer formalization model is established, and the proof of the second refinement relationship is completed in the interactive theorem prover, so as to confirm that the implementation layer formalization model satisfies all the requirement layer formalization specifications of the design layer formalization model. If the formalization specification, the first refinement relationship and the second refinement relationship are proved, it is determined that the memory management module passes the formal verification, and the formalization specification includes the requirement layer formalization specification.

[0047] In summary, the formalization model of the requirement layer, the design layer and the implementation layer is constructed, and the refinement relationship between the layers is proved, so as to form a complete formal verification chain. The functional correctness property and the security property of the memory management operation are accurately described in the requirement layer by using the mathematical language, and the proof of the specification is completed. Then, the first and second refinement relationships are established and proved, so as to confirm that the design layer formalization model and the implementation layer formalization model satisfy all the formalization specifications of the requirement layer formalization model. In summary, the formal verification method is performed layer by layer by using the interactive theorem prover, so as to fundamentally guarantee the complete correctness of the memory management module from the requirement to the design and the code implementation. The deep logical errors and the boundary condition problems which are difficult to be found by the traditional test method are excluded in the form of mathematical proof, so as to meet the verification requirements of the memory management module in the high reliability scene. BRIEF DESCRIPTION OF DRAWINGS

[0048] The above and other features, advantages and aspects of embodiments of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings in which:

[0049] Figure 1 An architectural diagram of a formal verification system of a memory management module provided in the present application;

[0050] Figure 2 A structure diagram of a split free list provided in an embodiment of the present application;

[0051] Figure 3 A memory state diagram provided in an embodiment of the present application;

[0052] Figure 4 A flow diagram of a memory management method of a memory management module provided in an embodiment of the present application;

[0053] Figure 5 An execution flow diagram of an allocation operation provided in an embodiment of the present application;

[0054] Figure 6 An execution flow diagram of a release operation provided in an embodiment of the present application;

[0055] Figure 7 A flow diagram of a formal verification method of a memory management module provided in an embodiment of the present application;

[0056] Figure 8 A specific implementation flow of a formal verification of a memory management module provided in an embodiment of the present application;

[0057] Figure 9 A flow diagram of another formal verification method of a memory management module provided in an embodiment of the present application;

[0058] Figure 10 A structure diagram of a formal verification device of a memory management module provided in an embodiment of the present application;

[0059] Figure 11 A structure diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0060] The embodiments of the present application will be described below in detail with reference to the accompanying drawings. The terms used in the embodiment part of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application.

[0061] The embodiments of the present application are described below with reference to the accompanying drawings. Those skilled in the art can know that with the development of technology and the emergence of new scenarios, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems.

[0062] The terms "first", "second", and the like in the specification and claims of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily have to describe a specific order or sequence. It should be understood that the terms used in this way can be interchanged under appropriate circumstances, and this is only a way of distinguishing the objects with the same attributes in the description of the embodiments of the present application. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, so that the processes, methods, systems, products or equipment containing a series of units do not have to be limited to those units, but can include other units not clearly listed or inherent to these processes, methods, products or equipment.

[0063] The present application can be applied to the field of operating system security technology, and specifically applied to the memory management scenario of an operating system with high security level (referred to as a core-level operating system).

[0064] The present application can be but not limited to applied in an application program or a cloud service provided by a cloud-side server with formal verification function of a memory management module, which will be introduced as follows:

[0065] Referring to Figure 1 , Figure 1 A system architecture diagram is shown. The system can include a terminal 100 and a server 200. The server 200 can provide the method provided by the embodiments of the present application for one or more terminals.

[0066] Among them, the terminal 100 can be installed with a formal verification application program of a memory management module, and the above-mentioned application program and webpage can provide an interface. The terminal 100 can receive the related parameters input by the user on the formal verification interface of the memory management module, and send the above-mentioned parameters to the server 200. The server 200 can obtain the processing result based on the received parameters, and return the processing result to the terminal 100.

[0067] It should be understood that in some optional implementations, the terminal 100 can also complete the action of obtaining the processing result based on the received parameters by itself, without the cooperation of the server to achieve it, and the embodiments of the present application are not limited.

[0068] Next, the product form of the terminal 100 is described. Figure 1

[0069] ​The terminal 100 in the embodiments of the present application can be a mobile phone, a tablet computer, a wearable device, a vehicle-mounted device, an augmented reality (AR) / virtual reality (VR) device, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), and the like, and the embodiments of the present application do not make any limitation in this regard.

[0070] The terminal 100 can include a radio frequency unit, a memory, an input unit, a display unit, a camera (optional), an audio circuit (optional), a speaker (optional), a microphone (optional), a headset jack (optional), a processor, an external interface, a power supply, and the like. Those skilled in the art can understand that the above components are only examples and do not constitute a limitation on the terminal or the multifunctional device, and more or fewer components can be included, or some components can be combined or different components can be included.

[0071] The input unit can be used to receive inputted digital or character information, and to generate key signal input related to user settings and function control of the portable multifunctional device. Specifically, the input unit can include a touch screen (optional) and / or other input devices. Specifically, the other input devices can include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, on / off buttons, and the like), trackballs, mice, joysticks, and the like.

[0072] The input device can receive inputted data and the like.

[0073] The display unit can be used to display information inputted by the user or information provided to the user, various menus of the terminal, interactive interfaces, file display, and / or playing of any kind of multimedia files. In the embodiments of the present application, the display unit can be used to display interfaces of the formal verification of the memory management module, processing results, and the like.

[0074] The memory can be used to store software codes related to the formal verification method of the memory management module, and the processor can execute the steps of the formal verification method of the memory management module, and can also schedule other units (such as the input unit and the display unit) to realize corresponding functions.

[0075] The radio frequency unit (optional) can be used to receive and send signals in the process of receiving or transmitting information or calls.

[0076] In the embodiments of the present application, the radio frequency unit can send data to the server 200 and receive processing results sent by the server 200.

[0077] It should be understood that the radio frequency unit is optional, which can be replaced by other communication interfaces, for example, can be a network interface.

[0078] The terminal 100 further includes a power supply (such as a battery) for powering various components.

[0079] The terminal 100 further includes an external interface, which can be a standard Micro USB interface, or a multi-pin connector, and can be used to connect the terminal 100 to other devices for communication, or to connect a charger to charge the terminal 100.

[0080] The server 200 includes a bus, a processor, a communication interface, and a memory. The processor, the memory, and the communication interface communicate through the bus.

[0081] The memory can be used to store software code related to the formal verification method of the memory management module of the chip, and the processor can execute the steps of the formal verification method of the memory management module of the chip, or can schedule other units to realize the corresponding functions.

[0082] In a high-reliability scenario, to meet the requirements of an embedded system, in addition to providing allocation and recycling of basic memory management mechanisms, the memory management module of the operating system also considers real-time issues. For example, a kernel-level operating system is a special operating system constructed for computer systems that undertake safety-critical tasks in nuclear power plants and other nuclear facilities (such as nuclear-powered ships and research reactors). The formal verification method of the traditional memory management module mainly relies on testing techniques to verify whether the memory management module meets the determinacy requirements of the kernel-level software, which mainly includes the safety and correctness of memory operations.

[0083] However, the traditional memory allocation module is called by other modules at a high frequency, and the memory management algorithm needs to quickly find a suitable memory block in the memory pool. Therefore, the memory management module usually uses a relatively complex data structure. The search for free memory blocks is affected by previous memory operations (allocation and release), and the state space is large. In a nuclear power instrumentation and control system, the memory management module also needs to consider real-time, limited space, and various boundary conditions.

[0084] Based on the above reasons, the traditional testing technique relies on empirical programming and lacks mathematical rigor, making it difficult to verify the correctness of memory operations. The state machine generated by the memory management is extremely large and cannot be completely traversed, leading to insufficient verification and making it difficult to find deep errors such as memory leaks, address conflicts, and access out-of-bounds. For example, it is difficult to complete the traversal of the state space of the memory management module. For example, when executing N memory allocation operations, the memory state is theoretically As the memory module is used multiple times, traversing the entire state space becomes nearly impossible. This demonstrates that existing formal verification methods for memory management modules suffer from insufficient verification.

[0085] To address the aforementioned issues, this application provides a formal verification method for a memory management module. This method uses theorem-based formal verification techniques to cover the entire memory state space, thereby improving verification sufficiency. The formal verification method for the memory management module of this application will be described in detail below with reference to the accompanying drawings.

[0086] Reference Figure 2 , Figure 2 This is a schematic diagram of a separate free list provided in an embodiment of this application, as shown below. Figure 2 As shown, the memory management module divides the nodes in the free list into three levels according to a three-level memory management algorithm. The first level includes 65 first-level nodes with index numbers 1 to 64. The memory base value corresponding to the first-level node with index number n (n∈[1, 64]) is 8 + 8(n-1) bytes. That is, the first level includes 64 first-level nodes with memory base values ​​of 8 to 512 bytes. Starting from 8 bytes, the memory base value of each first-level node increases by 8 bytes. The second level includes 321 second-level nodes with index numbers 64 to 256. The memory base value corresponding to the second-level node with index number m (m∈[64, 256]) is 576 + 64 × (m-65) bytes. That is, the second level includes 321 second-level nodes with memory base values ​​of 576 to 12800 bytes. Starting from 256 bytes, the memory base value of each second-level node increases by 64 bytes. The third level includes 64 third-level nodes with index numbers from 257 to 320. The memory base value of the third-level node with index number k (k∈[257,320]) is 13824 + 1024 × (k - 257) bytes. That is, the second level includes 64 third-level nodes with sizes from 13824 to 78336 bytes. Starting from 13824 bytes, the memory base value of each third-level node increases by 1024 bytes.

[0087] In this embodiment, each node in the memory space is attached to a doubly linked list consisting of free memory blocks, and a bitmap is used in the heap control structure to record the free memory blocks.

[0088] In this embodiment, the size of the free memory block in the doubly linked list attached to any target node is within the target byte range corresponding to the target node. The minimum value of the target byte range corresponding to the target node is the memory baseline value of the target node, and the maximum value is the memory baseline value of the next adjacent node of the target node minus 1.

[0089] Specifically, the target byte range of the first level node with index number 1 is 0~15, i.e. the free memory block with the size of 1~15 in the heap is hung on the node with index number 1. The target byte range of the target third level node with index number k=320 is not less than 78336, i.e. the free memory block with the size ≥78336 in the heap is hung on the node with index number 320. When the index number is not equal to 1 or 15, the minimum value of the byte range is the memory reference value of the target node, and the maximum value is the memory reference value of the next adjacent node minus 1, as shown in the following table. Figure 2 As shown in the table, the free memory block with the size of 16~23 in the heap is hung on the node with index number 2, and the free memory block with the size of 24~31 in the heap is hung on the node with index number 3.

[0090] In the embodiment, the memory pool of the operating system is composed of a base address and a length, which can be represented by a natural number list {base, (base+1)……(base+length)} in mathematics. When a user applies for a memory with a target memory size, the memory management component will select the unused memory with the target memory size for the user, which can be represented in mathematics as a set of natural numbers starting from M to (M+size) for the user, and the set of natural numbers is marked as used. Correspondingly, when the user releases the memory, it can be represented in mathematics as marking the set of natural numbers starting from M to (M+size) as unused. When the user queries the memory usage, it is to check the state of the natural number list.

[0091] Based on this, the running of the memory management module is simulated by using a state machine, and initialization, allocation and release are three types of events of the state machine, Figure 3 A memory state diagram provided by the embodiment of the application is shown in the following table. Figure 3 As shown in the table, the memory pool state is S0, the initialization init(base, size) function is executed to implement initialization, the memory pool state after the initialization is Sinit, the allocation function malloc(size) is executed to implement one-time memory allocation, specifically, malloc(n) searches the continuous free memory with the size at least size in the memory, and returns the memory block to the user, and sets the memory block as used. After the execution of malloc(size), the memory pool state is Sm1, after the execution of malloc(size) again, the memory pool state is Sm2, and after the execution of the malloc(size) function for multiple times, the memory pool state is the first set {Sm1, Sm2……}. Correspondingly, the release function free(P) is executed to implement one-time release, and after the execution of the release function free(P) for multiple times, the memory pool state is the second set {Sf1, Sf2……}.

[0092] See Figure 4 , Figure 4 This application provides a flowchart illustrating a memory management method for a memory management module, as shown in the embodiments below. Figure 4 As shown, this method specifically includes:

[0093] S401. Determine the memory state model and data structure.

[0094] In this embodiment, the memory management module is used to manage free memory blocks. When a user requests memory, the memory management module will allocate a suitable free memory block to the user and mark it as Uesd. In terms of logical memory, the free memory blocks in the memory pool consist of M sets of memory block lists, and each list consists of multiple memory blocks of a specified size range. Figure 4 This is a schematic diagram of a memory data structure provided in an embodiment of this application, such as... Figure 4 As shown, in terms of physical memory, the starting address of the memory pool is PoolStart, which is BaseAddress, and its size is Size. The memory pool consists of several memory blocks. The data structure representing a memory block includes the base address of the memory block, the size of the memory block, the status of the memory block (Used / Idle), and the size of the physically adjacent preceding memory block.

[0095] Specifically, the memory blocks used can be represented as a list in isabelle, which is "block_t list". Each group of free memory blocks within a specified size range can also be represented as "block_t list". For example, the maximum M free lists in the operating system memory pool can be represented as "(block_t list) list". In addition, to quickly find free memory blocks, a Bitmap: "bool list" is used to locate whether a free memory block exists in a certain group of free memory block lists.

[0096] It should be noted that err_num represents the fault code during allocation or reclamation, and init_flag indicates whether the memory pool has been initialized.

[0097] S402. Based on the allocation function, determine the allocation operation process.

[0098] In this embodiment, after a user requests a memory block of size Size, the system searches the free list for a contiguous region greater than or equal to the requested memory size, based on the requested memory and the current memory state. If such a region exists, the system returns the starting address of that region; otherwise, it returns NONE.

[0099] Figure 5 This is a schematic diagram of the execution flow of an allocation operation provided in an embodiment of this application, such as... Figure 5As shown, the allocation function execution method provided by the embodiment of the present application comprises:

[0100] S501, starting to execute a memory allocation process: the process starts from the entry of a memory allocation function (malloc).

[0101] S502, checking the legality of input parameters: the system first checks the validity of the request parameters passed in by the caller, for example, checking whether the requested memory size is a reasonable positive value.

[0102] S503, adjusting the memory size requested by the user: according to the predefined memory alignment rules and management data structure overhead, the size (req_size) of the user's initial request is adjusted and rounded up to calculate the actual size (final_size) of the memory block that needs to be found internally.

[0103] S504, finding a suitable memory block in the free list: the system finds and locates the first smallest free memory block (block) that meets the conditions in the list of all free memory blocks greater than or equal to the final size (final_size) according to the "first fit" principle.

[0104] S505, judging whether the memory block is successfully found: the result of the search operation is judged to confirm whether there is a free memory block that meets the requirements.

[0105] S506, returning an error code: if it is judged that no suitable memory block is found, the allocation process is terminated, and an error code indicating that there is not enough memory or the allocation fails is returned to the caller.

[0106] S507, calculating the remaining space of the candidate memory block: for the candidate memory block (x8bk) found, the difference between its total size and the required final size (final_size) is calculated.

[0107] S508, judging whether the remaining space is greater than the minimum memory block: the difference calculated in S507 is compared with the minimum memory block size specified by the system to determine whether the remaining space is sufficient to be divided into an independent new memory block.

[0108] S509, cutting the memory block and creating a new free block: if the remaining space is greater than the minimum memory block, the candidate memory block is cut into two parts. One part is exactly final_size and is marked as a to-be-allocated block (used_blk_temp). The remaining part is registered as a new, smaller free memory block and is put back into the corresponding free management list.

[0109] S510, mark the whole memory block as to be allocated: if the remaining space is not greater than the minimum memory block, i.e. the remaining space is not enough for effective segmentation, the memory block is not cut, but the whole memory block is directly marked as a to-be-allocated block (used_blk_temp).

[0110] S511, check the alignment of the to-be-allocated block address: the actual starting address (base - head) of the to-be-allocated block (used_blk_temp) is calculated, and it is checked whether the address meets the requirement of 64-byte alignment.

[0111] S512, allocate the whole block due to unaligned address: if the step address cannot be divided by 64, in order to meet the strict alignment requirement, the system gives up the cutting strategy and decides to allocate the whole original memory block to the user, even if it will cause partial internal fragmentation.

[0112] S513, calculate the memory size cut for meeting the alignment: if the address is aligned or after the whole allocation is completed, the difference between the current size of the to-be-allocated block and the target reference value is evaluated.

[0113] In this embodiment, the target reference value is the maximum value of the request size adjusted according to 8-byte alignment and the fixed header length, plus the memory management header size.

[0114] S514, judge whether the difference contains multiple minimum memory blocks: judge whether the difference is greater than or equal to the size of multiple system minimum memory blocks.

[0115] S515, perform alignment cutting and allocate the front part to the user: if the difference contains multiple minimum memory blocks, perform an accurate cutting once, allocate the front part (the part meeting the specific alignment and size requirements) of the memory block to the user, and the remaining tail part is recycled as a new free block to the management system.

[0116] S516, the process ends: after completing all the above steps, whether in the cutting way or the whole allocation way, the core process of memory allocation ends, and the system will perform subsequent return address and other finishing work.

[0117] S403, based on the release function, determine the process of the release operation.

[0118] After the user gives the OS the first address of the to-be-recycled memory block, the memory management module checks whether the address is valid, and if it is valid, modifies the state of the memory block to free, checks whether the front and rear memory blocks are free memory blocks, and according to the free state of the front and rear blocks, if there are free blocks, merges the memory blocks and ends the function, otherwise, sets the state of the memory block to Idle.

[0119] Figure 6An execution flow diagram of a release operation provided by an embodiment of the present application is shown in Figure 6 A release function execution method provided by an embodiment of the present application includes:

[0120] S601, start executing the memory release flow: the flow starts from the entry of a memory release function (free).

[0121] S602, find the target memory block in the used block list: the system performs a traversal search in the used memory block list of the entire memory pool according to the first address of the memory to be released input by the caller, and confirms whether there is a memory block whose recorded first address completely matches the input address.

[0122] S603, judge whether the target memory block is successfully found: the result of the search operation is judged to confirm whether the input address points to a valid memory block that is in the used state.

[0123] S604, keep the memory state unchanged and return: if it is judged in S603 that the target memory block is not found, that is, the input address is invalid or the memory block is not in the used state, the system terminates the release flow, keeps the memory state unchanged, and usually returns an error indication.

[0124] S605, locate the adjacent front and rear memory blocks: if it is judged in S603 that the target memory block (BLK) is successfully found, the system then searches for the front memory block (prev_block) and the rear memory block (next_block) adjacent to the physical address of the BLK according to the memory layout information.

[0125] S606, judge whether the front block is idle and the rear block is used: the system checks the state of the adjacent memory blocks. If the scenario is that the state of the front memory block (prev_block) is idle (Idle) and the state of the rear memory block (next_block) is used (Used), S607 is executed.

[0126] S607, merge with the idle front memory block: in this scenario, the BLK to be released is merged with the idle prev_block in front of it into a larger idle memory block. The size and state of the new memory block after merging are updated, and the memory management data structure (such as the free list) is also updated synchronously.

[0127] S608, judge whether the rear block is idle and the front block is used: the system checks the state of the adjacent memory blocks. If the scenario is that the state of the rear memory block (next_block) is idle (Idle) and the state of the front memory block (prev_block) is used (Used), S609 is executed.

[0128] S609, merging with the next block of free memory: in this scenario, the current BLK to be released is merged with its next block of free memory next_block into a larger block of free memory. The size and state of the new memory block after merging are updated, and the memory management data structure is updated synchronously.

[0129] S610, judging whether the two adjacent blocks are both free: the system checks the state of the adjacent memory blocks. If the scenario is that the state of the previous block of memory (prev_block) and the next block of memory (next_block) are both free (Idle), step 11 is performed.

[0130] S611, merging with the two adjacent blocks of free memory: in this scenario, the current BLK to be released, the previous block of free memory prev_block and the next block of free memory next_block are merged into a continuous and larger block of free memory. The size and state of the new memory block after merging are updated, and the memory management data structure is updated synchronously.

[0131] S612, judging whether the two adjacent blocks are both used: the system checks the state of the adjacent memory blocks. If the scenario is that the state of the previous block of memory (prev_block) and the next block of memory (next_block) are both used (Used), S613 is performed.

[0132] S613, not performing merging and directly releasing the target block: in this scenario, since the adjacent memory blocks are both used, merging cannot be performed. The system directly modifies the state of the target memory block BLK from "used (Used)" to "free (Idle)", and inserts it into the corresponding free management list, and updates the memory state.

[0133] S614, the end of the process: after any of the above merging operations or separate release operations is completed, the core process of memory release ends.

[0134] Reference Figure 7 , Figure 7 A flowchart of a formal verification method of a memory management module provided by an embodiment of the present application is shown in FIG. 1, and the method specifically includes the following steps. Figure 7

[0135] S701, obtaining the requirement document, design document and source code of the memory management module to be verified.

[0136] In this embodiment, the requirement document clearly specifies the high-level goals that the memory management module should achieve, such as core requirements such as functional correctness and no memory leakage. The design document describes the specific algorithms, architectures and data structures used to achieve the above requirements, and is a bridge connecting the requirements and the code. The source code is the specific implementation code of the memory management module.​

[0137] S702, based on the requirement document, the design document and the source code, in the interactive theorem prover, in turn, build the requirement layer formalization model, the design layer formalization model and the implementation layer formalization model.

[0138] In this embodiment, based on the requirement document, the requirement layer formalization model is modeled in the interactive theorem prover Isabelle, based on the design document, the design layer formalization model is modeled in the interactive theorem prover Isabelle, and based on the source code, the implementation layer formalization model is modeled.

[0139] In this embodiment, the requirement layer formalization model is used to formally describe the algorithm and data structure of the memory management operation defined in the requirement document in the meta language, to define the function of the memory management operation.

[0140] In this embodiment, the design layer formalization model is used to formally describe the algorithm and data structure of the memory management operation defined in the design document in the meta language, to define the function of the memory management operation.

[0141] In this embodiment, the implementation layer formalization model is used to formally model the function of the memory management operation defined in the source code in the state monoid of the interactive theorem prover, to define the function of the memory management operation.

[0142] S703, based on the requirement document, build the requirement layer formalization specification in the interactive theorem prover, and complete the proof of the requirement layer formalization specification in the interactive theorem prover.

[0143] In this embodiment, the requirement layer formalization specification is used to formally describe a plurality of requirement layer system properties defined in the requirement document in the meta language, and the requirement layer system properties include a plurality of functional correctness properties and a plurality of security properties.

[0144] S704, establish the first refinement relationship between the design layer formalization model and the requirement layer formalization model, and complete the proof of the first refinement relationship in the interactive theorem prover, to confirm that the design layer formalization model meets all the requirement layer formalization specifications of the requirement layer formalization model.

[0145] S705, establish the second refinement relationship between the implementation layer formalization model and the design layer formalization model, and complete the proof of the second refinement relationship in the interactive theorem prover, to confirm that the implementation layer formalization model meets all the requirement layer formalization specifications of the design layer formalization model.

[0146] S706, if the formalization specification, the first refinement relationship and the second refinement relationship are proved, it is determined that the memory management module passes the formal verification.

[0147] In this embodiment, the formal specification includes a requirement layer formal specification.

[0148] As can be seen from the technical solution, the formal verification method of the memory management module provided in the embodiment of the application forms a complete formal verification chain by constructing formal models of three levels of requirement layer, design layer and implementation layer, and establishing a refinement relationship proof between layers. The method first accurately describes the functional correctness properties and security properties of the memory management operation in the requirement layer using mathematical language, and completes the proof of the specification, and then establishes and proves the first and second refinement relationships to confirm that the formal model of the design layer and the formal model of the implementation layer both satisfy all formal specifications of the formal model of the requirement layer. In summary, the scheme performs the formal verification method of layer-by-layer progression through the interactive theorem prover, fundamentally guarantees the complete correctness of the memory management module from the requirement to the design and then to the code implementation, and excludes deep logical errors and boundary condition problems that are difficult to find by traditional testing methods in a mathematical proof manner, thereby meeting the verification requirements of the memory management module in a high-reliability scenario.

[0149] Reference Figure 8 , Figure 8 The specific implementation process of the formal verification of the memory management module provided in the embodiment of the application is shown in FIG. 8, and the method specifically includes the following steps. Figure 8

[0150] S801, acquire the requirement document, design document and source code of the memory management module to be verified.

[0151] S802, based on the requirement document, design document and source code, sequentially construct the formal model of the requirement layer, formal model of the design layer and formal model of the implementation layer in the interactive theorem prover.

[0152] In an optional embodiment, the memory management algorithm defined in the design document is converted into the control logic in the formal model of the design layer. The memory management algorithm includes the logic of the initialization operation, the logic of the memory allocation operation and the logic of the memory release operation. The data structure defined in the design document is converted into the mathematical model in the formal model of the design layer. The data structure includes a structure body for representing a memory block, a doubly linked list array for organizing free memory blocks, and a bitmap for fast lookup.

[0153] In an optional embodiment, the memory management function defined in the source code in C language is converted into the equivalent pure functional specification for operating the memory state in the formal model of the implementation layer using the state monad of the interactive theorem prover.

[0154] S803, based on the requirement document, construct the formal specification of the requirement layer in the interactive theorem prover. ​

[0155] In this embodiment, the requirement layer formalization specification is used to formally describe the plurality of requirement layer system properties defined in the requirement document in a meta language, and the requirement layer system properties include a plurality of functional correctness properties and a plurality of security properties.

[0156] In this embodiment, based on the requirement document, a specific method of constructing the requirement layer formalization specification in the interactive theorem prover includes:

[0157] A1, in the interactive theorem prover, each functional correctness property defined in the requirement document is formally described in a meta language, and a functional correctness specification for each memory management operation is obtained, and the plurality of functional correctness properties include the correctness properties of the functions of each memory management operation.

[0158] Specifically, the functional correctness properties include the correctness properties of the allocation function and the correctness properties of the release function. When there is free memory greater than 8 bytes in the memory pool that has been initialized, and the memory requested by the user is greater than zero, the memory allocation function should be able to return a piece of memory to the user.

[0159] Wherein, the correctness properties of the allocation function include:

[0160] a1: the return value of the allocation function is OK.

[0161] a2: the memory block return address can be divided by 64.

[0162] a3: the number of used memory blocks after allocation is one more than that before allocation.

[0163] a4: the sum of the sizes of the used memory blocks after allocation is the sum of the sizes of the used memory blocks before allocation and the size of the memory block allocated this time.

[0164] Wherein, the correctness properties of the release function include:

[0165] b1: the return value of the release function is OK.

[0166] b2: the memory block to be released is in the allocated memory block.

[0167] b3: the number of used memory blocks after release is one less than that before release.

[0168] b4: the sum of the sizes of the used memory blocks after release is the difference between the sum of the sizes of the used memory blocks before release and the size of the memory block released this time.

[0169] A2. Formalize the security properties defined in the requirement document in the meta-language in the interactive theorem prover, and obtain the security specification of each memory management operation.

[0170] In this embodiment, the security properties include memory total conservation, memory block non-overlapping and non-repeated release.

[0171] In this embodiment, the security properties include:

[0172] c1: After the memory pool is successfully initialized, the total amount of memory managed by the system remains unchanged regardless of how the memory is allocated or released, and is consistent with the size of the memory pool at initialization, so there is no memory leakage or damage.

[0173] c2: After the memory pool is successfully initialized, the memory blocks managed by the system are always non-overlapping regardless of how the memory is allocated or released, so there is no data damage or undefined behavior caused by a memory block being allocated to multiple users.

[0174] c3: After the memory pool is successfully initialized, the memory blocks managed by the system are always larger than the minimum memory block regardless of how the memory is allocated or released, so there is no memory fragmentation.

[0175] c4: After the memory pool is successfully initialized, the memory blocks managed by the system have a unique identifier regardless of how the memory is allocated or released, so there is no "double free" (the same address is freed twice) or "allocate already allocated memory" (i.e., allocate an already used address) error.

[0176] c5: After the memory pool is successfully initialized, the memory blocks managed by the system have a unique identifier regardless of how the memory is allocated or released, so there is no "double free" (the same address is freed twice) or "allocate already allocated memory" (i.e., allocate an already used address) error.

[0177] c6: After the memory pool is successfully initialized, the memory blocks managed by the system are within the specified range regardless of how the memory is allocated or released, so the memory allocation speed is O(1) and the execution time of the allocation or release function is deterministic.

[0178] S804. Complete the proof of the requirement layer formal specification in the interactive theorem prover.

[0179] S805. Establish a first refinement relationship between the design layer formal model and the requirement layer formal model.

[0180] In this embodiment, the first refinement relationship is established by defining a first mapping function, which is used to map the memory block structure in the design layer formal model to the memory block representation in the requirement layer formal model.

[0181] S806, complete the proof of the first refinement relationship in the interactive theorem prover to confirm that the design layer formalization model meets all the requirement layer formalization specifications of the requirement layer formalization model.

[0182] In this embodiment, it is proved that the behavior of the memory management operation in the design layer formalization model is consistent with the corresponding memory management operation defined in the requirement layer formalization model after being converted by the first mapping function.

[0183] In this embodiment, after the formalization specifications of the requirement stage are defined, if the design stage meets the consistency with the requirement stage, then the design model can be considered to meet the formalization specifications. The requirement model mainly describes the external behavior of the function / module, and the design model focuses on the internal implementation on the basis of the requirement while keeping the external behavior unchanged. Therefore, the condition for the design layer formalization model to meet the requirement layer is that the three key attributes of the memory block in the design layer formalization model should be consistent with the requirement layer formalization model.

[0184] Specifically, a first mapping function named block_map is defined, and the function of the first mapping function is to convert a design layer memory block representation into a requirement layer memory block representation. The specific conversion rules are as follows:

[0185] The "base address" of the requirement layer memory block is directly taken from the "base address" of the design layer memory block.

[0186] The "size" of the requirement layer memory block is directly taken from the "size" of the design layer memory block.

[0187] The "state" of the requirement layer memory block is directly taken from the "state" of the design layer memory block.

[0188] S807, based on the requirement document, build the design layer formalization specification in the interactive theorem prover.

[0189] In this embodiment, the design layer formalization specification is used to formally describe the multiple design layer system attributes defined in the design document in the meta language. The design layer system attributes include system attributes different from the requirement layer system attributes.

[0190] S808, complete the proof of the design layer formalization specification in the interactive theorem prover.

[0191] S809, establish a second refinement relationship between the implementation layer formalization model and the design layer formalization model.

[0192] In this embodiment, a second refinement relationship is established by defining a second mapping function, wherein the second mapping function is used to map the memory block structure represented by the state monad in the implementation layer formal model to the memory block data structure in the design layer formal model.

[0193] S810, in the interactive theorem prover, the proof of the second refinement relationship is completed to confirm that the implementation layer formal model meets all the requirement layer formal specifications of the design layer formal model.

[0194] In this embodiment, it is proved that the execution effect of the memory management operation represented by the state monad in the implementation layer formal model is consistent with the execution effect of the corresponding mathematical model in the design layer formal model after conversion by the second mapping function.

[0195] In this embodiment, after the algorithm and data structure of the memory management module are described in the design layer formal model, the implementation method needs to be modeled, and the implementation method (i.e., C language) is modeled using the state monad. The implementation layer code formal model needs to meet the conditions of the design layer, that is, the four key attributes of the memory block in the code layer should be consistent with the design layer.

[0196] Specifically, a second mapping function named block_map is defined, and the function of the second mapping function is to convert an implementation layer memory block representation into a design layer memory block representation, and the specific conversion rule is as follows:

[0197] The "base address" of the design layer memory block is directly taken from the "base address" of the implementation layer memory block.

[0198] The "size" of the design layer memory block is directly taken from the "size" of the implementation layer memory block.

[0199] The "state" of the design layer memory block is directly taken from the "state" of the implementation layer memory block.

[0200] The "previous memory block size" of the design layer memory block is directly taken from the "previous memory block size" of the implementation layer memory block.

[0201] In summary, the second mapping function accurately corresponds the memory block structure represented by the state monad in the implementation layer to the memory block data structure defined in the design layer by directly copying the four key attributes of "base address", "size", "state" and "previous memory block size".

[0202] S811, based on the source code, the implementation layer formal specification is constructed in the interactive theorem prover.

[0203] In this embodiment, the implementation layer formal specification is used to describe the multiple implementation layer system properties defined in the source code in the form of state monoids, and the implementation layer system properties include system properties different from the requirement layer system properties.

[0204] S812, proving the implementation layer formal specification in the interactive theorem prover is completed.

[0205] S813, if the requirement layer formal specification, the design layer formal specification and the implementation layer formal specification, the first refinement relationship and the second refinement relationship are all proved, it is determined that the memory management module passes the formal verification.

[0206] That is, the formal specification further includes the design layer formal specification and the implementation layer formal specification.

[0207] As can be seen from the above technical solution, the formal verification method of the memory management module provided by the embodiment of the present application is implemented by modeling based on the interactive theorem prover, that is, a three-layer formal model, a three-layer formal specification, a first refinement relationship and a second refinement relationship are constructed in the interactive theorem prover, and the proof is implemented based on the interactive theorem prover, that is, the three-layer formal specification, the first refinement relationship and the second refinement relationship are proved, a complete verification chain from the requirement to the code is established, not only the property consistency within each abstraction level is ensured, but also the correct transmission between levels is ensured through the refinement relationship, and finally the complete correctness of the memory management module is ensured in the form of mathematical proof.

[0208] In summary, Figure 9 The flowchart of another formal verification method of the memory management module provided by the embodiment of the present application is shown in FIG. 5, and the method specifically includes the following steps. Figure 9

[0209] In the requirement layer, first, the functional requirements of the memory management module described in natural language are converted into the requirement layer formal model described in the Isabelle meta language. Secondly, the judgment criteria met by the functional requirements are converted into the functional correctness, and the safety invariants are extracted in combination with the data structure and standard requirements in the isabelle model. Finally, it is proved in the isabelle whether the requirement model meets the correctness and safety invariants, that is, the correctness and safety invariants are constructed based on the requirement layer system specification.

[0210] As Figure 9 ​As shown, the verification process begins with a requirements document (function + expected results) written in natural language. First, the functional requirements described in this document are converted into a formalized requirement-layer model described in the Isabelle meta-language. Second, the criteria for satisfying the functional requirements are formalized as functional correctness attributes, and safety invariants are extracted by combining the data structure and standard requirements in the model. Finally, it is proven in Isabelle whether the requirement model satisfies these correctness and safety invariants constructed based on the requirement-layer system specifications, thus completing the verification of "functional correctness and safety based on arbitrary variables in Isabelle".

[0211] At the design layer, based on the design document, the algorithm and data structure are first converted into a design model described by the Isabelle meta-language. Next, the safety invariants of the design layer are extracted by combining the data structure and algorithm, and their refined relationship with the requirements layer is described. Finally, in Isabelle, it is proven whether the design model satisfies consistency with the requirements and the safety invariants of the design layer, that is, the safety invariants constructed based on the system specifications of the design layer.

[0212] like Figure 9 As shown, the input for design-layer verification is the design document (data structure + algorithm). First, the algorithms and data structures described therein are converted into design models described in the Isabelle meta-language. Second, considering the complexity of the specific algorithms and data structures introduced in the design layer, safety invariants of the design layer are extracted, and their refinement relationships with the requirements layer are described. Finally, in Isabelle, it is proven whether the design model satisfies consistency with the requirements (i.e., refinement relationships) and the design-layer safety invariants. This constitutes the "consistency verification of arbitrary variable types based on Isabelle".

[0213] At the implementation layer, the source code (C language) is transformed into a formal implementation model in Isabelle using the state monstrances provided in Isabelle. Next, the implementation layer's safety invariants are extracted by combining the data structures of the implementation layer, and their refined relationship with the design layer is described. Finally, Isabelle proves whether the implementation model satisfies consistency with the design and the implementation layer's safety invariants, i.e., the safety invariants constructed based on the implementation layer system specifications.

[0214] like Figure 9As shown, the implementation layer verification basis is source code (C language). The source code is converted into an implementation layer formal model by using the Simpl state monad provided in Isabelle. Secondly, the corresponding security invariants are extracted at the implementation layer according to the complexity of the specific algorithms and data structures introduced at the design layer, and the refinement relationship with the design layer is described. Finally, it is proved in Isabelle whether the implementation model meets the consistency with the design and the implementation layer security invariants, and this process completes the verification of the consistency with the design layer based on the Simpl state monad.

[0215] The present scheme is based on the isabelle interactive formalization tool, and establishes a formal model of a first-fit memory management algorithm based on three-level memory management, proposes a formal specification in combination with the determinacy requirement of the kernel-level operating system, and completes the proof in isabelle to confirm that the memory management module meets the determinacy requirement of the kernel-level operating system and solves the problem of incomplete verification of the traditional verification method.

[0216] The formal verification method of the memory management module provided in the embodiments of the present application is introduced above, and the device for executing the formal verification method of the memory management module will be introduced below.

[0217] Please refer to Figure 10 , Figure 10 The formal verification device of the memory management module provided in the embodiments of the present application is shown in FIG. 1. As shown in FIG. 1, the formal verification device 1000 of the memory management module comprises: Figure 10

[0218] A source file acquisition unit 1001 is configured to acquire the requirement document, the design document and the source code of the memory management module to be verified.

[0219] A formal modeling unit 1002 is configured to sequentially construct a requirement layer formal model, a design layer formal model and an implementation layer formal model in an interactive theorem prover based on the requirement document, the design document and the source code.

[0220] The requirement layer formal model is configured to formally describe the algorithm and the data structure of the memory management operation defined in the requirement document in a meta language to define the function of the memory management operation, wherein the memory management operation comprises an initialization operation, a memory allocation operation and a memory release operation.

[0221] The design layer formal model is configured to formally describe the algorithm and the data structure of the memory management operation defined in the design document in a meta language to define the function of the memory management operation.

[0222] ​The implementation layer formalization model is used to model functions of memory management operations defined in the source code in a state monoid of the interactive theorem prover, so as to define functions of the memory management operations;

[0223] The first proving unit 1003 is configured to construct a requirement layer formalization specification in the interactive theorem prover based on the requirement document, and complete proving of the requirement layer formalization specification in the interactive theorem prover; the requirement layer formalization specification is used to describe a plurality of requirement layer system properties defined in the requirement document in a meta language, and the requirement layer system properties include a plurality of functional correctness properties and a plurality of security properties.

[0224] The second proving unit 1004 is configured to establish a first refinement relationship between the design layer formalization model and the requirement layer formalization model, and complete proving of the first refinement relationship in the interactive theorem prover, so as to confirm that the design layer formalization model satisfies all the requirement layer formalization specifications of the requirement layer formalization model.

[0225] The third proving unit 1005 is configured to establish a second refinement relationship between the implementation layer formalization model and the design layer formalization model, and complete proving of the second refinement relationship in the interactive theorem prover, so as to confirm that the implementation layer formalization model satisfies all the requirement layer formalization specifications of the design layer formalization model.

[0226] The verification result judging unit 1006 is configured to judge that the memory management module passes formalization verification if the formalization specification, the first refinement relationship and the second refinement relationship are all proved, and the formalization specification includes the requirement layer formalization specification.

[0227] It should be noted that the specific implementation method of any functional unit can refer to the above-mentioned various embodiments.

[0228] In the embodiments of the present application, an electronic device is further provided. Referring to Figure 11 As shown in the figure, a structure schematic diagram suitable for implementing the electronic device in the embodiments of the present application is shown. The electronic device in the embodiments of the present application can include but is not limited to fixed terminals such as mobile phones, notebook computers, PDAs (personal digital assistants), PADs (tablet computers), desktop computers and the like. Figure 11 The electronic device shown is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0229] As Figure 11As shown, the electronic device can include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 1101 that can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 1102 or loaded into a random access memory (RAM) 1103 from a storage device 1108. In a state in which the electronic device is powered on, various programs and data required for operation of the electronic device are also stored in the RAM 1103. The processing device 1101, the ROM 1102, and the RAM 1103 are connected to each other through a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

[0230] Generally, the following devices can be connected to the I / O interface 1105: input devices 1106 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; output devices 1107 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1108 including, for example, a memory card, a hard disk, etc.; and communication devices 1109. The communication devices 1109 can allow the electronic device to communicate wirelessly or through a wire with other devices to exchange data. Although Figure 11 An electronic device having various devices is shown, but it should be understood that all of the shown devices are not required to implement or have the electronic device. More or fewer devices can alternatively be implemented or have.

[0231] The embodiment of the present application also provides a computer program product including computer readable instructions, when the computer readable instructions are executed on an electronic device, the electronic device implements the formal verification method of any one of the memory management modules provided by the embodiment of the present application.

[0232] The embodiment of the present application also provides a computer readable storage medium, the storage medium carries one or more computer programs, when the one or more computer programs are executed by an electronic device, the electronic device can implement the formal verification method of any one of the memory management modules provided by the embodiment of the present application.

[0233] In addition, it should be noted that the above-described device embodiments are only schematic, wherein the units shown as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment. In addition, the connection relationship between the modules in the device embodiment provided by the present application indicates that there is a communication connection between them, which can be implemented as one or more communication buses or signal lines.

[0234] Those skilled in the art can clearly understand that the application can be implemented by means of software plus necessary universal hardware, and of course can also be implemented by means of dedicated hardware including special integrated circuit, special CPU, special memory, special component, etc. Generally, any function completed by computer program can be easily implemented by corresponding hardware, and the specific hardware structure for implementing the same function can also be various, such as analog circuit, digital circuit or special circuit, etc. However, for the application, software program implementation is a better embodiment. Based on such understanding, the technical solution of the application or the part of the application which makes contribution to the prior art can be embodied in the form of software product, which is stored in readable storage medium, such as computer floppy disk, U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk, etc., and includes a plurality of instructions for making a computer device (which can be personal computer, training device or network device, etc.) execute the method described in various embodiments of the application.

[0235] In the above embodiments, the implementation can be achieved by software, hardware, firmware or any combination thereof, entirely or partially. When implemented by software, the implementation can be achieved in the form of a computer program product, entirely or partially.

[0236] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the flow or function described in the embodiments of the application is generated entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another, for example, the computer instructions can be transmitted from one website, computer, training device or data center to another website, computer, training device or data center through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that can be stored by a computer or a data storage device such as a training device, a data center, etc. integrated with one or more available media sets. The available medium can be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (SSD)), etc.

Claims

1. A formal verification method for a memory management module, characterized in that, include: Obtain the requirements document, design document, and source code of the memory management module to be verified; Based on the requirements document, the design document, and the source code, a formal model of the requirements layer, a formal model of the design layer, and a formal model of the implementation layer are constructed sequentially in the interactive theorem prover. The formal model of the requirements layer is used to formally describe the algorithms and data structures of the memory management operations defined in the requirements document in a meta-language, so as to define the functions of the memory management operations, including initialization operations, memory allocation operations and memory release operations. The formal model of the design layer is used to formally describe the algorithms and data structures of the memory management operations defined in the design document in a meta-language, so as to define the functionality of the memory management operations; The implementation layer formal model is used to formally model the functions of memory management operations defined in the source code using the state monads of the interactive theorem prover, so as to define the functionality of the memory management operations. Based on the requirements document, a formal specification of the requirements layer is constructed in the interactive theorem prover, and the proof of the formal specification of the requirements layer is completed in the interactive theorem prover; wherein, the formal specification of the requirements layer is used to formally describe multiple requirements layer system attributes defined in the requirements document in a meta-language, and the requirements layer system attributes include multiple functional correctness attributes and multiple security attributes. A first refinement relation is established between the formal model of the design layer and the formal model of the requirement layer, and the proof of the first refinement relation is completed in the interactive theorem prover to confirm that the formal model of the design layer satisfies all the formal specifications of the requirement layer of the formal model. A second refinement relation is established between the formal model of the implementation layer and the formal model of the design layer, and the proof of the second refinement relation is completed in the interactive theorem prover to confirm that the formal model of the implementation layer satisfies all the formal specifications of the formal model of the design layer. If the formal specification, the first refined relation, and the second refined relation are all proven, then the memory management module is determined to have passed formal verification, and the formal specification includes the formal specification of the requirement layer.

2. The formal verification method for the memory management module according to claim 1, characterized in that, The system attributes of the requirement layer include multiple functional correctness attributes and multiple security attributes. Based on the requirement document, a formal specification of the requirement layer is constructed in the interactive theorem prover, including: In the interactive theorem prover, the functional correctness attributes defined in the requirements document are formally described in a meta-language to obtain the functional correctness specifications for each memory management operation. The multiple functional correctness attributes include the correctness attributes of the functions of each memory management operation. In the interactive theorem prover, the various security attributes defined in the requirements document are formally described in a meta-language to obtain security specifications for each memory management operation; the various security attributes include total memory conservation, no overlapping memory blocks, and no duplicate releases.

3. The formal verification method for the memory management module according to claim 2, characterized in that, Also includes: Based on the requirements document, a design layer formal specification is constructed in the interactive theorem prover, wherein the design layer formal specification is used to formally describe multiple design layer system properties defined in the design document in a meta-language, and the design layer system properties include system properties that are different from the requirements layer system properties; The proof of the formal specification of the design layer is completed in the interactive theorem prover.

4. The formal verification method for the memory management module according to claim 3, characterized in that, Also includes: Based on the source code, an implementation layer formal specification is constructed in the interactive theorem prover, wherein the implementation layer formal specification is used to formally describe multiple implementation layer system properties defined in the source code in the form of state monads, and the implementation layer system properties include system properties that are different from the requirement layer system properties; The proof of the formal specification of the implementation layer is completed in the interactive theorem prover.

5. The formal verification method for the memory management module according to claim 4, characterized in that, If the formal specification of the requirement layer, the first refined relation, and the second refined relation are all proven, then the memory management module is determined to have passed formal verification, including: If the formal specification, the first refined relation, and the second refined relation are all proven, the memory management module is determined to have passed formal verification. The formal specification also includes the design layer formal specification and the implementation layer formal specification.

6. The formal verification method for the memory management module according to claim 1, characterized in that, Establish a first refinement relationship between the formal model of the design layer and the formal model of the requirements layer, and complete the proof of the first refinement relationship in the interactive theorem prover, including: The first refinement relation is established by defining the first mapping function, which is used to map the memory block structure in the formal model of the design layer to the memory block representation in the formal model of the requirements layer. Proof: The memory management operations in the formal model of the design layer, after being transformed by the first mapping function, are consistent with the corresponding memory management operations defined in the formal model of the requirements layer.

7. The formal verification method for the memory management module according to claim 1, characterized in that, Establish a second refinement relationship between the formal model of the implementation layer and the formal model of the design layer, and complete the proof of the second refinement relationship in the interactive theorem prover, including: A second refinement relation is established by defining a second mapping function, which is used to map the memory block structure represented by state monads in the formal model of the implementation layer to the memory block data structure in the formal model of the design layer. Proof: The memory management operations of the implementation layer formal model, after being transformed by the second mapping function, are consistent with the corresponding memory management operations in the design layer formal model.

8. A formal verification apparatus for a memory management module, characterized in that, include: The source file acquisition unit is used to acquire the requirements document, design document, and source code of the memory management module to be verified. The formal modeling unit is used to construct, in an interactive theorem prover, a formal model of the requirements layer, a formal model of the design layer, and a formal model of the implementation layer, based on the requirements document, the design document, and the source code. The formal model of the requirements layer is used to formally describe the algorithms and data structures of the memory management operations defined in the requirements document in a meta-language, so as to define the functions of the memory management operations, including initialization operations, memory allocation operations and memory release operations. The formal model of the design layer is used to formally describe the algorithms and data structures of the memory management operations defined in the design document in a meta-language, so as to define the functionality of the memory management operations; The implementation layer formal model is used to formally model the functions of memory management operations defined in the source code using the state monads of the interactive theorem prover, so as to define the functionality of the memory management operations. The first proof unit is used to construct a formal specification of the requirement layer in the interactive theorem prover based on the requirement document, and to complete the proof of the formal specification of the requirement layer in the interactive theorem prover; wherein, the formal specification of the requirement layer is used to formally describe multiple requirement layer system attributes defined in the requirement document in a meta-language, and the requirement layer system attributes include multiple functional correctness attributes and multiple security attributes. The second proof unit is used to establish a first refinement relationship between the formal model of the design layer and the formal model of the requirement layer, and to complete the proof of the first refinement relationship in the interactive theorem prover, so as to confirm that the formal model of the design layer satisfies all the formal specifications of the requirement layer of the formal model. The third proof unit is used to establish a second refinement relationship between the implementation layer formal model and the design layer formal model, and to complete the proof of the second refinement relationship in the interactive theorem prover, so as to confirm that the implementation layer formal model satisfies all the requirement layer formal specifications of the design layer formal model; The verification result determination unit is used to determine that the memory management module passes formal verification if the formal specification, the first refined relation, and the second refined relation are all proven. The formal specification includes the formal specification of the requirement layer.

9. A computer program product, characterized in that, It includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the formal verification method for the memory management module as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the formal verification method for the memory management module as described in any one of claims 1 to 7.

Images