A memory safety management method and apparatus

Abstract

A memory safety management method is disclosed, comprising: inserting a check statement to check pointer attributes before a risky statement in a first program; the risky statement is a statement in the first program that calls a pointer to access memory, and the pointer attribute is the attribute of the pointer in the risky statement; performing redundant code elimination on the first transformed program and the check statement respectively to obtain a first eliminated program and a second eliminated program; the first transformed program is an intermediate representation generated by compiling the first program; performing machine instruction conversion on the second eliminated program during compilation to obtain a second transformed program; and generating a target executable file based at least on the second transformed program and the first eliminated program. This method performs redundancy optimization on the first program before the check statement performs compilation conversion during compilation, which can improve the performance of code optimization during compilation.

Description

Technical Field

[0001] This application relates to the field of memory management technology, and in particular to a memory security management method and device. Background Technology

[0002] In C or C-like applications, pointers are commonly used to achieve flexible access to memory resources. However, improper use of pointers by developers can introduce security risks to memory management. These risks primarily manifest as memory safety issues related to memory types, such as null pointer dereferencing, out-of-bounds reads, and out-of-bounds writes.

[0003] Currently, solutions to memory safety issues related to memory space primarily involve modifying the source code by manually adding pointer attribute information. This information is then used to insert checks during compilation and to handle errors at runtime. However, because these inserted checks are first converted into branching machine instructions during compilation, the introduction of these branching structures complicates the logical relationships of the source code, significantly impacting the optimization effect during redundant code elimination and leading to substantial runtime overhead for the application. This is unacceptable in some overhead-sensitive fields, such as Wi-Fi chips and routers. Summary of the Invention

[0004] This application provides a memory safety management method and device that can improve the optimization effect of the source program during the compilation process, so that the runtime overhead of the target executable file is within the controllable range of the terminal, thereby improving the user experience of using terminal applications.

[0005] Firstly, this application provides a memory safety management method. The method includes: inserting a check statement to check pointer attributes before a risky statement in a first program; the risky statement is a statement in the first program that calls a pointer to access memory, and the pointer attribute is an attribute of the pointer in the risky statement; performing redundant code elimination on the first converted program and the check statement respectively to obtain a first eliminated program and a second eliminated program; wherein the first converted program is an intermediate representation generated by compiling the first program; performing machine instruction conversion during the compilation process on the second eliminated program to obtain a second converted program; generating a target executable file based at least on the second converted program and the first eliminated program; wherein the target executable file is used to generate fault information at runtime, the fault information including the pointer attribute of the pointer in the first risky statement, and the first risky statement is one of the risky statements in the first program.

[0006] Therefore, by changing the compilation and transformation process of the checking statements, the redundant code of the program is eliminated after the first transformation, and then the machine instructions of the checking statements are transformed during the compilation process. Thus, the logical relationship structure of the program after the first transformation is not changed during the redundant code elimination stage of the compilation process, thereby improving the optimization effect of the program after the first transformation during the compilation process.

[0007] In one possible implementation, redundant code elimination is performed on the first transformed program and the checking statements, including: by judging the checking object and checking scope of the checking statements, eliminating all identical redundant code and all partially ordered redundant code in the checking statements to obtain a third eliminated program; the checking object and checking scope of the checking statements are obtained at least based on the risk statements; by hashing the checking object of the checking statements in the third eliminated program, eliminating some identical redundant code and some partially ordered redundant code in the third eliminated program to obtain a second eliminated program.

[0008] Therefore, during the compilation process, redundant code is also eliminated from the checking statements, further improving the overall optimization effect of the target executable file and effectively reducing the runtime overhead of the application.

[0009] In one possible implementation, a check statement for checking pointer attributes is inserted before the risk statement in the first program, including: inserting a label statement after the pointer definition statement in the first program; the label statement is used to obtain the pointer attributes of the pointer in the risk statement; inserting a pointer attribute storage statement after the label statement; the pointer attribute storage statement is used to store the pointer attributes obtained by the label statement, and the pointer attribute storage statement contains pointer attribute variables, which are variables used to represent pointer attributes; the pointer attribute storage statement is a first user-defined statement recognizable by the compiler; based on the risk statement and the pointer attribute storage statement, a check statement for checking the pointer attributes of the risk statement is determined; wherein, the risk statement is used to determine the object of the check statement, and the pointer attribute variables contained in the pointer attribute storage statement and the pointer attributes stored in the pointer attribute storage statement are used to determine the scope of the check statement; wherein, the check statement is a second user-defined statement recognizable by the compiler; and inserting the check statement for checking pointer attributes before the risk statement.

[0010] Therefore, by storing pointer attributes in real time and establishing a connection between pointer attribute storage statements and checking statements, the correctness of pointer attributes used in checking statements can be maintained, false negatives can be reduced, and more comprehensive security capabilities can be provided.

[0011] In one possible implementation, after performing redundant code elimination on the first converted program and the checking statement respectively, the method further includes: eliminating redundant code in the pointer attribute storage statement and eliminating pointer attribute variables contained in the redundant code in the pointer attribute storage statement to obtain a fourth eliminated program; wherein, the pointer attributes stored in the redundant code in the pointer attribute storage statement and the pointer attribute variables contained in the redundant code in the pointer attribute storage statement are used to determine the checking scope of the redundant code in the checking statement; generating a target executable file based at least on the second converted program and the first eliminated program includes: generating a target executable file based on the second converted program, the first eliminated program, and the fourth eliminated program.

[0012] Therefore, during the compilation process, redundant code is eliminated for pointer attribute storage statements and pointer attribute variables contained in pointer attribute storage statements, further improving the overall optimization effect of the target executable file and effectively reducing the runtime overhead of the application.

[0013] In one possible implementation, the first program is a program written in C or a C-like language.

[0014] Secondly, this application provides a memory safety management device. The device includes: a processing module, configured to insert a check statement for checking pointer attributes before a risky statement in a first program; the risky statement is a statement in the first program that calls a pointer to access memory, and the pointer attribute is an attribute of the pointer in the risky statement; the processing module is further configured to perform redundant code elimination on the first converted program and the check statement respectively, obtaining a first eliminated program and a second eliminated program; wherein the first converted program is an intermediate representation generated by compiling the first program; the processing module is further configured to perform machine instruction conversion during the compilation process on the second eliminated program, obtaining a second converted program; the processing module is further configured to generate a target executable file based at least on the second converted program and the first eliminated program; wherein the target executable file is used to generate fault information at runtime, the fault information including the pointer attribute of the pointer in the first risky statement, and the first risky statement is one of the risky statements in the first program.

[0015] In one possible implementation, when the processing module performs redundant code elimination on the first converted program and the checking statements, it is used to: eliminate all identical redundant code and all partially ordered redundant code in the checking statements by judging the checking object and checking scope, and obtain the third eliminated program; the checking object and checking scope of the checking statements are obtained at least based on the risk statements; and eliminate some identical redundant code and some partially ordered redundant code in the third eliminated program by hashing the checking object of the checking statements in the third eliminated program, and obtain the second eliminated program.

[0016] In one possible implementation, when the processing module inserts a check statement to check pointer attributes before a risk statement in the first program, it performs the following steps: inserts a labeling statement after the pointer definition statement in the first program; the labeling statement is used to obtain the pointer attributes of the pointer in the risk statement; inserts a pointer attribute storage statement after the labeling statement; the pointer attribute storage statement is used to store the pointer attributes obtained by the labeling statement, and the pointer attribute storage statement contains pointer attribute variables, which are variables used to represent pointer attributes; the pointer attribute storage statement is a first user-defined statement recognizable by the compiler; based on the risk statement and the pointer attribute storage statement, determines a check statement to check the pointer attributes of the risk statement; wherein, the risk statement is used to determine the object of the check statement, and the pointer attribute variables contained in the pointer attribute storage statement and the pointer attributes stored in the pointer attribute storage statement are used to determine the scope of the check statement; wherein, the check statement is a second user-defined statement recognizable by the compiler; and inserts a check statement to check pointer attributes before the risk statement.

[0017] In one possible implementation, after the processing module performs redundant code elimination on the first converted program and the checking statement, it is used to: eliminate redundant code in the pointer attribute storage statement and eliminate pointer attribute variables contained in the redundant code in the pointer attribute storage statement to obtain a fourth eliminated program; wherein, the pointer attributes stored in the redundant code in the pointer attribute storage statement and the pointer attribute variables contained in the redundant code in the pointer attribute storage statement are used to determine the checking scope of the redundant code in the checking statement; when the processing module generates the target executable file based at least on the second converted program and the first eliminated program, it is used to: generate the target executable file based on the second converted program, the first eliminated program, and the fourth eliminated program.

[0018] In one possible implementation, the first program is a program written in C or a C-like language.

[0019] Thirdly, this application provides an electronic device, comprising: at least one memory for storing a program; and at least one processor for executing the program stored in the memory; wherein, when the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation thereof.

[0020] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to perform the method described in the first aspect or any possible implementation thereof.

[0021] Fifthly, this application provides a computer program product that, when run on a processor, causes the processor to perform the method described in the first aspect or any possible implementation thereof.

[0022] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0023] Figure 1 This is a diagram illustrating the process of compiling and optimizing code by checking statements using a branching structure.

[0024] Figure 2 It is a control flow diagram for checking the transformed statement structure;

[0025] Figure 3 This is a system architecture diagram of a memory security management method provided in an embodiment of this application;

[0026] Figure 4 This is a flowchart of a memory security management method provided in an embodiment of this application;

[0027] Figure 5a This is a flowchart illustrating a conventional VRAP algorithm processing method provided in an embodiment of this application;

[0028] Figure 5b This is a flowchart illustrating a customized VRAP algorithm processing method provided in an embodiment of this application;

[0029] Figure 6a This is a flowchart illustrating a conventional PRE algorithm processing method provided in an embodiment of this application;

[0030] Figure 6b This is a flowchart illustrating a customized PRE algorithm processing method provided in an embodiment of this application;

[0031] Figure 7 This is a flowchart illustrating a conventional DCE algorithm processing method provided in an embodiment of this application;

[0032] Figure 8 This is a flowchart of a source program compilation provided in an embodiment of this application;

[0033] Figure 9 This is an implementation architecture diagram of a memory security management method provided in an embodiment of this application;

[0034] Figure 10 This is a flowchart of a memory security management method provided in an embodiment of this application;

[0035] Figure 11This is an implementation architecture diagram of a memory security management method provided in an embodiment of this application;

[0036] Figure 12 This is an implementation architecture diagram of a memory security management method provided in an embodiment of this application;

[0037] Figure 13 This is a schematic diagram of the hardware structure of a memory security management device provided in an embodiment of this application;

[0038] Figure 14 This is a schematic diagram of the hardware structure of a memory security management device provided in an embodiment of this application. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described below with reference to the accompanying drawings.

[0040] In the description of the embodiments of this application, the words "exemplary" or "for example" are used to indicate that they are examples or illustrations. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0041] In the description of the embodiments in this application, the term "and / or" is merely a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, B existing alone, and A and B existing simultaneously. Furthermore, unless otherwise stated, the term "multiple" means two or more. For example, multiple systems refer to two or more systems, and multiple screen terminals refer to two or more screen terminals.

[0042] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and their variations all mean "including but not limited to," unless otherwise specifically emphasized.

[0043] To address potential memory safety risks in C or C-like applications when performing memory operations using pointers and pointer arithmetic, such as null pointer dereferencing, out-of-bounds reads, and out-of-bounds writes, it's crucial to locate and optimize suspicious pointers as much as possible during the compilation and debugging phases. Furthermore, during runtime, information about error pointers should be output, including their location within the application, error type, and error pattern. This facilitates debugging, modification, and maintenance for developers and system administrators. C-like languages, similar to C, involve memory operations using pointers and pointer arithmetic.

[0044] Figure 1 This is a diagram illustrating the process of code compilation and optimization that utilizes branching structures to inspect statements. For example... Figure 1 As shown, based on the design and implementation principles of the application solution, developers write the source code for this application solution using C or a C-like language. This source code extensively uses pointers to access and read / write terminal memory. To minimize potential memory safety management risks arising from pointer and memory interactions, one optional technical solution requires the following steps:

[0045] Step S100 involves determining the intermediate program, which includes check statements inserted before statements with pointer memory access risks and the source program. The execution of these risky statements may introduce memory safety vulnerabilities in pointer space classes. Step S100 may specifically include the following sub-steps S101-S103:

[0046] Step S101: Write the source program according to the application scheme requirements, and annotate all statements using pointers in the source program with pointer attributes. These pointer attribute annotations are mainly used to obtain the length and boundary information of the memory block pointed to by the pointer. This pointer attribute annotation can be similar to a positioning instruction, such as: where p: count(n), which means that the length of the memory block pointed to by pointer p is n. In the subsequent compilation stage, the compiler provides corresponding lexical and semantic analysis to extract the information represented by the pointer attribute annotations, such as: the length of the memory block pointed to by p is 5, and the boundary is [p, p+5).

[0047] Step S102: In the source program with added pointer attribute annotations, identify risky statements that access memory using pointers and insert check statements before these risky statements. As mentioned above, memory safety mainly includes three categories: null pointer dereferencing, out-of-bounds reads, and out-of-bounds writes. To eliminate potential risks caused by pointers, null check statements need to be inserted before memory access risky statements that may involve null pointer dereferencing. For example, a common null check statement, check(p != null), is inserted to check pointer access to memory space. For out-of-bounds reads and writes, out-of-bounds checks need to be inserted before pointer memory access risky statements. For example, a common out-of-bounds check statement, check(p >= p), is inserted to check the lower bound of pointer access, and check(p < p + 5) is inserted to check the upper bound of pointer access. If a pointer has both dereferencing and out-of-bounds risks, a null check statement needs to be inserted first, followed by an out-of-bounds check statement. Therefore, by inserting check statements to describe whether the conditions are met, the program can check for memory problems that may be caused by pointers used in the program. The check statements mentioned above appear in the source program in the form of "pseudocode", which is a custom statement format that can be recognized by the compilation process.

[0048] In step S103, after the compilation process extracts the information represented by the pointer attribute annotations, it removes the pointer attribute annotations to obtain the intermediate program, which includes the checking statements about pointers and the source program.

[0049] Thus, the intermediate program is determined. The intermediate program includes the check statements inserted at the pointer memory access point and the source program. Next, the intermediate program is compiled.

[0050] Step S110 involves using compiler technology to perform intermediate transformations, redundant code optimization, and target code generation on the intermediate program containing the inserted check statements. For common compiler techniques, to ensure the intermediate program meets compilation requirements, code transformation is performed on the intermediate program after the insertion of check statements according to syntax and semantic rules in the early stages of compilation. For check statements, a common transformation method is to convert them into a combination of regular comparison instructions and jump instructions. This transformation expands the check statement from a branchless single-instruction structure into a branch execution structure, thus significantly altering the logical structure of the source program in the intermediate program.

[0051] Figure 2 It is a control flow diagram that checks the structure of statements after transformation, such as Figure 2As shown, in the control flow graph (CFG), check statements in pseudocode form, check(i<upper) and check(j<upper), are inserted into the pointers p[i] and p[j] used in the source program, respectively. In the early stage of compilation, the check statements are converted into a combination of regular comparison instruction cmp and jump instruction jump according to the syntax and semantics, so that the check statements present a branching mode.

[0052] Subsequently, during the mid-compilation stage, optimization algorithms are used to optimize redundant code, and during the late-compilation stage, target code is generated, ultimately forming a binary executable file carrying check statements for technical personnel to debug, modify, and maintain the code. For example, during the runtime of the executable file, when the check instruction is triggered and the condition is met, the program exhibits a core dump caused by a jump exit operation, resulting in program termination. Developers can use the debug information in the binary file output by program termination to reconstruct diagnostic information for debugging. The diagnostic information includes the line number, column number, etc. of the diagnosed program.

[0053] The following section introduces several code optimization algorithms that may be involved in the mid-stage of compilation:

[0054] Value range analysis and propagation (VRAP) is a code optimization algorithm that uses the value range information of variables to remove redundant branches and expressions. When the comparison result of a comparison statement can be directly obtained through variable value range analysis, redundant branches can be removed based on this comparison result, and the expressions on the redundant branches are also deleted. At the same time, the value range of the compared objects in the comparison statement is updated.

[0055] Partial redundancy elimination (PRE) is a code optimization algorithm that eliminates redundant expressions by using the hash result of the expression to address situations where the expression is redundant for one branch but not for another.

[0056] Dead code elimination (DCE) is a code optimization algorithm that removes code that has no impact on the program's execution result.

[0057] However, the above Figure 1The method of using branching structures to inspect statements for code compilation and optimization, as demonstrated in the article, has significant shortcomings and flaws in practical applications, mainly for the following reasons:

[0058] First, to achieve complete memory safety, check statements need to be inserted before all risky statements that access memory using pointers. The number of these checks is very large, directly proportional to the proportion of memory access statements in the code, leading to significant runtime overhead. Furthermore, since these inserted check statements perform redundancy checks and code optimizations based on branching during compilation, they greatly affect the compilation and optimization effects of the source program, further increasing runtime overhead. The introduction of branching check statements makes the control flow graph extremely complex, rendering existing code optimization techniques ineffective during compilation. In step S110, during the early stages of compilation, the intermediate program after the insertion of check statements is uniformly transformed according to syntactic and semantic requirements, including the transformation of the branching patterns of the check statements, which further complicates the control flow graph. For example... Figure 2 As shown, each inserted check statement will bring a redundant node and a redundant path. Code optimization algorithms such as VRAP, PRE, and DCE all rely on pattern matching under CFG. Under complex CFG, the original code optimization pattern no longer holds and cannot play its original optimization role, resulting in a significant reduction in optimization effect. As a result, the final target executable file generated in the later stage of compilation is extremely bloated and cannot be widely used in terminal systems with limited memory resources.

[0059] In view of this, embodiments of this application provide a memory safety management method. In this method, checking statements and other code in the intermediate program are separated. The step of converting the checking statements from a single-instruction structure to a branch-structure machine instruction based on syntax and semantic rules in the early stage of compilation is postponed to the later stage of code generation. During the redundant code replacement process in the middle stage of compilation, the checking statements inserted based on the single-instruction method are optimized using customized VRAP, PRE, and DCE code optimization algorithms to eliminate redundancy and optimize code for both the source program in the CFG and the inserted checking statements. This effectively reduces the impact of the inserted checking statements on the redundancy optimization of the source program, keeping the memory resource consumption of the final generated target executable file within a reasonable range and significantly reducing runtime overhead.

[0060] Secondly, the propagation of pointer attributes across statements was not considered, leading to errors in the mapping between check statements and pointer attributes, resulting in missed detections. Although the pointer attributes in the source program were marked in step S101, thus obtaining the length and boundary of the memory region pointed to by the pointer, the boundary was not stored and updated in real time. This means that the boundary attributes obtained by subsequent check statements are still the old version. The old boundary information is carried into the check statements, resulting in invalid checks and missed detections. For example, when pointer p is declared, its length is marked as 5, so the length of the memory block pointed to by pointer p is [p, p+5). When accessing the memory region pointed to by p, an out-of-bounds check is required. The lower bound check statement is: check(p>=p), and the upper bound check statement is: check(p<p+5). When checking the 0th element of the first memory block pointed to by pointer p, out-of-bounds behavior can be detected. However, if pointer p is subsequently incremented in the program, when the memory area pointed to by pointer p is accessed again, pointer p will point to the first element of the first memory block. However, the target of the check statement is still p >= p and p < p + 5. Obviously, this check is invalid because the program has actually performed an out-of-bounds behavior, but it cannot be found by the check statement.

[0061] In view of this, embodiments of this application provide a pointer attribute storage statement that stores the results of pointer attribute annotation in real time and establishes a direct mapping between pointer attributes and check statements. This maintains the correctness of the pointer attributes used in the check statements, reduces false negatives, and provides more comprehensive security capabilities. Furthermore, based on the redundancy elimination results of the check statements, the pointer attribute storage statement can also be redundantly eliminated, further improving the redundancy elimination effect.

[0062] Figure 3 This is a system architecture diagram of a memory safety management method provided in an embodiment of this application, such as... Figure 3 As shown, the system architecture diagram includes five parts: language definition module 300, pointer attribute annotation module 310, check statement insertion module 320, code optimization module 330, and target code generation module 340. The specific functions of each module are described below:

[0063] The language definition module 300 describes the syntax and semantic rules of the source program, pointer attribute annotations, pointer attribute storage statements, checking statements, and various intermediate representations (IRs) during the compilation process. An intermediate representation refers to the internal representation generated after the compilation process scans the source program; it represents the semantic and syntactic structure of the source program. Each stage of the compilation process analyzes or optimizes the IR. In the actual compilation process, from the start of the code compilation stage until the generation of the target executable file, multiple progressive intermediate representations can be generated according to the compilation flow.

[0064] The pointer attribute annotation module 310 completes the pointer attribute annotations for all pointer definition statements in the source program.

[0065] In one example, when used to solve problems other than space-class memory safety, such as time-class memory safety problems caused by memory access due to pointer calls, which typically include freeing and reuse, memory leaks, and double freeing, the pointer attribute information generated by pointer attribute annotations can also be used to solve the necessary information needed to solve these problems.

[0066] The statement insertion module 320 selects potentially risky statements involving memory operations during the compilation process and inserts pointer check statements before all potentially risky statements. During the insertion process, if necessary, pointer attribute storage can be established through pointer attribute storage statements, and a direct mapping between pointer attribute storage statements and inserted pointer check statements can be implemented. After the insertion of the check statements is completed, the pointer attribute annotations need to be deleted.

[0067] In one example, three different check statements need to be designed during the compilation process to address three checking requirements: null checks, upper bound checks, and lower bound checks. These check statements should be in single-instruction format, executed in a branchless manner, and must conform to the semantic and syntactic rules supported by the compiler. The compilation process should detect risky statements that access memory using pointers and insert the designed check statements before each such risky statement.

[0068] compared to Figure 1 The code compilation and optimization process, the check statement insertion module added pointer attribute storage submodule 321 and pointer attribute mapping submodule 322 during the compilation stage.

[0069] In one example, the pointer attribute storage submodule 321 creates pointer attribute storage statements, forming an intermediate representation of the compilation process, and stores the pointer attribute information identified by the pointer attribute annotation.

[0070] In one example, the pointer attribute mapping submodule 322 associates the inserted check statement with the pointer attribute storage statement to achieve a correct mapping between the pointer check statement and the pointer attribute information.

[0071] The code optimization module 330, while ensuring functional equivalence, optimizes the source program, inserted check statements, and inserted pointer attribute storage statements to reduce runtime and space consumption, thereby improving the functionality of the target code. The code optimization module 330 comprises three parts: a conventional code optimization submodule 331, a check statement elimination submodule 332, and a pointer attribute elimination submodule 333. The conventional code optimization submodule 331 is used to perform intermediate representation conversions and redundant code optimization on source programs written in C or C-like languages.

[0072] compared to Figure 1 The code compilation and optimization process includes a code optimization module 330 that adds a check statement elimination submodule 332 and a pointer attribute elimination submodule 333 during the compilation stage.

[0073] In one example, the check statement elimination submodule 332 eliminates relevant redundant check statements through the design of a custom value range analysis and propagation algorithm and a custom partial redundancy algorithm.

[0074] In one example, the pointer attribute elimination submodule 333 eliminates redundant pointer attribute storage statements and pointer attribute variables that have lost their reference relationships through a customized dead code elimination algorithm. Pointer attribute storage statements store pointer attribute information, and pointer attribute variables are variables defined by these statements to represent pointer attributes. Pointer attribute storage statements associate pointer attribute information with the pointer's check statements. When a check statement for a pointer is eliminated due to redundancy, some pointer attribute variables defined by the pointer attribute storage statements become unusable, constituting dead code and also a form of redundancy. This application's solution further eliminates this redundancy during the compilation process.

[0075] The target code generation module 340 converts the remaining check statements in the optimized code into machine instructions, and combines them with the source program and pointer attribute storage statements after redundancy elimination to finally generate target code that can be supported by the terminal. The target code generation module 340 includes two parts: a check statement expansion submodule 341 and a regular code generation submodule 342. The regular code generation submodule 342 is used to finally convert the source program and pointer attribute storage statements after redundancy elimination into machine target code.

[0076] compared to Figure 1In the code compilation and optimization process, the target code generation module 340 adds a check statement expansion submodule 341 during the compilation stage, which is used to expand the check statements retained after redundancy elimination. The expansion process converts the check statements from single instruction format to branch instruction format. The single instruction format is a design statement executed without a branch structure, while the branch instruction format is a machine instruction executed with a branch structure, including a combination of comparison statements and jump statements.

[0077] By combining the outputs of the check statement expansion submodule 341 and the regular code generation submodule 342, a target executable file that meets the application requirements is obtained.

[0078] Next, based on Figure 3 The content here describes a memory security management scheme provided by an embodiment of this application.

[0079] Figure 4 This is a flowchart of a memory safety management method provided in an embodiment of this application. Figure 4 As shown, the method includes the following steps S401-S404, which are analyzed in detail below:

[0080] Step S401: Insert a check statement to check pointer attributes before the risk statement in the first program; the risk statement is the statement in the first program that calls a pointer to access memory, and the pointer attribute is the attribute of the pointer in the risk statement.

[0081] In this embodiment, firstly, based on user requirements, a first program needs to be obtained on the hardware platform using C or a C-like language, written according to the application scheme. This first program is... Figure 3 The source program described herein can be on a standalone PC, a network-connected server, or any user-readable input terminal platform capable of C or C-like language editing. In the first program obtained through editing, due to the extensive use of pointer operations, improper pointer access could potentially lead to destructive access to memory, severely impacting the program's security and reliability.

[0082] Based on this first program, it needs to be compiled. To compile the first program, a centralized development environment can be used to implement the editing and compilation process of the first program on the same platform, or the first program can be edited on one platform and then connected to the compilation environment on another platform.

[0083] In one example, based on the first program, a pointer attribute annotation statement is added after the pointer definition statement manually or in a compilation environment. First, the pointer attributes are extracted through the syntax and lexical analysis techniques that match the pointer attribute annotation statement. Then, the pointer attribute storage statement stores the pointer attributes. The pointer attributes refer to the necessary information required for spatial memory safety checks, such as the length, boundary, upper bound address of the memory space, and lower bound address of the memory space pointed to by the pointer, which are obtained through the lexical and syntactic analysis of the implicit information in the first program. For example Figure 3 as shown, the storage of the pointer attribute information is completed by the pointer attribute storage sub-module 321.

[0084] Generally speaking, it is necessary to insert a pointer annotation statement for obtaining pointer attributes and a pointer attribute storage statement for storing each pointer information after each pointer definition statement in the first program. The inserted pointer attribute storage statement is the first custom statement recognizable in the compilation process.

[0085] In one example, to ensure the security of memory access, after inserting the pointer attribute storage statement, it is necessary to find the risk statements generated by memory access using pointers in the first program through the compilation environment and insert a check statement about the pointer before the risk statements. The check object of the check statement is the pointer used in the risk statement. The inserted check statement is the second custom statement recognizable in the compilation process. To facilitate the optimization of redundant code, the check statement is usually designed in a single-instruction format and executed in the order of execution. The single-instruction format is manifested in that a custom check statement is designed to represent a check rule, compared with Figure 1 the way of using one comparison instruction plus one jump instruction to represent a check rule in the code compilation and optimization process scheme of, the check statement in the single-instruction format has the significant advantage of not changing the CFG, not affecting the code optimization technology, and thus significantly reducing the performance overhead of the target executable file. In addition, the risk statements represent those execution statements that may have spatial memory safety. To ensure the security of memory access, it is necessary to insert a check statement before these risk statements are executed. It can be understood that the risk statements can represent memory access statements, memory access statements involving pointer operations, and pointer operation statements.

[0086] In the process of inserting the check statement, a direct mapping between the check statement and the pointer attribute storage statement is adopted. The direct mapping is manifested in that the check range used in the created check statement is determined by the variables representing the pointer attribute information defined in the pointer attribute storage statement and the pointer attributes stored in the pointer attribute storage statement. This direct mapping has the significant advantage of extremely small memory overhead compared with the table building and table lookup methods usually adopted in the prior art. For example Figure 3As shown, the direct mapping between the check statement and the pointer attribute storage statement is completed by the pointer attribute mapping submodule 322. When implementing the mapping, for a specific pointer, such as pointer P, a risky statement that executes memory access on pointer P is found. A null check statement, check(p!=null), is inserted into the risky statement. The pointer attributes of pointer P before the execution of the risky statement are found. The relevant space information about pointer P contained in the pointer attribute storage statement that stores the pointer attributes is mapped to the calling parameters of the check statement.

[0087] During compilation, after the insertion check statements are completed, the pointer attribute annotation statements added to the code are deleted.

[0088] Step S402: Redundant code elimination is performed on the first converted program and the checking statement respectively to obtain the first eliminated program and the second eliminated program; wherein, the first converted program is an intermediate representation generated by compiling the first program.

[0089] In one example, the program with added pointer attribute storage statements and custom type single instruction format checks is brought into this stage. In a typical code optimization process, the checks are treated as "pseudocode." Without changing the original logic of the first program, a conventional code optimization scheme is used to compile the first program according to the syntax and semantic analysis rules defined in the compilation process, generating an intermediate representation during compilation to obtain the first transformed program. This first transformed program is then subjected to redundancy optimization to obtain the first eliminated version of the first transformed program. For example... Figure 3 As shown, this routine code optimization process is completed by the routine code optimization submodule 331. This routine code optimization process and... Figure 1 The code compilation and optimization process in the solution is similar to the processing and effect of the source program, and will not be described in detail here.

[0090] Furthermore, it can also be combined with Figure 3 The check statement insertion module 320 treats the check statement as an auxiliary statement of the first program, adds logical relationships associated with the check statement, and adapts conventional code optimization techniques to achieve a deeper elimination purpose. This research direction is not the focus of this application and will not be elaborated here.

[0091] In one example, the pointer attribute storage statement is a custom statement inserted during compilation. The syntax of this custom statement can be consistent with languages ​​like C or C-like languages. Since this custom statement is simply a variable definition statement—for example, defining pointer attribute variables p_lower and p_upper, adding the pointer attribute storage statement after the annotation statement, p_lower = p, p_upper = p + 100—it will not affect the regular optimization process of the first program. Alternatively, the syntax of this custom statement can also be inconsistent with languages ​​like C or C-like languages. In this case, during the regular code optimization process of the first program, it can be treated as "pseudocode," just like the checking statement. In this embodiment, for ease of description, the syntax of this custom statement is considered to be consistent with languages ​​like C or C-like languages. During the regular code optimization phase, it does not affect the code optimization of the first program. It can be understood that if the syntax of this custom statement is inconsistent with languages ​​like C or C-like languages, it will be treated as "pseudocode" during the regular code optimization phase. In either case, it will not affect the regular code optimization result of the first program.

[0092] In this embodiment, redundant code in the check statements is eliminated using a customized value range analysis and propagation algorithm, resulting in a third eliminated program. A customized partial redundancy elimination algorithm further eliminates redundant code in the check statements within the third eliminated program, resulting in a second eliminated program. A customized dead code elimination algorithm eliminates pointer attribute storage statements and pointer attribute variables that have a direct mapping to the eliminated check statements, resulting in a fourth eliminated program, as detailed below:

[0093] Generally speaking, redundant code can be divided into full redundancy and partial redundancy based on control flow relationship, and into identical redundancy and partial order redundancy based on inclusion relationship. In the process of checking statement elimination, a customized design of redundancy optimization algorithm is carried out for these redundant codes.

[0094] For the four types of redundant check statements that may exist in the check program, namely full redundancy, partial redundancy, identical redundancy and partial order redundancy, customized optimization algorithms are designed for deep elimination.

[0095] First, a customized VRAP algorithm is designed and implemented to eliminate completely identical redundancy and completely partially ordered redundancy. This is achieved by solving and propagating the value range of each checked statement to confirm its compliance with the conditions. If the condition is guaranteed to be met, the checked statement is either completely identical or completely partially ordered and is deleted. If the condition is guaranteed not to be met, a security issue will definitely occur, resulting in a static check and error report, providing debugging information to developers to assist in debugging and modification. If the condition cannot be confirmed, the checked statement is retained at runtime for real-time dynamic monitoring, and the value range information can be updated based on the checked range.

[0096] The following will combine Figures 5a-5b The customized VRAP algorithm provided in the embodiments of this application is described, wherein,

[0097] Figure 5a This is a flowchart illustrating a conventional VRAP algorithm processing method provided in an embodiment of this application. Figure 5b This is a flowchart of a customized VRAP algorithm processing method provided in an embodiment of this application.

[0098] In one example, for a piece of program code that inserts check statements, such as Figure 5a As shown, the redundancy check process using the conventional VRAP algorithm is as follows: The range of variable i is determined, conditional judgments are performed, and redundant branches are deleted, such as... Figure 5b As shown, the redundancy check process using the customized VRAP algorithm is as follows: confirm whether the requirements are met; if they are definitely met, delete the redundant check; if they are definitely not met, issue a static error; if they are not necessarily met, update the value range according to the check statement.

[0099] In summary, this application provides a customized value range analysis and propagation algorithm to eliminate check statements. The customization is mainly reflected in the following: "judging the check object and check range of the check statement" instead of "judging the comparison result of the comparison statement", and "deleting the check statement and updating the value range of the check object" instead of "deleting the comparison statement and updating the value range of the comparison object".

[0100] Secondly, the PRE algorithm is designed and implemented to eliminate partial redundancy and partial partial order redundancy: The check pointer object is treated as the key of the hash function. All check statements are hashed. When two check statements with the same key are encountered, their check ranges are compared to determine if they represent the same relationship, a partial order relationship, or a non-satisfied relationship. Then, based on the principles of correctness, security, computational optimality, and optimal lifespan, it is determined whether it is partially redundant. If it is a partially redundant same or partial order relationship, the check statement is redundant, and part of its path is deleted by lifting the check statement. If it is a partially redundant non-satisfied relationship, a security problem will definitely occur, and a static check will report an error, providing debugging information to developers to assist in debugging and modification. In other cases, the check statement is retained until runtime for real-time monitoring.

[0101] The following will combine Figures 6a-6b The customized PRE algorithm provided in the embodiments of this application is described, wherein,

[0102] Figure 6a This is a flowchart illustrating a conventional PRE algorithm processing method provided in an embodiment of this application. Figure 6bThis is a flowchart of a customized PRE algorithm processing method provided in an embodiment of this application.

[0103] In one example, such as Figure 6a As shown, for the redundancy scenarios addressed by the conventional PRE algorithm: Figure 6a In the middle (a), all calculations are redundant. Deleting the a+b operation in the left branch will not have any impact. The previous calculation result c will be used to replace a+b. Figure 6a In the middle (b), there is partial redundant calculation. The left branch only performs the a+b operation once and there is no redundancy. The right branch has redundant calculation. Since the function requires each branch to perform the a+b operation once, the core idea of ​​elimination is to make each branch only have the a+b operation once. Figure 6a In case (c), the common cyclic redundancy can be classified as a special case of partially redundant computation. That is, due to the different number of iterations, the number of times a+b is executed on different paths is different. When a+b is executed once and the loop is exited, there is no redundant computation. However, after entering the loop, redundant computation will occur.

[0104] from Figure 6a As can be seen, eliminating partial redundancy a+b involves various operations such as renaming, insertion, deletion, and moving. If variables c and d have some kind of relationship, different branches assign different values ​​to c or d, or branches and loops overlap, the calculation becomes extremely complex.

[0105] To ensure computational accuracy and the positive effects of optimization, the following four basic principles must be met simultaneously during the partial redundancy elimination process:

[0106] (1) Correctness: Only delete a+b on the redundant path of a+b to ensure that no mistakes are made;

[0107] (2) Security: a+b is only inserted on the original path where a+b was executed, ensuring that no extra insertions are made;

[0108] (3) Computational optimization: No matter what execution path the actual input data takes, there will be no fewer a+b calculations;

[0109] (4) Optimal lifespan (minimum register pressure): In Figure 6a (b) and Figure 6a Based on (c), minimize a+b

[0110] The later the register cycle is stored, the better.

[0111] Following the four principles mentioned above, operations such as renaming, inserting, deleting, and moving of a+b are implemented. Three flags are designed: DownSafe (ds), CanBeAvailable (cba), and Later (later). These three flags are calculated sequentially along the code, and corresponding operations are performed based on the calculation results. The table below lists the core flags of the conventional PRE algorithm:

[0112]

[0113] like Figure 6b As shown, the customized PRE algorithm is designed for redundant scenarios. Figure 6b In the three methods (b), (c), and (d), check(i) is used as the key of the hash. check(i < len1) and check(i < len2) will be regarded as the same hash object. After obtaining the same hash relationship, the inclusion relationship of the check range between the two is confirmed: if len1 == len2, it is the same relationship; if len1 < len2, then check(i < len2) must be satisfied if check(i < len1) is satisfied, which is a partial order relationship; if len1 > len2, then check(i < len2) may not be satisfied if check(i < len1) is satisfied, which is a non-redundant relationship. Then, the principles of correctness, security, computational optimality, and life cycle optimality are combined to determine whether it is partially redundant.

[0114] In one example, regarding the above Figure 6a The meanings of the four basic principles in the document are modified as follows:

[0115] (1) Correctness: Only delete check(i<len) on the redundant path of check(i<len) to ensure that no error is deleted;

[0116] (2) Security: Only insert check(i<len) on the original path where check(i<len) was executed, ensuring that no extra checks are inserted;

[0117] (3) Computational optimization: No matter what execution path the actual input data takes, there will be no fewer checks;

[0118] (4) Optimal lifecycle (minimum register pressure): This principle is removed because it does not involve register storage.

[0119] Accordingly, the flag calculation method is modified to implement the check statement, i.e., the renaming, insertion, deletion, and movement operations of the check instruction. The table below lists the core flags of the customized PRE algorithm:

[0120]

[0121] In summary, this application provides a customized partial redundancy elimination algorithm to eliminate check statements. The customization is mainly reflected in the following aspects: "hashing the check objects in the check statement" replaces "hashing the entire expression", and "comparing different check ranges of the same check object can eliminate the same redundancy and partial order redundancy" replaces "comparing the same statement can only eliminate the same redundancy".

[0122] Finally, a custom DCE algorithm was designed and implemented to eliminate redundant pointer attributes, which refer to pointer attribute storage statements and pointer attribute variables that are no longer valuable. Pointer attribute variables are defined in pointer attribute storage statements (called definition points) and used in check statements (called use points). After a large number of redundant check statements are eliminated, many pointer attribute storage statements and pointer attribute variables no longer have use points and are therefore worthless, becoming dead code that requires further redundancy elimination.

[0123] Figure 7 This is a flowchart of a conventional DCE algorithm processing method provided in an embodiment of this application. The following will be combined with... Figure 7 The customized DCE algorithm provided in the embodiments of this application is described as follows: Figure 7 As shown, in the conventional DCE algorithm, reverse data flow analysis is performed to determine if a variable is no longer used; otherwise, it is considered useless. In the customized DCE algorithm, although the implementation principle is the same as the conventional DCE algorithm, the target audience is different. The target audience is redundant pointer attribute storage statements and pointer attribute variables. This application provides designed check statements and pointer attribute storage statements to support the customization of this DCE algorithm.

[0124] As above, as Figure 3 As shown, the elimination of redundant check statements is completed by the check statement elimination submodule 332, and the elimination of redundant pointer attribute storage statements is completed by the pointer attribute elimination submodule 333. During the above execution process, the check statement elimination submodule 332 can be executed after the regular code optimization submodule 331 has finished executing, or it can be executed synchronously with the regular code optimization submodule 331; no specific configuration is made here.

[0125] In one example, the static debug file generated during the execution of the code optimization module 330 can be fed back to the program developers, and the developers can be received to modify the source code, inspection statements, pointer attribute assignment statements, pointer attribute variables, etc. Generally, the static debug file can be a compilation error generated by the regular code optimization submodule 331 in performing syntax and semantic transformation and redundant code optimization on the first program, including syntax errors, memory access errors, command line errors, etc., or it can be an optimization logic error, syntax error, etc. generated during the process of the redundancy elimination submodule 332 in eliminating redundant inspection statements and the pointer attribute elimination submodule 333 in eliminating redundant pointer attribute storage statements.

[0126] Step S403: The second eliminated program is subjected to machine instruction conversion during the compilation process to obtain the second converted program.

[0127] Step S404: Based at least on the second converted program and the first eliminated program, generate a target executable file; wherein, the target executable file is used to generate fault information at runtime, and the fault information includes the pointer attribute of the pointer in the first risk statement, and the first risk statement is one of the risk statements in the first program.

[0128] After eliminating redundant code in the first transformed program and check statements, such as Figure 3 As shown, each check statement is expanded into a combination of a comparison and a jump by the check statement expansion submodule 341, resulting in the second transformed program.

[0129] Since the fourth elimination program, generated after redundancy elimination of pointer attribute storage statements and pointer attribute variables, is also part of the target executable file, it is necessary to add the fourth elimination program before generating the target executable file. Then, based on the second conversion program, the second elimination program, and the fourth elimination program, a binary code with pointer checking function is generated.

[0130] In one example, a dynamic debug file generated by the target executable at runtime can be fed back to the program developers, and modifications made by the developers to the source code, inspection statements, pointer attribute assignment statements, pointer attribute variables, etc., can be received. The dynamic debug file contains fault information caused by memory access through pointer calls, including the location of the risky statement, the pointer execution code that caused the fault, pointer attributes, pointer out-of-bounds types, etc.

[0131] Figure 8 This is a flowchart of source program compilation provided in an embodiment of this application. The execution process of the code in the source program according to steps S401-S404 is described in detail below:

[0132] The intermediate program is derived from the source program; the source program is a program written according to the application scheme; the intermediate program includes the source program, pointer attribute storage statements that store pointer attributes in the source program, pointer attribute variables defined in the pointer attribute storage statements, and checking statements that check pointer attributes in risk statements; among them, pointer attributes include the length and boundary information of the memory block pointed to by the pointer, and risk statements are statements in the source program that use pointers to access memory.

[0133] The source program is converted into an intermediate representation generated during the compilation process, resulting in the first converted program.

[0134] Redundant code is eliminated from the first converted program to obtain the first eliminated program.

[0135] The redundant code in the checked statements is eliminated by a customized value range analysis and propagation algorithm, resulting in the third eliminated program. The redundant code in the third eliminated program is further eliminated by a customized partial redundancy elimination algorithm, resulting in the second eliminated program.

[0136] The custom dead code elimination algorithm eliminates redundant code that has lost its reference relationship in pointer attribute storage statements and pointer attribute variables, resulting in the fourth eliminated program. The redundant code that has lost its reference relationship refers to pointer attribute storage statements and pointer attribute variables that have a direct mapping to the redundant code in the check statements. This direct mapping maps the pointer attribute variables and stored pointer attributes contained in the redundant code that has lost its reference relationship to the check scope of the redundant code in the check statements.

[0137] The machine instructions of the second eliminated program are converted during the compilation process to obtain the second converted program.

[0138] In one example, during the compilation process of the intermediate program, apart from requiring the redundancy elimination of pointer attribute storage statements and pointer attribute variables to be performed after the redundancy elimination of check statements, there are no special requirements for the execution order of other actions. For example, the compilation transformation and regular code optimization of the source program, and the redundancy elimination and execution order transformation of check statements can be performed simultaneously or sequentially. Changing the execution order of the two will not affect the final compilation result.

[0139] Based on the second conversion program, the first elimination program, and the fourth elimination program, the target executable file is generated.

[0140] Figure 9 This is an implementation architecture diagram of a memory safety management method provided in an embodiment of this application, such as... Figure 9As shown, a modified integrated development process is designed, with compiler 900 and graphical user interface 910 optimizing the source code. After developers complete the source code writing and modification in the source code writing submodule 921 of editor 920, check statements are inserted before risky statements through two submodules: pointer attribute storage submodule 901 and pointer attribute mapping submodule 902. After passing through three submodules: regular code optimization submodule 903, check statement elimination submodule 904, and pointer attribute elimination submodule 905, binary code containing check functions is obtained through check statement expansion submodule 806 and regular code generation submodule 907. At the same time, some static check error information is obtained and passed to developers through interactive error reporting and debugging submodule 911 in graphical user interface 910 to assist them in debugging and modification. When the binary code is input into the actual execution environment, security issues can be checked in real time based on real-time input information, and the obtained debugging information is passed to maintenance personnel to assist them in code debugging.

[0141] To achieve low-overhead, high-security detection of memory safety issues in space-based systems, refer to... Figure 4 Memory safety management methods, Figure 10 This is a flowchart of a memory safety management method provided in an embodiment of this application, such as... Figure 10 As shown, the implementation steps S1000-S1008 are described in detail below:

[0142] Step S1000: Extract pointer attribute information from the source program through lexical and syntactic analysis.

[0143] Step S1001: Create pointer attribute variables and pointer attribute storage statements to store pointer attribute information.

[0144] Step S1002: Design a single-instruction format check statement using pointer attribute variables and insert the check statement before risky statements such as memory access statements.

[0145] Step S1003: Use conventional code optimization techniques to perform performance tuning.

[0146] Step S1004: Use a customized VRAP algorithm to eliminate check statements that are completely identical or partially redundant, and perform static checks to report errors.

[0147] Step S1005: Use a customized PRE algorithm to eliminate some identical and partially redundant check statements, and perform static checks to report errors.

[0148] Step S1006: Use a customized DCE algorithm to eliminate redundant pointer attribute storage statements that are not used.

[0149] Step S1007: Expand each check statement into a combination of a comparison instruction and a jump instruction.

[0150] Step S1008: Combine the code obtained by performing conventional code optimization on the source program to generate the target executable code.

[0151] Figure 11 This is an implementation architecture diagram of a memory safety management method provided in an embodiment of this application, such as... Figure 11 As shown, this is a modified compiler with optimized designs for its front-end, middle-end, and back-end components. First, the front-end module 1100 includes a pointer attribute storage submodule 1101 and a pointer attribute mapping submodule 1102, used to store pointer attributes and establish correct mappings between pointer attributes and checking statements. The middle-end module 1110 includes a regular code optimization submodule 1111, a checking statement elimination submodule 1112, and a pointer attribute elimination submodule 1113. In the middle-end module 1110, static error results are output to developers as debugging information to assist them in debugging and modifying the code. The back-end module 1120 includes a checking statement expansion submodule 1121 and a regular code generation submodule 1122, used to expand the designed single-instruction format checking statements into combinations of comparison instructions and jump instructions. This results in binary code with checking functionality. When this binary code runs in a real execution environment, it can provide debugging information to maintenance personnel to assist them in debugging and modification. (Except for the module division and connection method...) Figure 9 The real-time architecture diagram shown is different; the specific operations of each step are different. Figure 10 The descriptions in the flowcharts shown are consistent and will not be repeated here.

[0152] Figure 12 This is an implementation architecture diagram of a memory safety management method provided in an embodiment of this application, such as... Figure 12 As shown, this is a modified program analysis tool that includes both static and dynamic analysis. The static analysis module 1200 contains five submodules: pointer attribute storage submodule 1201, pointer attribute mapping submodule 1202, regular code optimization submodule 1203, check statement elimination submodule 1204, and pointer attribute elimination submodule 1205. This achieves correct mapping between pointer attributes and check statements, eliminating redundant check statements while outputting static error results as debugging information to developers to assist in code debugging and modification. The dynamic analysis module 1210 contains a check statement expansion submodule 1211 and a regular code generation submodule 1212. It generates binary code with checking functionality, which, along with simulated test cases, is input into the simulation execution environment to generate error information, which is then output to developers to assist in code debugging and modification. (The module division and connection method are different from...) Figure 9 The real-time architecture diagram shown is different; the specific operations of each step are different. Figure 10 The descriptions in the flowcharts shown are consistent and will not be repeated here.

[0153] Based on the methods in the above embodiments, this application also provides a memory security management device.

[0154] Figure 13 This is a schematic diagram of the hardware structure of a memory security management device provided in an embodiment of this application. Figure 13 As shown, the memory security management device 1300 includes: a processing module 1301, the specific functions of which are described below:

[0155] Processing module 1301 inserts a check statement for checking pointer attributes before the risk statement in the first program. The risk statement is the statement in the first program that calls a pointer to access memory, and the pointer attribute is the attribute of the pointer in the risk statement.

[0156] The processing module 1301 also performs redundant code elimination on the first converted program and the checking statement respectively to obtain the first eliminated program and the second eliminated program; wherein, the first converted program is an intermediate representation generated by compiling the first program.

[0157] The processing module 1301 also performs machine instruction conversion during the compilation process on the second eliminated program to obtain the second converted program.

[0158] The processing module 1301 further generates a target executable file based at least on the second converted program and the first eliminated program; wherein the target executable file is used to generate fault information at runtime, and the fault information includes the pointer attribute of the pointer in the first risk statement, and the first risk statement is one of the risk statements in the first program.

[0159] In some embodiments, when the processing module 1301 performs redundant code elimination on the first converted program and the checking statements, it eliminates all identical redundant code and all partially ordered redundant code in the checking statements by judging the checking objects and checking scope, thus obtaining a third eliminated program; the checking objects and checking scope of the checking statements are at least based on risk statements. By hashing the checking objects of the checking statements in the third eliminated program, some identical redundant code and some partially ordered redundant code in the third eliminated program are eliminated, thus obtaining a second eliminated program.

[0160] In some embodiments, when the processing module 1301 inserts a check statement for checking pointer attributes before a risk statement in the first program, it inserts a label statement after the pointer definition statement in the first program; the label statement is used to obtain the pointer attributes of the pointer in the risk statement; a pointer attribute storage statement is inserted after the label statement; the pointer attribute storage statement is used to store the pointer attributes obtained by the label statement, and the pointer attribute storage statement contains pointer attribute variables, which are variables used to represent pointer attributes; the pointer attribute storage statement is a first user-defined statement recognizable by the compilation process; based on the risk statement and the pointer attribute storage statement, a check statement for checking the pointer attributes of the risk statement is determined; wherein, the risk statement is used to determine the object of the check statement, and the pointer attribute variables contained in the pointer attribute storage statement and the pointer attributes stored in the pointer attribute storage statement are used to determine the scope of the check statement; wherein, the check statement is a second user-defined statement recognizable by the compilation process; and a check statement for checking pointer attributes is inserted before the risk statement.

[0161] In some embodiments, after the processing module 1301 performs redundant code elimination on the first converted program and the checking statement, it eliminates the redundant code in the pointer attribute storage statement and eliminates the pointer attribute variables contained in the redundant code in the pointer attribute storage statement to obtain the fourth eliminated program; wherein, the pointer attributes stored in the redundant code in the pointer attribute storage statement and the pointer attribute variables contained in the redundant code in the pointer attribute storage statement are used to determine the checking range of the redundant code in the checking statement; when the processing module 1301 generates the target executable file based at least on the second converted program and the first eliminated program, it is used to: generate the target executable file based on the second converted program, the first eliminated program and the fourth eliminated program.

[0162] In some embodiments, the first program is a program written in C or a C-like language.

[0163] Figure 14 This is a schematic diagram of the hardware structure of a memory security management device provided in an embodiment of this application. The network device 1400 can be the aforementioned memory security management device. Figure 14 As shown, the network device 1400 includes a processor 1410, a memory 1420, a communication interface 1430, and a bus 1440. The processor 1410, memory 1420, and communication interface 1430 are interconnected via the bus 1440. The processor 1410, memory 1420, and communication interface 1430 can also be connected using other connection methods besides the bus 1440.

[0164] The memory 1420 can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), flash memory, optical storage, hard disk, etc.

[0165] The processor 1410 may be a general-purpose processor, which can be a processor that performs specific steps and / or operations by reading and executing contents stored in memory (e.g., memory 1420). For example, the general-purpose processor may be a central processing unit (CPU). The processor 1410 may include at least one circuit to perform... Figure 4 or Figure 9 The illustrated embodiments provide all or part of the steps of the memory security management method.

[0166] The communication interface 1430 includes input / output (I / O) interfaces, physical interfaces, and logical interfaces for interconnecting devices within the network device 1400, as well as interfaces for interconnecting the network device 1400 with other devices (such as other network devices or user equipment). The physical interface can be an Ethernet interface, a fiber optic interface, an ATM interface, etc.

[0167] The bus 1440 can be any type of communication bus used to interconnect the processor 1410, memory 1420 and communication interface 1430, such as a system bus.

[0168] The aforementioned devices can be disposed on separate chips, or at least partially or entirely on the same chip. Whether to dispose of the devices independently on different chips or integrate them on one or more chips often depends on the needs of the product design. This application does not limit the specific implementation of the aforementioned devices.

[0169] Figure 14 The network device 1400 shown is merely an example. In the implementation process, the network 1400 may also include other components, which will not be listed here.

[0170] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of the present invention is generated. 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, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0171] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. It should be understood that in the embodiments of this application, the order of the process numbers does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0172] The above specific embodiments further illustrate the purpose, technical solution and beneficial effects of this application. It should be understood that the above are only specific embodiments of the present invention and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this application should be included within the scope of protection of this application.

Claims

1. A memory safety management method, characterized by, The method includes: A check statement for checking pointer attributes is inserted before the risk statement in the first program; the risk statement is the statement in the first program that calls a pointer to access memory, the pointer attribute is the attribute of the pointer in the risk statement, the risk statement is used to determine the object to be checked by the check statement, the scope of the check statement is determined based on the pointer attribute, and the pointer attribute is stored through a pointer attribute storage statement inserted in the first program; Redundant code is eliminated from the first converted program and the checking statement respectively to obtain a first eliminated program and a second eliminated program; wherein, the first converted program is an intermediate representation generated by compiling the first program; The second eliminated program is subjected to machine instruction conversion during the compilation process to obtain the second converted program; A target executable file is generated based at least on the second converted program and the first eliminated program; wherein, the target executable file is used to generate fault information at runtime, and the fault information includes the pointer attribute of the pointer in the first risk statement, the first risk statement being one of the risk statements in the first program.

2. The method of claim 1, wherein, The process of eliminating redundant code in the first converted program and the checking statement includes: By judging the inspection object and inspection scope of the inspection statement, all identical redundant code and all partially ordered redundant code in the inspection statement are eliminated to obtain the third eliminated program; the inspection object and inspection scope of the inspection statement are at least based on the risk statement. By hashing the checked objects of the check statements in the third elimination program, some identical redundant code and some partial order redundant code in the third elimination program are eliminated, resulting in the second elimination program.

3. The method of claim 1, wherein, The insertion of a check statement to check pointer attributes before the risk statement in the first program includes: A labeling statement is inserted after the pointer definition statement in the first program; the labeling statement is used to obtain the pointer attribute of the pointer in the risk statement. A pointer attribute storage statement is inserted after the annotation statement; the pointer attribute storage statement is used to store the pointer attributes obtained by the annotation statement, the pointer attribute storage statement contains pointer attribute variables, the pointer attribute variables are variables used to represent pointer attributes; the pointer attribute storage statement is the first user-defined statement that can be recognized by the compilation process. Based on the risk statement and the pointer attribute storage statement, a checking statement is determined to perform pointer attribute checks on the risk statement; wherein, the risk statement is used to determine the object of the checking statement, and the pointer attribute variables contained in the pointer attribute storage statement and the pointer attributes stored in the pointer attribute storage statement are used to determine the scope of the checking statement; wherein, the checking statement is a second user-defined statement that can be recognized by the compilation process. Insert a check statement to check pointer properties before the risk statement.

4. The method of claim 3, wherein, After performing redundant code elimination on the first converted program and the checking statement respectively, the method further includes: The redundant code in the pointer attribute storage statement is eliminated, and the pointer attribute variables contained in the redundant code in the pointer attribute storage statement are eliminated to obtain the fourth eliminated program; wherein, the pointer attributes stored in the redundant code in the pointer attribute storage statement and the pointer attribute variables contained in the redundant code in the pointer attribute storage statement are used to determine the inspection scope of the redundant code in the inspection statement. The step of generating a target executable file based at least on the second converted program and the first eliminated program includes: Based on the second converted program, the first eliminated program, and the fourth eliminated program, a target executable file is generated.

5. The method according to any of claims 1 to 4, characterized in that, The first program is written in C or a C-like language.

6. A memory safety management device, comprising: The device includes: The processing module is used to insert a check statement for checking pointer attributes before the risk statement in the first program; the risk statement is a statement in the first program that calls a pointer to access memory, the pointer attribute is the attribute of the pointer in the risk statement, the risk statement is used to determine the object to be checked by the check statement, the scope of the check statement is determined based on the pointer attribute, and the pointer attribute is stored through a pointer attribute storage statement inserted in the first program. The processing module is further configured to perform redundant code elimination on the first converted program and the checking statement respectively, to obtain a first eliminated program and a second eliminated program; wherein, the first converted program is an intermediate representation generated by compiling the first program; The processing module is also used to perform machine instruction conversion during the compilation process on the second eliminated program to obtain the second converted program; The processing module is further configured to generate a target executable file based at least on the second converted program and the first eliminated program; wherein the target executable file is configured to generate fault information at runtime, the fault information including the pointer attribute of the pointer in the first risk statement, the first risk statement being one of the risk statements in the first program.

7. The apparatus of claim 6, wherein, When the processing module performs redundant code elimination on the first converted program and the checking statement respectively, it is used for: By judging the inspection object and inspection scope of the inspection statement, the completely identical redundant code and completely partial order redundant code in the inspection statement are eliminated to obtain the third eliminated program. The objects and scope of the inspection statements are obtained at least based on the risk statements; By hashing the checked objects of the check statements in the third elimination program, some identical redundant code and some partial order redundant code in the third elimination program are eliminated, resulting in the second elimination program.

8. The device according to claim 6, characterized in that, When the processing module inserts a check statement to check pointer attributes before the risk statement in the first program, it is used for: A labeling statement is inserted after the pointer definition statement in the first program; the labeling statement is used to obtain the pointer attribute of the pointer in the risk statement. A pointer attribute storage statement is inserted after the annotation statement; the pointer attribute storage statement is used to store the pointer attributes obtained by the annotation statement, the pointer attribute storage statement contains pointer attribute variables, the pointer attribute variables are variables used to represent pointer attributes; the pointer attribute storage statement is the first user-defined statement that can be recognized by the compilation process. Based on the risk statement and the pointer attribute storage statement, a checking statement is determined to perform pointer attribute checks on the risk statement; wherein, the risk statement is used to determine the object of the checking statement, and the pointer attribute variables contained in the pointer attribute storage statement and the pointer attributes stored in the pointer attribute storage statement are used to determine the scope of the checking statement; wherein, the checking statement is a second user-defined statement that can be recognized by the compilation process. Insert a check statement to check pointer properties before the risk statement.

9. The apparatus of claim 8, wherein, After the processing module performs redundant code elimination on the first converted program and the checking statement, it is used for: The redundant code in the pointer attribute storage statement is eliminated, and the pointer attribute variables contained in the redundant code in the pointer attribute storage statement are eliminated to obtain the fourth eliminated program; wherein, the pointer attributes stored in the redundant code in the pointer attribute storage statement and the pointer attribute variables contained in the redundant code in the pointer attribute storage statement are used to determine the inspection scope of the redundant code in the inspection statement. When the processing module generates a target executable file based at least on the second converted program and the first eliminated program, it is used to: generate a target executable file based on the second converted program, the first eliminated program, and the fourth eliminated program.

10. The apparatus of any of claims 6-9, wherein, The first program is written in C or a C-like language.

11. An electronic device, comprising: include: At least one memory for storing a program; at least one processor for executing the program stored in the memory; wherein, when the program stored in the memory is executed, the processor is configured to perform the method as described in any one of claims 1-5.

12. A computer-readable storage medium, characterized in that, Includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-5.

13. A computer program product, characterised in that, Includes program code that, when a computer runs the computer program product, causes the computer to perform the method as described in any one of claims 1-5.

Images