Memory safety verification method in Java code automatic generation based on Event-B

Abstract

The present invention discloses a memory security verification method in automatic Java code generation based on Event‑B. Firstly, the functional requirements, environmental requirements and security requirements of the memory management system are clarified. Then, the memory management system is abstractly modeled and the core functions of the system are defined, including memory allocation, recycling and state management. The memory management process is formally described to ensure the verifiability of the system behavior. The refinement strategy starts from the initial abstract model and gradually introduces different functional requirements and security requirements for refinement. In each step of the refinement process, the model is verified. The security conversion rules from Event‑B to JML and then to Java code are constructed, and the Isabelle / HOL theorem prover is used to verify the semantics of the system behavior, so as to ensure the correctness of the memory operation in the code conversion process and realize the security conversion from Event‑B model to Java code.

Description

Technical Field

[0001] The present invention belongs to the technical field of formal verification and automatic code generation, and relates to a memory safety verification method in automatic Java code generation based on Event-B. Background Art

[0002] Event-B is a formal modeling language for responsive systems and a formal software development method in which software systems are initially conceived in a very abstract way and then refined into code. The verified Event-B model directly generates code to ensure consistency between the implementation and the original verified model. This reduces the risk of manual coding errors and implementation deviations, especially when it comes to complex safety-critical systems. The use of automatic code generation can reduce the manual workload from abstract models to specific implementations and improve development efficiency.

[0003] As a mature formal method, Event-B has been widely used in many fields abroad, especially in the design and verification of safety-critical systems. For example, in the European aviation field, Event-B is used to verify the safety of flight control systems and simulate and verify aircraft arrival managers [Mammar, A., Leuschel, M. (2023). Modeling and Verifying an Arrival Manager Using EVENT-B. In: Glasser, U., Creissac Campos, J., Méry, D., Palanque, P. (eds) Rigorous State-Based Methods. ABZ 2023. Lecture Notes in Computer Science, vol 14010. Springer, Cham.]. This method emphasizes starting from an abstract model and gradually refining it to a specific implementation, making the verification process more rigorous and systematic. These studies usually focus on improving the automation level of verification tools and reducing manual intervention.

[0004] In terms of memory management, foreign researchers focus on how to accurately describe complex memory allocation and recycling strategies through formal methods, and how to effectively deal with memory fragmentation problems. For example, Yu et al. from Yale University used Coq language as a formal tool [Yu, D., Hamid, NA, Shao, Z. (2003). Building Certified Libraries for PCC: Dynamic Storage Allocation. In: Degano, P. (eds) Programming Languages ​​and Systems. ESOP 2003. Lecture Notes in Computer Science, vol 2618. Springer, Berlin, Heidelberg.] to verify the assembly code implementation of a relatively simple memory allocation algorithm. However, the algorithm is far from meeting the requirements of spacecraft, and there are problems such as oversimplification and poor performance in actual applications.

[0005] In recent years, China has begun to attach importance to the application of formal methods in software engineering, especially in safety-critical systems such as aviation, aerospace and high-speed railway systems, which have put forward higher requirements for the formal verification of memory management systems. The Event-B method has gradually attracted attention due to its systematicity and rigor. Researchers have begun to try to use Event-B and other methods to formally model and verify aerospace software. SpaceOS [L.Qiao, M.Yang, B.Gu, H.Yang and B.Liu,"An EmbeddedOperating System Design for the Lunar Exploration Rover,"2011 FifthInternational Conference on Secure Software Integration and ReliabilityImprovement-Companion, Jeju, Korea (South), 2011, pp.160-165, doi:10.1109 / SSIRI-C.2011.39.] is the first domestically developed and space-flying embedded real-time operating system for spacecraft. It is a real-time operating system dedicated to spacecraft. Its design modularity is good and can be formally verified in modules.

[0006] Mery and Singh [Singh NK, Singh N K. EB2ALL: an automatic code generation tool [J]. Using Event-B for Critical Device Software Systems, 2013: 105-141.] presented the EB2ALL plug-in toolset, which converts Event-B machines into several different languages: C, C++, Java, and C. EB2ALL only supports a small subset of Event-B syntax, and users are required to write the final Event-B implementation refinement using the syntax supported by the tool.

[0007] Wright [Wright S. Automatic generation of C from Event-B [C] / / Workshop on integration of model-based formal methods and tools. 2009: 14.] defined a B2C extension of the Rodin platform to convert Event-B models into C code.

[0008] Rivera V, Cataño N [Translating Event-B to JML-specified Java programs [C] / / Proceedings of the 29th Annual ACM Symposium on Applied Computing. 2014: 1264-1271.] developed an open source tool EventB2Java for translating Event-B into Java class code based on JML description. However, as pointed out in the paper, EventB2Java does not implement constant initialization and lacks proof of correctness of the conversion at the corresponding stage. Users need to manually specify constant values ​​to meet the constraints, which increases the development burden and may introduce errors. At the same time, the invariant expression of memory safety requirements is not strictly maintained in the Java implementation, and there is no verification whether the generated Java code meets the memory safety requirements at runtime.

[0009] In summary, none of the existing Java code automatic generation tools based on the Event-B model have performed security proof work. The lack of security in the memory management system of current tools is mainly reflected in the fact that they cannot effectively generate code that meets memory safety requirements. This means that the generated code may lack security verification of memory access and operations, and cannot ensure that memory leaks, illegal access and other problems are avoided, especially in the process of memory allocation and release, which may introduce security vulnerabilities. These vulnerabilities may cause crashes in the operation of the memory management system, data corruption, and even bring security risks to the system. Summary of the invention

[0010] In view of the shortcomings of the prior art, the present invention provides a memory safety verification method in Java code automatic generation based on Event-B to solve the problem of security deficiency in the prior art. By ensuring the security property verification in the code generation process of the memory management system, the reliability of the model-to-code conversion is enhanced, and potential system crashes and security risks are prevented.

[0011] The present invention is achieved through the following technical solutions:

[0012] A memory safety verification method in automatic Java code generation based on Event-B includes the following steps:

[0013] The first step is to clarify the functional requirements, environmental requirements, and security requirements of the memory management system in the automatic generation of Java code based on Event-B, including:

[0014] Functional requirements include: dynamic memory allocation and release, memory merging and segmentation, memory status tracking and management;

[0015] Environmental requirements include: abstract environment constraints that adapt to the hardware limitations of different devices, memory isolation mechanisms, the structure of the pointer operation model and pointer constraints and state constraints of its related operations;

[0016] Security requirements include: preventing null pointer dereference, preventing memory leaks, and reducing memory fragmentation;

[0017] The second step is Event-B modeling of memory management: abstract modeling of the memory management system, defining the core functions of the system, including memory allocation and release, merging and splitting, and state tracking and management. The memory management process is formally described based on the Event-B language to ensure the verifiability, correctness, and consistency of system behavior. The refinement strategy starts from the initial abstract model and gradually introduces different functional requirements and security requirements for refinement. At each step of the refinement process, the model is verified to ensure that the introduction of new functions and attributes will not destroy the existing system properties, until a memory management system model that includes all functions, environments, and security requirements is finally obtained.

[0018] The third step is to convert the Event-B machine model into the JML language. The events in each machine are decomposed into two JML methods: a guard method for detecting guard conditions and a run method for executing operations. The JML method ensures that the event is executed and the state is consistent when the conditions are met through different specification situations, and accurately expresses the assignment and state changes in Event-B through existential quantifiers and predicate operations, closely combining the formal specification with the Java implementation, and ensuring that the converted Java code still meets the safety constraints of the original model through verification;

[0019] The fourth step is to convert the formal machine model of Event-B into an abstract JML annotated Java class. The converted class contains abstract methods converted from Event-B events. These methods are inherited and implemented in Java to ensure that each step meets the requirements of the memory management system and verify the initialization and constraints of the memory block status during the conversion process.

[0020] In the third and fourth steps, the Isabelle / HOL theorem proving tool is used to formally verify the semantics of the memory management system behavior in the conversion process from Event-B machine model to JML, and from JML to Java, to ensure the verifiability, correctness and consistency of memory operations in each conversion step, and finally convert the Event-B machine model into Java code with JML annotations, thereby completing the automatic generation of memory management Java code based on Event-B.

[0021] Furthermore, when the memory adopts a doubly linked list data structure, the environment requirements also include no circular references.

[0022] Furthermore, during the model refinement process, the security requirements in the memory management system are converted into formal invariants to ensure that each operation in the model meets the memory safety requirements.

[0023] Furthermore, the conversion rules from Event-B to JML are as follows:

[0024] Each Event-B event is converted into two JML methods: a guard method for judging the event guard condition and a run method for executing the event operation. The guard method is used to judge whether the event meets the execution condition and returns a Boolean value after converting the machine model into JML language. If the condition is met, it returns true, otherwise it returns false.

[0025] Each run method contains two specification cases, indicating whether the event meets the guard condition. If the guard condition is met, the method must be executed and ensure that the state meets the post-condition after the transition. If the guard condition is not met, the method does not modify any fields to ensure that the state before and after is consistent.

[0026] For the any constructor in Event-B, its variables are bound in JML through existential quantification expressions, and the guard method returns true if the guard condition is satisfied;

[0027] The ordinary assignment and non-deterministic assignment in Event-B are expressed differently in JML. The syntax of non-deterministic assignment ":|" is converted into existential quantification expression in JML. Multiple assignment operations are converted one by one and connected by logical combiners.

[0028] Furthermore, Isabelle / HOL is used to verify the process of converting the Event-B event model to JML. During the verification process, the state variables in the Event-B model are first declared in Isabelle / HOL, and the invariants in the Event-B model are converted into predicate logic expressions in Isabelle to ensure consistency before and after the conversion.

[0029] Furthermore, when using the Isabelle / HOL theorem proving tool to verify the conversion of Event-B model to JML, the following contents are included:

[0030] Verification of conversion guard conditions: During the JML conversion process, the guard conditions of Event-B are defined as preconditions of JML methods. The guard method in each JML method is verified through Isabelle / HOL to ensure that the guard conditions remain consistent after each state change.

[0031] Correctness verification of event conversion: When verifying the correctness of the conversion from Event-B to JMLrun method, it is necessary to formally describe the preconditions and postconditions of each event. Use Isabelle / HOL to prove that when the preconditions of the JML method are met, the method can be executed correctly and ensure that the state transition meets the postconditions of the Event-B model.

[0032] Define the before and after states of an event: In Isabelle / HOL, the behavior of an event is described by defining the before and after state functions, and verify whether the before and after states of each event conform to the specifications of the JML method;

[0033] Verification of assignment and variable binding: The assignment operation in Event-B is converted from JML to Java code. Isabelle / HOL is used to verify whether the status before and after the assignment operation is consistent.

[0034] Proof of invariant preservation: The memory safety requirement invariants defined in the Event-B model must remain unchanged during the JML conversion process. In Isabelle / HOL, each invariant is proved to ensure that the invariant still holds after each event execution;

[0035] Integrated verification of JML annotations and Isabelle / HOL: In Isabelle / HOL, preconditions, postconditions, and invariants are formalized as logical formulas and verified for each execution path of the code.

[0036] Furthermore, the conversion rules from JML to Java are as follows:

[0037] Class structure and abstract methods: The machine in Event-B will be converted into an abstract Java class with JML annotations. The class contains multiple abstract methods, each of which corresponds to a different event of Event-B. These abstract classes and methods will be inherited and implemented by specific subclasses, thereby mapping the behavior of the Event-B model to Java code;

[0038] Conversion between context and machine: The sets, constants, axioms, and theorems in the context of Event-B are combined with the variables, invariants, events, variants, and guard conditions in the machine, and the whole is converted into a complete Java class structure;

[0039] Preconditions and postconditions: In JML, requires is used to represent preconditions, and ensures is used to represent postconditions. For methods with multiple specification cases, the precondition is the disjunction of the preconditions of each case. The precondition of the overall run method is true, indicating that the method can always be called; when the guard condition is met, the specific implementation of the run method must be executed and ensure that the corresponding postcondition is met;

[0040] Guard conditions and method execution: Guard conditions are converted into requires clauses in JML. When the guard condition is met, the corresponding Java method will be executed and its postcondition must be met. If the guard condition is not met, the Java method will not modify any state to ensure consistency between the previous and next states.

[0041] Furthermore, Isabelle / HOL performs formal verification during the JML to Java conversion process, including the following:

[0042] Verify the correctness of class structure and abstract methods: In Isabelle / HOL, verify whether the structure of the generated Java class can correctly implement the original Event-B and JML models, including: checking whether the definition of the abstract class is consistent with the structure of the Event-B machine, and verifying whether each abstract method correctly corresponds to the event in Event-B;

[0043] Verification of abstract classes: Define an abstract class structure in Isabelle / HOL and verify whether it completely contains the corresponding events in Event-B. Specifically, ensure that the fields and methods of the abstract class correspond one-to-one with the variables and events in Event-B, and verify whether the inheritance relationship of the abstract class meets the design intent.

[0044] Verification of context and machine conversion: Convert the context in Event-B to the corresponding part in the Java class and verify the correctness of these conversions in Isabelle / HOL, including: ensuring that collections and constants are correctly mapped to static fields or constants of Java classes, and verifying whether axioms and theorems are correctly embedded in Java classes through JML annotations or logical formulas;

[0045] Precondition and postcondition consistency verification: In Isabelle / HOL, formally describe the precondition of each JML method and verify whether the Java implementation meets the following requirements: the precondition can be maintained under all possible input conditions, the state update after the method is executed complies with the definition of the postcondition, and for methods with multiple specification conditions, verify whether the disjunction logic of its precondition is correct;

[0046] Verification of guard conditions and execution methods: Verify the logical correctness of guard conditions in Isabelle / HOL. Java methods are executed only when guard conditions are met. Specifically, it includes: formally defining guard conditions and verifying their logical consistency with JML to ensure that Java methods do not modify any state when guard conditions are not met;

[0047] Verification of invariant preservation: Formalize the invariants in the Event-B model as logical formulas in Isabelle / HOL and verify whether they are maintained after each Java method execution. Specifically, it includes: proving that the Java implementation still satisfies the invariants of memory safety after executing the operation, and ensuring that the invariants are maintained in all possible state transitions.

[0048] Compared with the prior art, the present invention has the following beneficial effects:

[0049] The present invention discloses a memory safety verification method in the automatic generation of Java code based on Event-B, which realizes the safe conversion from Event-B model to Java code. At the same time, taking the generation of Java code of a bidirectional linked list as an example, a modeling method, a safety verification method and a conversion algorithm from the initial model to the final code implementation process are given. At the assembly level, by formally modeling the operation of the memory management module and using the Isabelle / HOL theorem prover to verify the semantics of the system behavior, the correctness of the memory operation during the code conversion process is ensured. The core content of this article includes memory-related functional requirements and security requirements analysis, a memory safety verification framework based on the model refinement method, and Event-B modeling and code generation process taking linked list operations as an example, including the safety conversion rules and verification process from Event-B to JML, and then to Java code, ensuring the safety property guarantee from the abstract model to the specific implementation, avoiding potential system crashes and security risks.

[0050] The present invention successfully realizes the safe conversion from abstract design to Java code by gradually refining the Event-B model and combining the formal verification tool Isabelle / HOL, ensuring that the memory management system has high security and reliability, avoiding problems such as null pointer dereference, memory leaks and memory fragmentation. The embodiment of the present invention adopts the data structure and invariant constraints of a doubly linked list to ensure the correctness and efficiency of memory operations, while realizing the modular design of memory management, and improving the scalability and maintainability of the system. The technical solution of the present invention is not only applicable to data structures such as doubly linked lists, but can also be extended to other complex memory management scenarios, providing strong technical support for the development of high-security systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 This is a schematic diagram of a process flow of an embodiment of the method of the present invention;

[0052] Figure 2 A refined flow chart is provided for modeling the memory management system of the present invention. DETAILED DESCRIPTION

[0053] The exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. It should be noted that, although specific embodiments of the present invention are shown in the accompanying drawings, the implementation of the present invention is not limited to these embodiments. On the contrary, these embodiments are provided in order to enable a more thorough understanding of the present invention and to fully convey the scope of the present invention to those skilled in the art. It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments can be combined with each other. The present invention will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0054] The present invention proposes a memory safety verification method in Java code automatic generation based on Event-B, aiming to ensure the correctness, security and reliability in the memory management process. First, the requirements of the memory management system are analyzed in detail, and the functional requirements, environmental requirements and security requirements are defined. Among them, the functional requirements focus on dynamic memory allocation and release, merging and segmentation of memory blocks, and tracking and management of memory status to ensure efficient utilization of memory resources and system stability. Environmental requirements emphasize the adaptability to abstract environmental constraints restricted by different device hardware, memory isolation mechanism, the structure of pointer operation model and pointer constraints and state constraints of related operations. Security requirements mainly include preventing null pointer dereference, preventing memory leaks and reducing memory fragmentation to ensure the security of memory operations and the continuous stability of the system.

[0055] To achieve the above requirements, the present invention adopts a model refinement method based on Event-B, which is gradually refined from the initial abstract model to the specific implementation. By gradually introducing more complex functional requirements and security requirements, the model refinement process at each stage includes preliminary modeling of bidirectional linked lists, insertion and deletion of nodes, allocation and release of memory blocks, improvement of traversal operations, and gradual introduction of security invariants. Each model refinement is verified by invariant verification to ensure that the system maintains verifiability, correctness and consistency during the refinement process, forming a memory management system model that meets all functional and security requirements.

[0056] During the model conversion process, JML annotations are used to formalize the memory management requirements and security requirements in Event-B into specifications and invariants in JML. Each Event-B event is converted into two JML methods, a guard method for detecting guard conditions and a run method for executing operations. JML annotations ensure the correctness, security and consistency of Java implementation by maintaining preconditions, postconditions and invariants during conversion to Java code. In addition, the present invention introduces theorem proving tools such as Isabelle / HOL to formally verify the conversion of Event-B model to JML and the conversion of JML to Java, thereby ensuring the correctness and consistency of each conversion step.

[0057] In the code generation phase, high security and reliability of the memory management process are ensured through model refinement and JML conversion rules. The secure code generation process ensures that each memory operation meets the security requirements of memory management through formal invariant definitions, avoiding risks such as system crashes, memory leaks, and data corruption caused by improper operations. This systematic model refinement and conversion method not only realizes the functional requirements of the memory management system, but also fully guarantees the security of memory operations, providing a feasible technical solution for the design and implementation of complex memory management systems.

[0058] The present invention needs to ensure that the memory management requirements in the Event-B model are correctly converted into Java code, including functional requirements and security requirements, to ensure that the generated code has correctness, security and reliability in the memory management process. The specific requirements are as follows:

[0059] 1. Functional requirements

[0060] The functional requirements of the memory management system mainly focus on the dynamic allocation, release, merging, segmentation, and state tracking and management of memory to ensure efficient use of memory resources and system stability. It mainly includes the following points:

[0061] Dynamic memory allocation and release: The memory management system needs to be able to dynamically allocate memory blocks based on requests from users or other kernel modules, and recycle them promptly and appropriately after the task is completed. This ensures that the allocated memory can be used reasonably and that the released memory can be returned to the system in a timely manner, avoiding resource waste and improving memory usage efficiency.

[0062] Memory merging and segmentation: When releasing memory, the memory management system should be able to automatically detect and merge adjacent free memory blocks to reduce memory fragmentation and maximize memory utilization. At the same time, for scenarios that require smaller memory blocks, the system should support segmenting large blocks of memory to meet the memory requirements of different applications and improve the utilization of memory space.

[0063] Memory status tracking and management: The memory management system needs to maintain a global memory status table to accurately record the status of each memory block (allocated or free). By tracking the status of memory blocks, it can effectively prevent repeated allocation or release of unallocated memory blocks, ensure the validity and consistency of memory, and ensure the stability and reliability of the system.

[0064] 2. Environmental requirements

[0065] The design and implementation of the memory management system needs to consider the environmental constraints of the target device. Specifically, the memory management system should be able to adapt to the abstract environmental constraints of different device hardware limitations, including key parameters such as the upper limit of memory capacity and the minimum number of allocation units, to ensure that the system maintains system stability and efficiency in a multi-task parallel processing environment. In addition, the system should also have a complete memory isolation and pointer management mechanism to ensure the correctness and effectiveness of memory operations:

[0066] Structure and pointer constraints: Each memory block should contain a data part and a pointer part. The pointer part is used to link the previous and next memory blocks to support efficient memory allocation and release operations. Pointers should be one-to-one corresponding to ensure that they do not interfere with each other.

[0067] State constraints: The system needs to maintain the head pointer and tail pointer status of the memory and clearly define different states to facilitate efficient memory management, allocation, and recycling operations.

[0068] No circular references: In a doubly linked list, circular references must be avoided, and the linked list structure should not contain loops, that is, starting from any node, traversing along the successor pointer should not return to that node, thereby ensuring the correctness of the linked list structure and the security of memory management.

[0069] 3. Security requirements

[0070] Existing code conversion tools do not support memory-safe code generation, which may cause the operating system to face the risk of crash, data corruption or security attacks. This invention mainly optimizes and converts three key security requirements:

[0071] Prevent null pointer dereference: When performing memory allocation and release operations, you must ensure that all memory block references are valid pointers to avoid accessing unallocated or released memory blocks. During the operation, the memory block status needs to be checked to ensure that there is no illegal access, thereby avoiding system crashes or data corruption.

[0072] Prevent memory leaks: Ensure that each allocated memory block is properly released and marked as free when it is no longer in use, and merge adjacent free memory blocks as much as possible to maintain the continuity of available memory resources, prevent memory blocks from being permanently unusable, and avoid memory leaks.

[0073] Memory fragmentation reduction requirements: Ensure that the size of each free block is not less than a fixed value, and control the overall memory fragmentation rate within a specified threshold to improve memory utilization. Through a reasonable memory management strategy, reduce the generation of small memory blocks, improve the effective utilization of system memory, and avoid memory fragmentation affecting the normal operation of the system.

[0074] This paper proposes a model refinement method for a memory management system, which aims to gradually develop from abstract concepts to specific implementations to ensure the security and correctness of memory management. This method is based on Event-B modeling and covers the entire process from abstract models to specific code implementations, including the invariant conversion of memory safety requirements and the multi-stage model refinement process. The entire refinement method consists of the following main steps:

[0075] The first step is Event-B modeling of memory management: First, abstractly model the memory management system and define the core functions of the system, such as memory allocation and release, merging and splitting, and state tracking and management. By formally describing the memory management process, the verifiability, correctness, and consistency of system behavior are ensured. The initial model starts from a high-level abstraction and gradually introduces more complex functions and security requirements.

[0076] The second step is to convert security requirements into invariants: convert the security requirements in the system (such as preventing null pointer dereference, preventing memory leaks and memory fragmentation management) into formal invariants to ensure that each operation in the model meets the requirements of memory safety. These invariants are strictly followed in the subsequent code implementation to ensure the stability and reliability of the system.

[0077] The third step is the security verification rules in JML conversion: the Event-B event model is converted to JML. During the process, a series of formal verification rules are used to ensure that the memory safety requirements are maintained at the code level. Each Event-B event is decomposed into two JML methods, a guard method for detecting event guard conditions and a run method for performing specific operations on the event. The JML method ensures that the event is executed and the state is consistent when the conditions are met through different specification situations, and accurately expresses the assignment and state changes in Event-B through existential quantifiers and predicate operations, thereby closely combining the formal specification with the Java implementation to ensure that the converted code still meets the security constraints of the original model.

[0078] Step 4: Rules for safe conversion from JML to Java code: Use a set of syntax rewriting rules to convert the formalized machine of Event-B into an abstract JML-annotated Java class. The converted class contains abstract methods converted from Event-B events, which can be inherited and implemented in Java. Ensure that each step meets the requirements of the memory management system. The conversion process not only includes the initialization of the memory block state and the verification of constraints, but also formal verification through theorem provers such as Isabelle / HOL to ensure the correctness and security of the code.

[0079] Through these steps, the model refinement method of the present invention realizes the complete process from abstract design to specific implementation, ensuring that the memory management system has high security and reliability when converted into Java code, avoiding the risks of system crash, data corruption or security attack.

[0080] The present invention will be further described below in conjunction with an embodiment of a memory management system composed of a bidirectional linked list. Figure 1 As shown in the figure, the security code generation process of the doubly linked list structure memory management system is as follows:

[0081] As a key component of the operating system kernel, memory management has the core function of providing memory allocation and recycling services for each module of the system. In the architecture of the operating system, the memory management system is at the bottom layer, and its operating stability is directly related to the security and reliability of the entire system. Therefore, when modeling the memory management system, the present invention adopts a data structure based on a bidirectional linked list, and finally realizes the optimized management and security protection of memory resources through multi-level model refinement.

[0082] In the system modeling process, the bidirectional linked list is first modeled to describe the data structure of the nodes and their interrelationships. Each linked list node contains a data field and two pointer fields (the predecessor pointer field and the successor pointer field point to the previous node and the next node respectively), and the overall behavior of the linked list is described by the nodes and their interrelationships. To ensure the completeness and security of the system functions, the functional requirements are marked with FUN, the environmental requirements are marked with ENV, and the security requirements are marked with SAF.

[0083] The requirements analysis of the memory management system based on a doubly linked list focuses on the following aspects:

[0084] Functional requirements (FUN) include:

[0085] FUN-1: Linked list node storage and access – The system should be able to store information in any node of a doubly linked list and be able to access this information.

[0086] FUN-2: Node insertion and deletion - The system should be able to insert and delete nodes at any position in the linked list while maintaining the integrity of the linked list. During insertion and deletion operations, the pointers of adjacent nodes must be correctly updated to maintain the structure and status information of the linked list.

[0087] FUN-3: Modification of node information - The system should be able to modify the node information and correctly update the pointers of adjacent nodes during the modification to maintain the integrity of the linked list.

[0088] FUN-4: Bidirectional traversal - The system should be able to traverse the entire linked list from beginning to end and from end to beginning.

[0089] FUN-5: Maintenance of linked list length - The system should correctly maintain the length of the doubly linked list and be able to quickly obtain the total number of nodes.

[0090] FUN-6: Search Operation – The system should be able to search for an element of a specific value in a doubly linked list.

[0091] FUN-7: Information processing interface - The system should provide commonly used linked list information processing interface to facilitate users to perform common operations.

[0092] FUN-8: Maintenance of integrity and order of linked lists - The system should maintain the order, integrity and consistency of the linked lists when performing specific operations (such as insertion and deletion).

[0093] Environmental requirements (ENV) include:

[0094] ENV-1: Node structure - Each node contains a data field and two pointer fields, pointing to the previous and next nodes respectively. For the first node, the predecessor pointer is null; for the last node, the successor pointer is null.

[0095] ENV-2: Head and tail pointers - A doubly linked list should have pointers pointing to the head node and tail node respectively to support efficient insertion and deletion operations.

[0096] ENV-3: Pointer uniqueness - The predecessor pointer and successor pointer should point to a unique node respectively to avoid duplicate pointing.

[0097] ENV-4: Node relationship - The pointing relationship between every two nodes should be one-to-one and there should be no mutual interference.

[0098] ENV-5: Empty linked list state - when the linked list is empty, the head and tail pointers should be null and the length is 0, that is, the predecessor pointer of the first node is null and the successor pointer of the last node is null.

[0099] ENV-6: No circular references - A doubly linked list should not contain cycles, i.e. traversing from any node along the successor pointer should not return to that node.

[0100] Safety requirements (SAF) include:

[0101] SAF-1: Preventing null pointer dereferences - When performing insertion and deletion operations, the node's predecessor and successor must be checked to be present and valid to prevent null pointer access.

[0102] SAF-2: Prevent memory leaks - ensure that each allocated node is properly released and marked as free when no longer in use, merge adjacent free nodes to ensure that free memory blocks in the linked list can be reused, and avoid hanging nodes causing memory leaks.

[0103] SAF-3: Reduce memory fragmentation - Ensure that the size of each free memory block is not less than a fixed value to avoid generating memory blocks that are too small and cannot be effectively used.

[0104] SAF-4: Control memory fragmentation rate - Ensure that the overall memory fragmentation rate does not exceed a fixed value to ensure memory utilization.

[0105] According to the model refinement method proposed in the present invention, the present invention implements the following refinement strategy: This strategy is based on the initial model, gradually introduces more complex functions and security requirements, and finally builds a complete memory management system that meets all functional requirements, environmental requirements, and security requirements. The following is a specific refinement strategy for the memory management system, which continuously improves the integrity and robustness of the model by gradually adding different functions and security measures at each stage.

[0106] At each step of refinement, the model needs to be rigorously verified to ensure that the introduction of new functions and properties will not destroy the existing system properties. The core of this method is to gradually expand functions and continuously increase details to eventually build a robust bidirectional linked list memory management system that meets all functional, environmental and security requirements.

[0107] This step-by-step refinement approach ensures that each functional module of the linked list memory management system is fully defined and verified, thereby achieving step-by-step refinement from the abstract model to the specific code implementation. This ensures that the memory management system has high security and reliability at the code level, effectively avoiding potential risks of system crashes, data corruption or security attacks.

[0108] According to the refinement steps, the model is divided into 7 levels, each level covers different requirements and verifies different properties. The formal model constructed from requirements to design is mainly shown in Table 1. The construction process of the formal model is as follows Figure 2 The steps are carried out step by step.

[0109] Table 1 Formal model refinement process

[0110]

[0111] The process of Event-B modeling for memory is as follows:

[0112] In Event-B, the bidirectional linked list model uses context to define the carrier set of node type and node content type, which are called ITEM and INFO respectively. The linked list also includes a special virtual node anchor, which is used to connect the head and tail nodes of the linked list and acts as a head and tail pointer (as described in ENV-2). The content of the virtual node is defined as anchorinfo, which does not belong to the linked list itself.

[0113] Since the modeling work is relatively large, the modeling work of the event "delete any node, and the linked list has ≥ 2 nodes remaining" is used as an example to describe the modeling process. This event is used to delete a specific node x from the linked list and update the related attributes of the linked list. The specific code is:

[0114]

[0115] According to the informal description and refinement strategy of the protocol requirements above, the Event-B method is used to model and analyze the bidirectional linked list and memory management system on the Rodin platform. In order to ensure that the model meets the various requirements of memory management, the correspondence between each requirement and the model element will be explained during the modeling process. When describing the modeling process, it will be explained step by step how the modeling elements in the context and the machine meet specific requirements. The complete process of memory management involves multiple operations and complex system states. In order to simplify the model and highlight the core functions of memory management, only basic dynamic memory allocation, release, merging and other operations are considered in the modeling process, and unnecessary external influences and abnormal situations are ignored. In the process of model refinement, only the newly added modeling elements and modified parts are listed, so as to gradually reflect the complete evolution of the memory management system from abstraction to concrete implementation.

[0116] After analyzing the model requirements, the consistency of the model structure and refinement process was verified using the automatic generation of proof obligations (PO) provided by Rodin. Although Rodin automatically generates proof obligations and attempts to automatically prove them, for complex and cumbersome models, automatic proof may fail due to reasons such as too complex proof obligations or time constraints. In actual applications, proofs were manually performed and all propositions to be proved were completed. The number of model proofs at each stage is shown in Table 2.

[0117] Table 2 Summary of the number of proofs in the model refinement process

[0118]

[0119] The invariant expression of security requirements and the addition of memory model are as follows:

[0120] In view of the security requirements of the memory management system, the present invention converts them into corresponding invariants to ensure the security and stability of memory management. These invariants will be verified after each operation to ensure that the system meets all security requirements of memory management.

[0121] The NULL pointer dereference prevention (SAF-1) invariant description: , for each node x in the linked list, if its predecessor and successor nodes exist and are valid, then x must also be part of the linked list. This ensures that all pointer references are valid before performing any memory operations, thus preventing null pointer dereferences.

[0122] Preventing Memory Leaks (SAF-2) Invariant Description: For each node x in the linked list, if x has been allocated and is no longer in use (i.e. isInUse(x) is false), then x should be marked as a free memory block and put into the free block set FreeBlocks. This ensures that each allocated memory block in the system can be properly released and recycled after it is no longer in use, avoiding memory leaks.

[0123] Reduce memory fragmentation (SAF-3) invariant description: , for each free block f in the linked list, its size must be greater than or equal to minBlockSize. This ensures that the size of the memory block is not too small, avoiding fragmentation caused by too many small memory blocks.

[0124] Control memory fragmentation rate (SAF-4) invariant description: , define the overall memory fragmentation rate not to exceed a fixed value maxFragmentationRate to ensure memory utilization. This can be achieved through regular system memory defragmentation, merging adjacent free blocks, etc., to ensure efficient and secure memory management.

[0125] These invariants formally define the security requirements of the memory management system and are used to verify the system status to ensure that each operation will not undermine the security and consistency of the system. Through the formal description of these invariants, these security requirements can be gradually introduced and verified during the refinement and code generation of the Event-B model, ensuring that security can be maintained from the abstract model to the specific implementation, and ultimately forming a robust memory management system.

[0126] The memory management system model obtained after multiple refinements in this embodiment is as follows:

[0127]

[0128]

[0129]

[0130] The specific contents of introducing JML migration rules and verification are as follows:

[0131] Event-B to JML conversion rules:

[0132] Event conversion to JML methods: Each Event-B event is converted into two JML methods: a guard method for determining the event guard condition and a run method for executing the event operation. The guard method is used to determine whether the event meets the execution condition. After converting the machine model into JML language, it returns a Boolean value. If the condition is met, it returns true, otherwise it returns false.

[0133] Guard and execute methods in JML: Each run method contains two specification cases, indicating whether the event meets the guard condition. If the guard condition is met, the method must be executed and the state must meet the post-condition after the transition. If the guard condition is not met, the method does not modify any fields to ensure that the state before and after is consistent.

[0134] Guards and variable binding: The variables in the any constructor in Event-B are bound by existential quantification expressions in JML, and the guard method returns true, indicating that the guard condition of the conversion is met.

[0135] Conversion of assignment operations: Normal assignments and non-deterministic assignments are represented differently in JML. The syntax of non-deterministic assignments ":|" is converted to existential quantification in JML. Multiple assignments are converted one by one and combined. For example, the simultaneous assignments x:=y and y:=x are converted to the JML representation of two variables exchanging values.

[0136] For security requirements only, we get:

[0137]

[0138] In the process of converting from Event-B to JML, JML adds invariants and condition checks related to memory safety to ensure the corresponding safety in the Java implementation. Compared with the Event-B model, JML adds invariants for constraints such as memory fragmentation rate control, null pointer prevention, and memory leak prevention, and introduces additional verification rules, such as variables such as minBlockSize and maxFragmentationRate, to explicitly control the safety attributes and performance goals in the memory management process, ensuring safety and consistency at the code level.

[0139] Isabelle / HOL is used to verify the process of converting the Event-B event model to JML. The formal verification in Isabelle / HOL is as follows:

[0140] In order to ensure that the Event-B model is correctly converted to the JML specification, formal verification is required using Isabelle / HOL to prove that each step of the conversion is consistent in terms of security and functionality. Isabelle / HOL is a powerful theorem prover that can strictly verify the formal model through logical reasoning and invariant checking. The following is a detailed process of how to perform this verification in Isabelle / HOL:

[0141] ①Define state variables and invariants

[0142] First, define state variables and invariants in Isabelle / HOL to ensure consistency before and after the conversion:

[0143] State variable definition: Declare state variables in the Event-B model in Isabelle / HOL, such as next, previous, content, etc., to describe the predecessor and successor relationships of linked list nodes, as well as node content.

[0144] Invariant conversion: The invariants in the Event-B model are converted into predicate logic expressions in Isabelle. For example, this definition ensures that when the predecessor and successor pointers of each node are valid, the node must be part of the linked list to prevent null pointer dereference:

[0145]

[0146] ②Verification of guard switching conditions

[0147] Events in the Event-B model have guard conditions to ensure that the execution of the event complies with certain constraints. During the JML conversion process, the guard conditions are defined as JML preconditions and need to be verified in Isabelle:

[0148] Define guard conditions: Formalize the guard conditions of each event as preconditions in Isabelle. For example, this condition indicates that before performing a memory allocation operation, it is necessary to ensure that there are free blocks of sufficient size:

[0149]

[0150] Verify guard consistency: Use Isabelle to verify the guard method in each JML method to ensure that the guard condition remains consistent after each state change.

[0151] ③Correctness verification of event conversion

[0152] In order to verify the correctness of the conversion from Event-B to JML run method, it is necessary to formally describe the preconditions and postconditions of each event to ensure that the converted method is executed correctly when the preconditions are met.

[0153] Define the before and after states of an event: In Isabelle / HOL, the behavior of an event is described by defining the before and after state functions. These definitions describe the changes in the FreeBlocks and Allocated collections before and after memory allocation, ensuring that the converted code performs the correct state transition when the preconditions are met:

[0154]

[0155]

[0156] Verify state consistency: Use the reasoning tools in Isabelle / HOL to verify whether the state before and after each event conforms to the specification of the JML method. For example, verify whether the state change of memory allocation conforms to the defined behavior. This lemma is used to verify that when the precondition is met, the Allocate_run method can correctly update the system state:

[0157]

[0158] ④Verification of assignment and variable binding

[0159] The assignment operation in Event-B needs to be correctly converted into the assignment in Java code in JML. Isabelle / HOL is used to verify whether the status before and after the assignment operation is consistent.

[0160] Formal assignment verification: Formalize the assignment operation in the Event-B model, such as x:=y, into a state transition function in Isabelle / HOL and verify the correctness of the assignment. For example, this definition is used to verify the correctness of the exchange of two variables:

[0161]

[0162] ⑤Proof of the preservation of invariants

[0163] Memory safety invariants defined in the Event-B model (e.g., SAF-1 to SAF-4) must remain unchanged during the JML transformation. In Isabelle / HOL, each invariant needs to be proven to ensure that they still hold after each event execution.

[0164] Invariant proof template: For each invariant, use Isabelle's proof process to verify that the invariant still holds after executing all possible events. For example, this lemma proves that the SAF-1 invariant still holds after executing the memory allocation event:

[0165]

[0166] ⑥Integration verification of JML annotations and Isabelle / HOL

[0167] Annotations in JML are used to describe the contracts (preconditions, postconditions, invariants) of Java code. In Isabelle / HOL, by formalizing these JML contracts into logical formulas, each execution path of the code can be verified to ensure that the transformation from Event-B to JML is not only functionally correct, but also meets all safety requirements.

[0168] Verify the correctness of the JML contract: Introduce the pre- and post-conditions in JML into Isabelle / HOL for verification to ensure that the behavior of each method is safe under all possible inputs. For example, this proof ensures that the JML contract meets the original Event-B safety requirements after each event execution:

[0169]

[0170] Through the formal verification of Isabelle / HOL, it can be ensured that each state transition, assignment operation, invariant and security requirement are correctly preserved and implemented during the conversion from Event-B to JML. This verification process ensures that the final generated Java code can meet the security requirements of memory management while maintaining functional correctness, avoiding potential system crashes, memory leaks and security risks.

[0171] The introduction of Java migration rules and verification are as follows:

[0172] JML to Java conversion rules:

[0173] Class structure and abstract methods: Event-B's machinery will be converted into an abstract Java class with JML annotations, which contains multiple abstract methods, each corresponding to a different event of Event-B. These abstract classes and methods can be inherited and implemented by subclasses.

[0174] Conversion of context and machine: The context in Event-B includes sets, constants, axioms, and theorems, which are converted into corresponding parts of abstract Java classes, such as carrier sets, constants, axioms, etc. These elements, as components of the class, are combined with other parts of the machine for overall conversion.

[0175] Preconditions and postconditions: JML uses requires to represent preconditions and ensures to represent postconditions. In the case of multiple specification cases, the precondition is the disjunction of the preconditions of each case, so the precondition of the overall run method is always true.

[0176] Postconditions take effect when certain conditions are met, similar to the semantics of Event-B, that is, when the guard condition is met, the method is executed and the corresponding postcondition must be met.

[0177] Isabelle / HOL performs formal verification during the JML to Java conversion process as follows:

[0178] During the conversion process from JML to Java, Isabelle / HOL is required for formal verification to ensure that each step from the JML specification to the Java implementation meets the original Event-B design goals and memory safety requirements. The conversion from JML to Java involves gradually concretizing the abstract formal description into executable Java code. In this process, the class structure, the implementation of abstract methods, and the preservation of preconditions and postconditions need to be strictly verified to ensure the correctness and consistency of all conversion steps. The following is the details of the verification process:

[0179] ① Define the correctness of class structure and abstract methods

[0180] The JML specification is usually converted into an abstract Java class with JML annotations, which contains multiple abstract methods, each corresponding to a different event of Event-B. It is necessary to verify whether the structure of the Java class can correctly implement the original Event-B and JML model.

[0181] Verification of abstract classes: In Isabelle / HOL, we first define the structure of an abstract class and verify whether it contains the corresponding events in Event-B. For example, for each Event-B machine, we formally describe in Isabelle / HOL how it is converted into an abstract method of a Java class. This definition ensures that the Java class contains all the events in the original Event-B machine and that these events are represented as abstract methods in the Java class:

[0182]

[0183] ②Context and machine conversion verification

[0184] The context in Event-B (including collections, constants, axioms, and theorems) is converted to the corresponding parts in the Java class, such as collections and constants. In Isabelle / HOL, these conversions need to be verified to ensure that each element is correctly mapped in Java.

[0185] Verification of collections and constants: In Isabelle / HOL, the collections and constants in the Event-B context are defined as class attributes and their representation in the Java class is verified to be correct. For example, this definition ensures that the collections and constants in the context are correctly defined and constrained in the Java class, maintaining the constraints of the original axioms and theorems:

[0186]

[0187] ③Verification of the persistence of preconditions and postconditions

[0188] JML uses requires and ensures to describe preconditions and postconditions, which must be maintained when converted to Java to ensure that the behavior of the Java method is consistent with the Event-B model.

[0189] Precondition verification: In Isabelle / HOL, it is necessary to formally describe the preconditions of each JML method and verify whether the Java implementation can maintain these preconditions under all possible input conditions. Assuming run_Allocate is a method for allocating memory blocks, the verification form of its preconditions is, this lemma proves that the preconditions in JML also hold in the Java implementation:

[0190]

[0191] Postcondition Verification For each event postcondition, it is necessary to verify that the Java implementation meets these conditions and, after execution: meets the corresponding state update. In Isabelle / HOL, the postcondition can be expressed as a state transition. This lemma ensures that the Java implementation meets the JML postcondition:

[0192]

[0193] ④Verification of guard conditions and execution methods

[0194] In JML, guard conditions are defined by the guard method to determine whether an event can be executed. The logical correctness of the guard conditions needs to be verified in Isabelle / HOL to ensure that the Java method can be executed only when the guard conditions are met.

[0195] Guard Condition Preservation: Guard conditions are formally defined and verified to be correct in Java methods. This lemma proves that the guard conditions in Java are consistent with the guard logic in the original JML:

[0196]

[0197] ⑤Verification of the preservation of invariants

[0198] During the conversion process from JML to Java, it is necessary to ensure that all invariants (such as memory management safety requirements) remain consistent in the converted Java implementation. Using Isabelle / HOL, these invariants are verified to ensure that they still hold after each method execution in the Java code.

[0199] Invariant verification: Each invariant is formalized as a logical formula in Isabelle and verified to hold after each Java method execution. This lemma ensures that the Java implementation maintains the memory safety invariants after the operation is executed:

[0200]

[0201] By using Isabelle / HOL to formally verify the JML to Java transformation, we can ensure that every step from the abstract JML specification to the Java implementation is correct. Specifically, this verification includes the preservation of class structure, correct mapping of context, verification of pre- and post-conditions, preservation of guard conditions, and verification of invariants. The verification of all these steps ensures that the final generated Java code can meet all the functional and security requirements of the original Event-B model, thereby ensuring the reliability and stability of the system.

[0202] The present invention has been described in detail above through embodiments, but the contents described are only exemplary embodiments of the present invention and cannot be considered to limit the scope of implementation of the present invention. The protection scope of the present invention is defined by the claims. Anyone who utilizes the technical solution described in the present invention, or a technician in the field, inspired by the technical solution of the present invention, designs a similar technical solution within the essence and protection scope of the present invention to achieve the above technical effects, or makes equal changes and improvements to the scope of application, shall still belong to the scope of protection covered by the patent of the present invention. It should be noted that in order to make a clear statement, the description of some components and processes that have no direct and obvious connection with the scope of protection of the present invention but are known to those skilled in the art are omitted in the description of the present invention.

Claims

1. A memory safety verification method in automatic Java code generation based on Event-B, characterized in that: The following steps are involved: The first step is to clarify the functional requirements, environmental requirements, and security requirements of the memory management system in the automatic generation of Java code based on Event-B, including: Functional requirements include: dynamic memory allocation and release, memory merging and segmentation, memory status tracking and management; Environmental requirements include: abstract environment constraints that adapt to the hardware limitations of different devices, memory isolation mechanisms, the structure of the pointer operation model and pointer constraints and state constraints of its related operations; Security requirements include: preventing null pointer dereference, preventing memory leaks, and reducing memory fragmentation; The second step is Event-B modeling of memory management: abstract modeling of the memory management system, defining the core functions of the system, including memory allocation and release, merging and splitting, and state tracking and management. The memory management process is formally described based on the Event-B language to ensure the verifiability, correctness, and consistency of system behavior. The refinement strategy starts from the initial abstract model and gradually introduces different functional requirements and security requirements for refinement. At each step of the refinement process, the model is verified to ensure that the introduction of new functions and attributes will not destroy the existing system properties, until a memory management system model that includes all functions, environments, and security requirements is finally obtained. The third step is to convert the Event-B machine model into the JML language. The events in each machine are decomposed into two JML methods: a guard method for detecting guard conditions and a run method for executing operations. The JML method ensures that the event is executed and the state is consistent when the conditions are met through different specification situations, and accurately expresses the assignment and state changes in Event-B through existential quantifiers and predicate operations, closely combining the formal specification with the Java implementation, and ensuring that the converted Java code still meets the safety constraints of the original model through verification; The fourth step is to convert the formal machine model of Event-B into an abstract JML annotated Java class. The converted class contains abstract methods converted from Event-B events. These methods are inherited and implemented in Java to ensure that each step meets the requirements of the memory management system and verify the initialization and constraints of the memory block status during the conversion process. In the third and fourth steps, the Isabelle / HOL theorem proving tool is used to formally verify the semantics of the memory management system behavior in the conversion process from Event-B machine model to JML, and from JML to Java, to ensure the verifiability, correctness and consistency of memory operations in each conversion step, and finally convert the Event-B machine model into Java code with JML annotations, thereby completing the automatic generation of memory management Java code based on Event-B.

2. According to the memory safety verification method in the automatic generation of Java code based on Event-B according to claim 1, it is characterized in that: When the memory uses a doubly linked list data structure, the environment requirements also include no circular references.

3. According to the memory safety verification method in the automatic generation of Java code based on Event-B according to claim 1, it is characterized in that: During the model refinement process, the security requirements in the memory management system are converted into formal invariants to ensure that each operation in the model meets the memory safety requirements.

4. According to the memory safety verification method in the automatic generation of Java code based on Event-B according to claim 1, it is characterized in that: The conversion rules from Event-B to JML are as follows: Each Event-B event is converted into two JML methods: a guard method for judging the event guard condition and a run method for executing the event operation. The guard method is used to judge whether the event meets the execution condition and returns a Boolean value after converting the machine model into JML language. If the condition is met, it returns true, otherwise it returns false. Each run method contains two specification cases, indicating whether the event meets the guard condition. If the guard condition is met, the method must be executed and ensure that the state meets the post-condition after the transition. If the guard condition is not met, the method does not modify any fields to ensure that the state before and after is consistent. For the any constructor in Event-B, its variables are bound in JML through existential quantification expressions, and the guard method returns true if the guard condition is satisfied; The common assignment and non-deterministic assignment in Event-B are expressed differently in JML. The syntax of non-deterministic assignment ":|" is converted into existential quantification expression in JML. Multiple assignment operations are converted one by one and connected by logical combiners.

5. According to claim 4, a memory safety verification method in Java code automatic generation based on Event-B is characterized in that: Isabelle / HOL is used to verify the process of converting the Event-B event model to JML. During the verification process, the state variables in the Event-B model are first declared in Isabelle / HOL, and the invariants in the Event-B model are converted into predicate logic expressions in Isabelle to ensure consistency before and after the conversion.

6. According to the memory safety verification method in the automatic generation of Java code based on Event-B according to claim 4, it is characterized in that: When using the Isabelle / HOL theorem proving tool to verify the transformation of the Event-B model to JML, the following is included: Verification of conversion guard conditions: During the JML conversion process, the guard conditions of Event-B are defined as preconditions of JML methods. The guard method in each JML method is verified through Isabelle / HOL to ensure that the guard conditions remain consistent after each state change. Correctness verification of event conversion: When verifying the correctness of the conversion from Event-B events to JML run methods, it is necessary to formally describe the preconditions and postconditions of each event. Use Isabelle / HOL to prove that when the preconditions of the JML method are met, the method can be executed correctly and ensure that the state transition meets the postconditions of the Event-B model. Define the before and after states of an event: In Isabelle / HOL, the behavior of an event is described by defining the before and after state functions, and verify whether the before and after states of each event conform to the specifications of the JML method; Verification of assignment and variable binding: The assignment operation in Event-B is converted from JML to Java code. Isabelle / HOL is used to verify whether the status before and after the assignment operation is consistent. Proof of invariant preservation: The memory safety requirement invariants defined in the Event-B model must remain unchanged during the JML conversion process. In Isabelle / HOL, each invariant is proved to ensure that the invariant still holds after each event execution; Integrated verification of JML annotations and Isabelle / HOL: In Isabelle / HOL, preconditions, postconditions, and invariants are formalized as logical formulas and verified for each execution path of the code.

7. According to the memory safety verification method in the automatic generation of Java code based on Event-B according to claim 1, it is characterized in that: The conversion rules from JML to Java are as follows: Class structure and abstract methods: The machine in Event-B will be converted into an abstract Java class with JML annotations. The class contains multiple abstract methods, each of which corresponds to a different event of Event-B. These abstract classes and methods will be inherited and implemented by specific subclasses, thereby mapping the behavior of the Event-B model to Java code; Conversion between context and machine: The sets, constants, axioms, and theorems in the context of Event-B are combined with the variables, invariants, events, variants, and guard conditions in the machine, and the whole is converted into a complete Java class structure; Preconditions and postconditions: In JML, requires is used to represent preconditions, and ensures is used to represent postconditions. For methods with multiple specification cases, the precondition is the disjunction of the preconditions of each case. The precondition of the overall run method is true, indicating that the method can always be called; when the guard condition is met, the specific implementation of the run method must be executed and ensure that the corresponding postcondition is met; Guard conditions and method execution: Guard conditions are converted into requires clauses in JML. When the guard condition is met, the corresponding Java method will be executed and its postcondition must be met. If the guard condition is not met, the Java method will not modify any state to ensure consistency between the previous and next states.

8. According to claim 7, a memory safety verification method in automatic generation of Java code based on Event-B is characterized in that: Isabelle / HOL performs formal verification during the JML to Java conversion process, including the following: Verify the correctness of class structure and abstract methods: In Isabelle / HOL, verify whether the structure of the generated Java class can correctly implement the original Event-B and JML models, including: checking whether the definition of the abstract class is consistent with the structure of the Event-B machine, and verifying whether each abstract method correctly corresponds to the event in Event-B; Verification of abstract classes: Define an abstract class structure in Isabelle / HOL and verify whether it completely contains the corresponding events in Event-B. Specifically, ensure that the fields and methods of the abstract class correspond one-to-one with the variables and events in Event-B, and verify whether the inheritance relationship of the abstract class meets the design intent. Verification of context and machine conversion: Convert the context in Event-B to the corresponding part in the Java class and verify the correctness of these conversions in Isabelle / HOL, including: ensuring that collections and constants are correctly mapped to static fields or constants of Java classes, and verifying whether axioms and theorems are correctly embedded in Java classes through JML annotations or logical formulas; Precondition and postcondition consistency verification: In Isabelle / HOL, formally describe the precondition of each JML method and verify whether the Java implementation meets the following requirements: the precondition can be maintained under all possible input conditions, the state update after the method is executed complies with the definition of the postcondition, and for methods with multiple specification conditions, verify whether the disjunction logic of its precondition is correct; Verification of guard conditions and execution methods: Verify the logical correctness of guard conditions in Isabelle / HOL. Java methods are executed only when guard conditions are met. Specifically, it includes: formally defining guard conditions and verifying their logical consistency with JML to ensure that Java methods do not modify any state when guard conditions are not met; Verification of invariant preservation: Formalize the invariants in the Event-B model as logical formulas in Isabelle / HOL and verify whether they are maintained after each Java method execution. Specifically, it includes: proving that the Java implementation still satisfies the invariants of memory safety after executing the operation, and ensuring that the invariants are maintained in all possible state transitions.

Images