WO2024113831A1 - Memory security management method and device - Google Patents

Abstract

Disclosed is a memory security management method, comprising: inserting a test statement for checking a pointer attribute before a risk statement in a first program, wherein the risk statement is a statement for calling a pointer to perform memory access in the first program, and the pointer attribute is an attribute of the pointer in the risk statement; separately performing redundant code elimination on a first converted program and the test statement 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; converting, on the second eliminated program, a machine instruction in a compiling process to obtain a second converted program; and generating a target execution file at least on the basis of the second converted program and the first eliminated program. According to the method, in the compiling process, redundancy optimization is performed on the first program before the test statement performs compiling conversion, so that the code optimization performance in the compiling process can be improved.

Description

A memory security management method and device

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on November 30, 2022, with application number 202211535703.5 and application name “A memory security management method and device”, the entire contents of which are incorporated by reference in this application.

Technical Field

The present application relates to the field of memory management technology, and in particular to a memory security management method and device.

Background technique

In applications written in C or C-like languages, pointers are usually used to achieve flexible access to memory resources. However, if developers use pointers improperly, it will also bring security risks to memory management. The hidden dangers of using pointers to access memory in applications are mainly reflected in spatial memory safety issues, such as null pointer dereference, out-of-bounds read, out-of-bounds write, etc.

At present, the solution to the spatial memory safety problem is mainly to modify the source program, manually add some pointer attribute information, use this information to insert check statements when the program is compiled, and perform error processing when the program is running. However, since these inserted check statements are first converted into machine instructions with branch structures during the compilation process, the introduction of these branch structures complicates the logical relationship of the source program, greatly affects the optimization effect of the source program when eliminating redundant code, and brings a large runtime overhead of the application. For some overhead-sensitive fields, such as WiFi chips, routers, etc., it is unacceptable.

Summary of the invention

The present application provides a memory security management method and device, which can improve the optimization effect of the source program during the compilation process, make the runtime overhead of the target executable file within the controllable range of the terminal, and enhance the user experience of using the terminal application.

In the first aspect, the present application provides a memory safety management method. The method includes: inserting a check statement for checking pointer attributes before a risk statement in a first program; the risk statement is a statement in the first program that calls a pointer for memory access, and the pointer attribute is the attribute of the pointer in the risk 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 execution file based on at least the second converted program and the first eliminated program; wherein the target execution 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.

Therefore, by changing the compilation conversion process of the check statement, the redundant code of the first converted program is first eliminated, and then the check statement is implemented with the conversion of machine instructions in the compilation process. Thus, in the redundant code elimination stage of the compilation process, the logical relationship structure of the first converted program is not changed, thereby improving the optimization effect of the first converted program in the compilation process.

In one possible implementation, redundant code elimination is performed on the first converted program and the check statement respectively, including: by determining the check object and the check range of the check statement, all identical redundant codes and all partially-ordered redundant codes in the check statement are eliminated to obtain a third eliminated program; the check object and the check range of the check statement are obtained based on at least the risk statement; by hashing the check object of the check statement in the third eliminated program, part of the identical redundant codes and part of the partially-ordered redundant codes in the third eliminated program are eliminated to obtain a second eliminated program.

Therefore, during the compilation process, redundant code elimination is also implemented for check statements, further improving the overall optimization effect of the target executable file and effectively reducing the runtime overhead of the application.

In a possible implementation, a check statement for checking pointer attributes is inserted before a risk statement in a first program, including: inserting a label statement after a pointer definition statement in the first program; the label statement is used to obtain pointer attributes of a pointer in the risk statement; inserting a pointer attribute storage statement after the label statement; the pointer attribute storage statement is used to save 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 custom statement recognizable by the compilation process; based on the risk statement and the pointer attribute storage statement, a check statement for performing pointer attribute check on the risk statement is determined; wherein the risk statement is used to determine a check object of the check statement, and the pointer attribute variables contained in the pointer attribute storage statement and the pointer attributes saved in the pointer attribute storage statement are used to determine a check scope of the check statement; wherein the check statement is a second custom statement recognizable by the compilation process; and inserting a check statement for checking pointer attributes before the risk statement.

Therefore, by storing pointer attributes in real time and establishing a connection between pointer attribute storage statements and check statements, the correctness of pointer attributes used in check statements can be maintained, underreporting can be reduced, and more complete security assurance capabilities can be provided.

In a possible implementation, after eliminating redundant codes from the first converted program and the check statement respectively, the method further includes: eliminating redundant codes in the pointer attribute storage statement and eliminating pointer attribute variables contained in the redundant codes in the pointer attribute storage statement to obtain a fourth eliminated program; wherein the pointer attributes stored in the redundant codes in the pointer attribute storage statement and the pointer attribute variables contained in the redundant codes in the pointer attribute storage statement are used to determine the inspection scope of the redundant codes in the check statement; generating a target execution file based on at least the second converted program and the first eliminated program, including: generating a target execution file based on the second converted program, the first eliminated program and the fourth eliminated program.

Therefore, during the compilation process, redundant code elimination is also implemented 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.

In a possible implementation manner, the first program is a program written in C or a C-like language.

In a second aspect, the present application provides a memory safety management device. The device includes: a processing module, which is used to insert a check statement for checking pointer attributes before a risk statement in a first program; the risk statement is a statement in the first program that calls a pointer for memory access, and the pointer attribute is the attribute of the pointer in the risk statement; the processing module is also used to eliminate redundant code from 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; the processing module is also used to implement the conversion of machine instructions during the compilation process on the second eliminated program, to obtain a second converted program; the processing module is also used to generate a target execution file based on at least the second converted program and the first eliminated program; wherein the target execution 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.

In one possible implementation, when the processing module performs redundant code elimination on the first converted program and the check statement respectively, it is used to: eliminate all identical redundant codes and all partially ordered redundant codes in the check statement by judging the check object and the check range of the check statement to obtain a third eliminated program; the check object and the check range of the check statement are obtained based on at least the risk statement; and eliminate part of the identical redundant codes and part of the partially ordered redundant codes in the third eliminated program by hashing the check object of the check statement in the third eliminated program to obtain a second eliminated program.

In a possible implementation, when the processing module inserts a check statement for checking pointer attributes before a risk statement in a first program, it is used to: insert a label statement after a pointer definition statement of the first program; the label statement is used to obtain the pointer attributes of the pointer in the risk statement; insert a pointer attribute storage statement after the label statement; the pointer attribute storage statement is used to save 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 custom statement recognizable by the compilation process; based on the risk statement and the pointer attribute storage statement, a check statement for performing a pointer attribute check on the risk statement is determined; wherein the risk statement is used to determine the check object of the check statement, and the pointer attribute variables contained in the pointer attribute storage statement and the pointer attributes saved in the pointer attribute storage statement are used to determine the check scope of the check statement; wherein the check statement is a second custom statement recognizable by the compilation process; and the check statement for checking pointer attributes is inserted before the risk statement.

In a possible implementation, after the processing module eliminates redundant codes from the first converted program and the check statement respectively, the processing module is used to: eliminate the redundant codes in the pointer attribute storage statement, and eliminate the pointer attribute variables contained in the redundant codes in the pointer attribute storage statement, to obtain a fourth eliminated program; wherein the pointer attributes stored in the redundant codes in the pointer attribute storage statement, and the pointer attribute variables contained in the redundant codes in the pointer attribute storage statement, are used to determine the inspection scope of the redundant codes in the check statement; when the processing module generates a target executable file based on at least the second converted program and the first eliminated program, the processing module is used to: generate a target executable file based on the second converted program, the first eliminated program, and the fourth eliminated program.

In a possible implementation manner, the first program is a program written in C or a C-like language.

In a third aspect, the present application provides an electronic device comprising: at least one memory for storing programs; and at least one processor for executing programs 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 of the first aspect.

In a fourth aspect, the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method described in the first aspect or any possible implementation of the first aspect.

In a fifth aspect, the present application provides a computer program product. When the computer program product runs on a processor, the processor executes the method described in the first aspect or any possible implementation of the first aspect.

It can be understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of a process of code compilation and optimization using a branch structure form check statement;

Fig. 2 is a control flow chart after checking the converted sentence structure;

FIG3 is a system architecture diagram of a memory security management method provided in an embodiment of the present application;

FIG4 is a flow chart of a memory security management method provided in an embodiment of the present application;

FIG5a is a flow chart of a conventional VRAP algorithm processing provided by an embodiment of the present application;

FIG5 b is a flowchart of a customized VRAP algorithm processing provided in an embodiment of the present application;

FIG6a is a flowchart of a conventional PRE algorithm processing provided by an embodiment of the present application;

FIG6 b is a flowchart of a customized PRE algorithm processing provided in an embodiment of the present application;

FIG7 is a flow chart of a conventional DCE algorithm processing provided by an embodiment of the present application;

FIG8 is a flow chart of a source program compilation provided by an embodiment of the present application;

FIG9 is an implementation architecture diagram of a memory security management method provided in an embodiment of the present application;

FIG10 is a flowchart of a memory security management method provided in an embodiment of the present application;

FIG11 is an implementation architecture diagram of a memory security management method provided in an embodiment of the present application;

FIG12 is an implementation architecture diagram of a memory security management method provided in an embodiment of the present application;

13 is a schematic diagram of the hardware structure of a memory security management device provided in an embodiment of the present application;

FIG. 14 is a schematic diagram of the hardware structure of a memory security management device provided in an embodiment of the present application.

Detailed ways

In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings.

In the description of the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples or illustrations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

In the description of the embodiments of the present application, the term "and/or" is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and/or B may represent: A exists alone, B exists alone, and A and B exist at the same time. In addition, unless otherwise specified, the term "multiple" means two or more. For example, multiple systems refers to two or more systems, and multiple screen terminals refers to two or more screen terminals.

In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. The terms "include", "comprises", "has" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

In order to solve the potential memory security management risks that may arise when memory operations are performed through pointers and pointer operations in applications written in C or C-like languages, such as null pointer dereference, out-of-bounds read, out-of-bounds write, etc., it is necessary to locate and optimize suspicious pointers as much as possible during program compilation and debugging, and output relevant information about error pointers when the program is running, including the location of the error pointer in the application, the error type of the error pointer, the error form of the error pointer, etc., to facilitate developers and operation and maintenance personnel to debug, modify and maintain the application. Among them, C-like languages refer to languages that perform memory operations through pointers and pointer operations like C.

Figure 1 is a schematic diagram of the process of code compilation and optimization using branch structure form check statements. As shown in Figure 1, based on the design and implementation principles of the application solution, the developer uses C or C-like language to write the source program to implement the application solution. A large number of application pointers in this source program implement the access and reading and writing of the terminal memory. In order to eliminate the potential space memory security management risks that may arise from the interaction between pointers and memory as much as possible, in an optional technical solution, the following steps need to be performed:

Step S100, determine the intermediate program, which includes the check statement and source program inserted before the pointer memory access risk statement. The execution of these risky statements may bring pointer space memory security risks. Step S100 may specifically include the following sub-steps S101-S103:

Step S101, write the source program according to the requirements of the application solution, and perform pointer attribute annotation on all statements using pointers in the source program. 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), indicating that the length of the memory block pointed to by pointer p is n. In the subsequent compilation stage, the compiler provides supporting lexical and semantic analysis to extract the information represented by the pointer attribute annotation, such as: the length of the memory block pointed to by p is 5, and the boundary is [p, p+5).

Step S102, in the source program with added pointer attribute annotations, search for risk statements that use pointers to access memory, and insert check statements before these risk statements. As mentioned above, space-based memory safety mainly includes three categories: null pointer dereference, out-of-bounds read, and out-of-bounds write. In order to eliminate the hidden dangers that may be caused by pointers, it is necessary to insert a null check statement before the memory access risk statement where null pointer dereference may occur. For example, insert a common null check statement, check(p!=null), which indicates the check of pointer access to memory space. For the two types of problems of out-of-bounds read and out-of-bounds write, it is necessary to insert an out-of-bounds check before the pointer's memory access risk statement. For example, insert a common out-of-bounds check statement, check(p>=p), which indicates the check of pointer access to the lower bound, and check(p<p+5), which indicates the check of pointer access to the upper bound. If a pointer has both dereference risks and out-of-bounds risks, it is necessary to insert a null check statement first, and then continue to insert an out-of-bounds check statement. Therefore, by inserting check statements to describe whether the determined conditions are met, the space memory problems that may be caused by the pointers used in the program are checked. The above-mentioned check statements appear in the source program in the form of "pseudocode", which is a custom statement format that can be recognized by the compilation process.

Step S103, after the compilation process extracts the information indicated by the pointer attribute annotation, the pointer attribute annotation is removed to obtain the check statement and source program including the pointer to form an intermediate program.

Thus, the intermediate program is determined, which includes the check statements inserted at the pointer memory access points and the source program, and then the compilation phase of the intermediate program is entered.

Step S110, using compilation technology to perform intermediate conversion of the compilation process, redundant code optimization, and target code generation on the intermediate program with the check statement inserted. For common compilation technology, in order to make the intermediate program meet the compilation requirements, it is necessary to perform code conversion on the intermediate program after the check statement is inserted according to grammatical and semantic rules in the early stage of compilation. For the check statement, a common conversion method is to convert it into a machine instruction combination of conventional comparison instructions and jump instructions. This conversion expands the check statement from a branchless single instruction structure to a branch execution structure, thereby causing a great change in the logical structure of the source program in the intermediate program.

FIG2 is a control flow graph after the check statement structure is converted. As shown in FIG2, in the control flow graph (CFG), the check statements check(i<upper) and check(j<upper) in the form of "pseudocode" are respectively inserted into the pointers p[i] and p[j] used in the source program. In the early stage of compilation, the check statements are converted into a combination of conventional comparison instructions cmp and jump instructions jump according to syntax and semantics, so that the check statements present a branch mode.

Then, in the mid-stage of compilation, the optimization algorithm is used to optimize the redundant code, and in the late stage of compilation, the target code is generated, and finally a binary target execution file with check statements is formed for technical personnel to debug, modify and maintain the code. For example, when the check instruction is triggered to meet the conditions during the runtime of the target execution file, the execution program will show a core dump problem caused by the jump exit operation, and the program will terminate. Developers can use the debug information in the binary file output by the program termination to restore the diagnostic information for debugging. The diagnostic information includes the line number and column number of the diagnosed program.

Among them, several code optimization algorithms that may be involved in the mid-stage of compilation are introduced as follows:

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

Partial redundancy elimination (PRE) is a code optimization algorithm that eliminates redundant expressions by using the hash result of expressions in such partial redundancy scenarios.

Dead code elimination (DCE) is a code optimization algorithm that deletes codes that have no effect on the program's running results.

However, the method of compiling and optimizing code by checking statements in the form of branch structures shown in FIG1 above has great deficiencies and loopholes in practical applications, mainly for the following reasons:

First, in order to achieve perfect memory safety, it is necessary to insert a check statement before all risky statements that use pointers to access memory. The amount of insertion is very large, which is positively correlated with the proportion of memory access statements in the code, and will bring a large program runtime overhead; and, since these inserted check statements are based on branch forms for redundant checks and code optimization during the compilation process, they greatly affect the compilation and optimization effect of the source program, and further bring greater program runtime overhead. The introduction of branch-form check statements makes the control flow graph extremely complex, and the original code optimization technology cannot play a role during the compilation process. In step S110, in the early stage of compilation, the intermediate program after the insertion of the check statement is uniformly converted according to the requirements of syntax and semantics, including the conversion of the branch mode of the check statement, which will make the control flow graph complex. As shown in Figure 2, each inserted check statement will bring an extra node and an extra path, and code optimization algorithms such as VRAP, PRE, and DCE all rely on pattern matching under CFG. Under complex CFG, the original code optimization mode is no longer valid and cannot play the original optimization role, resulting in a greatly reduced optimization effect, and in the later stage of compilation, the target executable file finally generated is extremely bloated, and cannot be widely used in terminal systems with limited memory resources.

In view of this, an embodiment of the present application provides a memory safety management method. In this method, the check statements and other codes in the intermediate program are stripped, and the step of converting the check statements from a single instruction structure to a branch structure machine instruction based on grammatical and semantic rules in the early stage of compilation is postponed to the later stage of compilation for code generation. In the redundant code generation process in the mid-stage of compilation, based on the check statements inserted in a single instruction manner, a customized VRAP, PRE, and DCE code optimization algorithm is used to eliminate redundancy and optimize the code of the source program and the inserted check statements in the CFG, which can effectively reduce the impact of the inserted check statements on the redundant optimization of the source program, so that the consumption of memory resources by the target execution file finally generated is controlled within a reasonable range, and the runtime overhead is significantly reduced.

Secondly, the cross-statement propagation of pointer attributes is not considered, and the mapping between the check statement and the pointer attribute is wrong, resulting in missed reports. Although the pointer attributes in the source program are marked in step S101, thereby obtaining the length and boundary function of the memory area pointed to by the pointer, the boundary is not stored and updated in real time, so that the boundary attributes obtained when the subsequent check statement is checked are still the old version. The old version of the boundary information is brought into the check statement, which will lead to invalid checks and then missed reports. For example, when declaring pointer p, its length is marked as 5, and it can be known that the length of the memory block pointed to by pointer p is [p, p+5). When accessing the memory area pointed to by p, an out-of-bounds check is required. The out-of-bounds check statement is: check(p>=p), and the out-of-bounds check statement is: check(p<p+5). When checking the 0th element of the first memory block pointed to by pointer p, the out-of-bounds behavior of the upper and lower bounds can be detected. However, if the pointer p is incremented later in the program, when the memory area pointed to by pointer p is accessed again, pointer p will already 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 actual program has already exceeded the upper bound, but it cannot be found through the check statement.

In view of this, the embodiment of the present application provides a pointer attribute storage statement, stores the results of pointer attribute annotation in real time, and establishes a direct mapping between pointer attributes and check statements, which can maintain the correctness of pointer attributes used in check statements, reduce underreporting, and provide more complete security capabilities. In addition, according to the results of redundancy elimination of the check statement, the pointer attribute storage statement can also be redundancy eliminated, further improving the effect of eliminating redundant code.

FIG3 is a system architecture diagram of a memory safety management method provided by an embodiment of the present application. As shown in FIG3 , the system architecture diagram includes five parts: a language definition module 300, a pointer attribute annotation module 310, a check statement insertion module 320, a code optimization module 330, and a target code generation module 340. The specific functions of each module are described as follows:

The language definition module 300 describes the source program, pointer attribute annotations, pointer attribute storage statements, check statements, and the syntax and semantic rules of various intermediate representations (IR) during the compilation process. Among them, the intermediate representation refers to the internal representation generated after the compilation process scans the source program, representing the semantic and grammatical structure of the source program. Each stage of the compilation process is analyzed or optimized on the IR. In the actual compilation process, from the beginning of the code compilation stage until the target execution file is generated, multiple progressive intermediate representations can be generated according to the compilation process.

The pointer attribute annotation module 310 completes the pointer attribute annotations of all pointer definition statements in the source program.

In one example, when used to solve other problems besides spatial memory safety, such as temporal memory safety problems caused by calling pointers to perform memory access, which usually include use after free, memory leaks, repeated releases, etc., the pointer attribute information generated by pointer attribute annotation can also be used to provide the necessary information needed to solve such problems.

The check statement insertion module 320 selects potential risk statements involving memory operations during the compilation process, and inserts pointer check statements before all potential risk statements. During the insertion process, if necessary, pointer attribute storage statements can also be used to establish pointer attribute storage, as well as to implement direct mapping between pointer attribute storage statements and inserted pointer check statements. After completing the insertion of the check statement, the pointer attribute annotation needs to be deleted.

In one example, three check statements need to be designed for the three check requirements of null, crossing the upper bound, and crossing the lower bound during the compilation process. These check statements are in single instruction format and are executed in a branchless structure. At the same time, they must comply with the semantic and grammatical rules supported by the compilation process. During the compilation process, risky statements that use pointers to access memory are detected, and designed check statements are inserted before each risky statement.

Compared with the code compilation and optimization process of FIG. 1 , the check statement insertion module adds a pointer attribute storage submodule 321 and a pointer attribute mapping submodule 322 during the compilation stage.

In one example, the pointer attribute storage submodule 321 creates a pointer attribute storage statement to form an intermediate representation of the compilation process, and stores the pointer attribute information identified by the pointer attribute annotation.

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

The code optimization module 330 optimizes the source program, the inserted check statements, and the inserted pointer attribute storage statements to shorten the running time and occupy less space, etc., under the premise of ensuring functional equivalence, so as to achieve functional improvement of the target code. The code optimization module 330 includes three parts: a conventional code optimization submodule 331, a check statement elimination submodule 332, and a pointer attribute elimination submodule 333. Among them, the conventional code optimization submodule 331 is used to convert the intermediate representation of the source program written in C or C-like language during the programming process, and optimize the redundant code.

Compared with the code compilation and optimization process of FIG. 1 , the code optimization module 330 adds a check statement elimination submodule 332 and a pointer attribute elimination submodule 333 during the compilation phase.

In one example, the check statement elimination submodule 332 eliminates relevant redundant check statements by designing a customized value range analysis and propagation algorithm and a customized partial redundancy algorithm.

In one example, the pointer attribute elimination submodule 333 eliminates redundant pointer attribute storage statements and pointer attribute variables that have lost reference relationships through the design of a customized dead code elimination algorithm. The pointer attribute storage statement is used to store pointer attribute information, and the pointer attribute variable is a variable defined by the pointer attribute storage statement, which is used to represent the attributes of the pointer. The pointer attribute storage statement associates the pointer attribute information with the check statement of the pointer. When a check statement of the pointer is eliminated due to redundancy, some pointer attribute variables defined by the pointer attribute storage statement have no usage points, which are dead codes and also a kind of redundancy. The present application solution further eliminates this redundancy during the compilation process.

The target code generation module 340 converts the check statements retained in the optimized code into machine instructions, and combines 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 a check statement expansion submodule 341 and a regular code generation submodule 342, wherein 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.

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

The output results of the inspection statement expansion submodule 341 and the conventional code generation submodule 342 are combined to obtain a target execution file that meets the application requirements.

Next, based on the content in Figure 3, a memory security management solution provided in an embodiment of the present application is introduced.

FIG4 is a flow chart of a memory security management method provided by an embodiment of the present application. As shown in FIG4 , the method includes the following steps S401-S404, which are specifically analyzed as follows:

Step S401, inserting a check statement for checking pointer attributes before a risk statement in the first program; the risk statement is a statement in the first program that calls a pointer for memory access, and the pointer attribute is an attribute of the pointer in the risk statement.

In this embodiment, firstly, according to user needs, a first program written according to the application scheme needs to be obtained based on C or C-like language editing on a hardware platform, the first program being the source program described in FIG3 , and the hardware platform can be an independent PC, a server connected to the network, or any user input terminal platform that can be edited in C or C-like language. In the first program obtained by editing, since a large number of pointer operations are used, when using pointers for memory access, destructive access to the memory space may be caused due to improper pointer operations, thereby seriously affecting the security and reliability of the program.

Based on the first program, it is necessary to make the first program enter the compilation phase. In order to compile the first program, a centralized development environment can be used to centrally implement the editing and compiling processes of the first program on the same platform, or the editing of the first program can be implemented on one platform. The edited first program is connected to a compilation environment on another platform.

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 attribute is extracted by the syntax and lexical analysis technology matched with the pointer attribute annotation statement, and then the pointer attribute storage statement is used to store the pointer attribute. The pointer attribute refers to the length, boundary, upper boundary address of the memory space, lower boundary address of the memory space, etc. of the memory block pointed to by the pointer, which is necessary information required for the space class memory security check, and is obtained by the lexical and grammatical analysis of the implicit information in the first program. As shown in FIG3 , the storage of the pointer attribute information is completed by the pointer attribute storage submodule 321.

Generally speaking, after each pointer definition statement of each pointer in the first program, a pointer annotation statement for obtaining pointer attributes and a pointer attribute storage statement for storing each pointer information need to be inserted. The inserted pointer attribute storage statement is the first custom statement recognizable by the compilation process.

In one example, in order to ensure the security of memory access, after implementing the insertion of pointer attribute storage statements, it is necessary to find the risk statements generated by using pointers for memory access in the first program through the compilation environment, and insert the pointer check statement before the risk statement. The check object of the check statement is the pointer used in the risk statement. The inserted check statement is the second custom statement that can be identified by the compilation process. In order to facilitate the optimization of redundant code, the check statement is usually designed in a single instruction format and executed in a sequential manner. The single instruction format is manifested in that a custom check statement is designed to represent a check rule. Compared with the method of using a comparison instruction plus a jump instruction to represent a check rule in the code compilation and optimization process scheme of Figure 1, the check statement in the single instruction format has the significant advantages of not changing CFG, not affecting code optimization technology, and thus greatly reducing the performance overhead of the target execution file. In addition, the risk statement represents those execution statements that may have spatial memory safety. In order to ensure the security of memory access, it is necessary to insert the check statement before the execution of these risk statements. It can be understood that the risk statement can represent a memory access statement, a memory access statement involving pointer operations, and a pointer operation statement.

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 variable used to represent the pointer attribute information defined in the pointer attribute storage statement and the pointer attribute stored in the pointer attribute storage statement. Compared with the table building and table lookup methods commonly used in the prior art, this direct mapping has a significant advantage of extremely low memory overhead. As shown in FIG3 , 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 risk statement for executing the pointer P to perform memory access is found, and a null check statement, check(p!=null), is inserted into the risk statement to find the pointer attribute of the pointer P before executing the risk statement, and the relevant space information about the pointer P contained in the pointer attribute storage statement storing the pointer attribute is mapped as the call parameter of the check statement.

During the compilation process, after the insertion of the check statement is completed, the pointer attribute annotation statement added to the code is deleted.

Step S402, 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.

In one example, a program after adding a pointer attribute storage statement and a check statement of a user-defined type single instruction format is brought into this link. In a conventional code optimization process, the check statement is regarded as "pseudocode". Without changing the original logic of the first program, a conventional code optimization scheme is adopted to compile the first program according to the grammatical and semantic analysis rules defined in the compilation process, generate an intermediate representation in the compilation process, obtain a first converted program, and perform redundancy optimization on the first converted program to obtain a first eliminated program of the first converted program. As shown in FIG3 , the conventional code optimization process is completed by a conventional code optimization submodule 331. The conventional code optimization process and the code compilation and optimization process scheme in FIG1 are similar in processing and processing effects on the source program, and are not described in detail here.

Furthermore, the check statement insertion module 320 in Figure 3 can also be combined to regard the check statement as an auxiliary statement of the first program, add the logical relationship associated with the check statement, and adapt the conventional code optimization technology to achieve a deeper elimination purpose. This research direction is not the focus of this application and will not be elaborated here.

In one example, the pointer attribute storage statement is a custom statement inserted during the compilation process. The syntax format of this custom statement can be consistent with C or C-like languages. Since this custom statement is only a type of variable definition statement, for example, to define pointer attribute variables p_lower and p_upper, add the pointer attribute storage statement after the annotation statement, p_lower=p, p_upper=p+100, so it will not affect the regular optimization process of the first program. In addition, the syntax format of this custom statement can also be inconsistent with C or C-like languages. In this case, in the regular code optimization process of the first program, it can be regarded as "pseudocode" like the check statement. In this embodiment, for the convenience of description, the syntax format of this custom statement is regarded as consistent with C or C-like languages. In the regular code optimization stage, it does not affect the code optimization of the first program. It can be understood that if the syntax format of this custom statement is inconsistent with C or C-like languages, it will be regarded as "pseudocode" when the first program is optimized in the regular code optimization stage. In either case, it will not affect the regular code optimization result of the first program.

In this embodiment, redundant codes in the check statements are eliminated according to the customized value range analysis and propagation algorithm to obtain a third eliminated program. According to the customized partial redundancy elimination algorithm, redundant codes in the check statements in the third eliminated program are further eliminated to obtain a second eliminated program. According to the customized dead code elimination algorithm, pointer attribute storage statements and pointer attribute variables that are directly mapped to the eliminated check statements are eliminated to obtain a fourth eliminated program, which is specifically described as follows:

Generally speaking, redundant codes can be divided into full redundancy and partial redundancy according to the control flow relationship, and can be divided into identical redundancy and partial order redundancy according to the inclusion relationship. In the process of checking statement elimination, customized design of redundant optimization algorithms is performed for these redundant codes.

Aiming at the four kinds of redundant check statements, namely full redundancy, partial redundancy, identical redundancy and partial order redundancy, which may exist in the check program, customized optimization algorithms are designed for deep elimination.

First, a customized VRAP algorithm is designed and implemented to eliminate all identical redundancy and all partial order redundancy. The check statement is confirmed to meet the conditions by solving and propagating the value range of each checked statement. If it is definitely satisfied, then this check statement is all identical redundancy or all partial order redundancy and is deleted; if it is definitely not satisfied, then there will definitely be a security problem, and a static check error will be reported, providing debugging information to the developer to assist in debugging and modification; if it is impossible to confirm whether it is satisfied, then the check statement will be retained until the runtime stage for real-time dynamic monitoring, and the value range information can be updated according to the inspection range.

The customized VRAP algorithm provided in the embodiment of the present application will be described below in conjunction with FIGS. 5a-5b , wherein:

FIG. 5 a is a flowchart of a conventional VRAP algorithm processing provided in an embodiment of the present application, and FIG. 5 b is a flowchart of a customized VRAP algorithm processing provided in an embodiment of the present application.

In one example, for a program code with a check statement inserted, as shown in FIG5a , the redundancy check process of the conventional VRAP algorithm is used: the value range of the variable i is obtained, conditional judgment is performed, and redundant branches are deleted. As shown in FIG5b , the redundancy check process of the customized VRAP algorithm is used: confirm whether the requirements are met, if they are definitely met, the redundant check is deleted, if they are definitely not met, a static error is reported, and if they are not necessarily met, the value range is updated according to the check statement.

In summary, the present application provides a customized value range analysis and propagation algorithm to achieve the elimination of check statements. The customization is mainly reflected in: "judging the inspection object and inspection scope of the check statement" replaces "judging the comparison result of the comparison statement", and "deleting the check statement and updating the value range of the check object at the same time" replaces "deleting the comparison statement and updating the value range of the comparison object at the same time".

Secondly, design and implement the PRE algorithm to eliminate partial identical redundancy and partial partial order redundancy: treat the check pointer object as the keyword of the hash, hash all the check statements, and when encountering two check statements with the same keyword, judge the check range of the two to confirm whether it is the same relationship, partial order relationship or unsatisfied relationship, and then combine the principles of correctness, security, computational optimality, and life cycle optimality to determine whether it is partial redundancy. If it is the same relationship or partial order relationship under partial redundancy, then this check statement is redundant, and some paths are deleted by lifting the check statement; if it is an unsatisfied relationship under partial redundancy, there will definitely be security issues, and static check errors will be reported, providing debugging information to developers to assist them in debugging and modification; if it is other cases, the check statement will be retained until the runtime link for real-time monitoring.

The customized PRE algorithm provided in the embodiment of the present application will be described below in conjunction with FIG. 6a-6b, wherein:

FIG. 6 a is a flowchart of a conventional PRE algorithm processing provided in an embodiment of the present application, and FIG. 6 b is a flowchart of a customized PRE algorithm processing provided in an embodiment of the present application.

In an example, as shown in FIG6a , for the redundant scenarios faced by the conventional PRE algorithm: FIG6a (a) belongs to a fully redundant calculation. Deleting the a+b operation of the left branch will not have any effect, and the previous calculation result c is used to replace a+b; FIG6a (b) belongs to a partially redundant calculation. The left branch only executes the a+b operation once, and there is no redundancy. The right branch has redundant calculations. Since each branch needs to execute the a+b operation once, the core idea of eliminating it is to make each branch only have one a+b operation; FIG6a (c) is a common cyclic redundancy, which can be attributed to a special case of partially redundant calculations, that is, due to different loop times, the execution times of a+b on different paths are different. When a+b is executed once and the loop is exited, there is no redundant calculation, but after entering the loop, redundant calculation will be generated.

As can be seen from Figure 6a, the elimination of partial redundancy a+b requires various operations such as renaming, inserting, deleting, and moving. If there is a certain connection between variables c and d, different branches assign different values to c or d, and branches and loops are superimposed, the calculation will become very complicated.

In order to ensure the correctness of calculations and the positive effects of execution optimization, the following four basic principles must be met simultaneously during the process of partial redundancy elimination:

(1) Correctness: a+b is deleted only on the redundant path of a+b to ensure that no mistakes are made.

(2) Security: a+b is only inserted on the path where a+b is originally executed, ensuring that no more than one insertion occurs.

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

(4) Optimal life cycle (minimum register pressure): Based on (b) in Figure 6a and (c) in Figure 6a, minimize the register pressure of a+b storage.

The later the storage, the better.

Follow the above four principles to implement the renaming, insertion, deletion, and movement of a+b: design three flags: DownSafe (ds), CanBeAvail (cba), and Later (later). Calculate the three flags in the code sequence and perform corresponding operations based on the calculation results. The following table lists the core flags of the conventional PRE algorithm:

As shown in FIG6b , the customized PRE algorithm targets the redundant scenarios (b), (c), and (d) in FIG6b . With check(i) as the hash keyword, check(i<len1) and check(i<len2) are 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 if check(i<len1) is satisfied, then check(i<len2) must be satisfied, which is a partial order relationship. If len1>len2, then if check(i<len1) is satisfied, then check(i<len2) may not be 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 partial redundancy.

In one example, the meanings of the four basic principles in FIG. 6a above are modified as follows:

(1) Correctness: check(i<len) is only deleted on the path where check(i<len) is redundant to ensure that no mistakes are made.

(2) Safety: check(i<len) is only inserted on the path where check(i<len) is originally executed to ensure that no more than one check(i<len) is inserted.

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

(4) Optimal life cycle (minimum register pressure): This principle is deleted because it does not involve register storage.

Accordingly, the flag bit solving method is modified to implement the check statement, that is, the renaming, insertion, deletion, and movement of the check instruction. The following table lists the core flag bits of the customized PRE algorithm:

In summary, the present application provides a customized partial redundancy elimination algorithm to achieve the elimination of check statements. The customization is mainly reflected in: "hashing the check object in the check statement" replaces "hashing the entire expression", and "comparing different check ranges of the same check object to eliminate the same redundancy and partial order redundancy" replaces "comparing the same statement to only eliminate the same redundancy".

Finally, a customized DCE algorithm is designed and implemented to eliminate redundant pointer attributes, which are 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 are no longer useful. There is no more usage point, so it has no value and becomes dead code, which needs further redundancy elimination.

FIG7 is a flow chart of a conventional DCE algorithm processing provided by an embodiment of the present application. The customized DCE algorithm provided by an embodiment of the present application will be described below in conjunction with FIG7. As shown in FIG7, in a conventional DCE algorithm, reverse data flow analysis is performed to determine that a variable is useless if it no longer has a use point. In a customized DCE algorithm, although the implementation principle is the same as that of a conventional DCE algorithm, the object-oriented is different, and the object-oriented is redundant pointer attribute storage statements and pointer attribute variables. The present application provides designed check statements and pointer attribute storage statements to support the customization of this DCE algorithm.

As shown in FIG3 , the elimination of redundant check statements is completed by the check statement elimination submodule 332, and then the elimination of redundant pointer attribute storage statements is completed by the pointer attribute elimination submodule 333. In the above execution process, the check statement elimination submodule 332 can be executed after the execution of the conventional code optimization submodule 331, or it can be executed synchronously with the conventional code optimization submodule 331, which is not set here.

In one example, the static debugging file generated during the execution of the code optimization module 330 can be fed back to the program developer, and the program developer's modifications to the source program, check statements, pointer attribute assignment statements, pointer attribute variables, etc. can be received. Generally speaking, the static debugging file can be the compilation errors generated by the regular code optimization submodule 331 when the first program is subjected to syntax, semantic conversion and redundant code optimization, including syntax errors, memory access errors, command line errors, etc., or can be the optimization logic errors, syntax errors, etc. generated during the redundant elimination of check statements by the design redundancy elimination submodule 332 and the redundant elimination of pointer attribute storage statements by the pointer attribute elimination submodule 333.

Step S403, converting the machine instructions in the compilation process on the second eliminated program to obtain a second converted program.

Step S404, 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 risk statement, and the first risk statement is one of the risk statements in the first program.

After eliminating the redundant codes of the first converted program and the check statements, as shown in FIG3 , each check statement is expanded into a combination of a comparison and a jump by the check statement expansion submodule 341 to obtain a second converted program.

Since the fourth elimination program generated after redundant elimination of pointer attribute storage statements and pointer attribute variables is also a part of generating the target execution file, the fourth elimination program needs to be added before generating the target execution file, and then, based on the second converted program, the second eliminated program and the fourth eliminated program, a binary code containing a pointer checking function is generated.

In one example, the dynamic debugging file generated by the target execution file during runtime can be fed back to the program developer, and the program developer's modifications to the source program, check statements, pointer attribute assignment statements, pointer attribute variables, etc. can be received. The dynamic debugging file contains fault information caused by calling pointers for memory access, including the location of risky statements, pointer execution code that generates faults, pointer attributes, pointer out-of-bounds types, etc.

FIG8 is a flowchart of a source program compilation provided by an embodiment of the present application, and the code in the source program is described according to the execution process of steps S401-S404, which is specifically described as follows:

An intermediate program is obtained based on a source program; a source program is a program written according to an application solution; the intermediate program includes a source program, a pointer attribute storage statement for storing pointer attributes of a pointer in the source program, pointer attribute variables defined in the pointer attribute storage statement, and a check statement for checking pointer attributes of a pointer in a risk statement; wherein the pointer attributes include the length and boundary information of a memory block pointed to by the pointer, and the risk statement is a statement in the source program that uses a pointer to access memory.

The source program is converted into an intermediate representation generated by a compilation process to obtain a first converted program.

Redundant codes are eliminated from the first converted program to obtain a first eliminated program.

According to the customized value range analysis and propagation algorithm, the redundant codes in the check statement are eliminated to obtain a third eliminated program. According to the customized partial redundancy elimination algorithm, the redundant codes existing in the third eliminated program are further eliminated to obtain a second eliminated program.

According to the customized dead code elimination algorithm, redundant codes that have lost reference relationships in pointer attribute storage statements and pointer attribute variables are eliminated to obtain a fourth eliminated program. The redundant codes that have lost reference relationships are pointer attribute storage statements and pointer attribute variables that are directly mapped to the redundant codes in the check statement, and the direct mapping maps the pointer attribute variables and the stored pointer attributes contained in the redundant codes that have lost reference relationships to the check range of the redundant codes in the check statement.

The second eliminated program is subjected to the conversion of the machine instructions in the compilation process to obtain a second converted program.

In one example, during the compilation of the intermediate program, except for 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 execution actions. For example, the source program is compiled and converted and the conventional code is optimized, and the redundancy elimination and execution order conversion of the check statements are performed. These two steps can be performed simultaneously or successively. Changing the execution order will not affect the final compilation result.

Based on the second post-conversion program, the first post-elimination program, and the fourth post-elimination program, a target execution file is generated.

FIG9 is an implementation architecture diagram of a memory safety management method provided by an embodiment of the present application. As shown in FIG9 , a modified integrated development link is designed, and the compiler 900 and the graphical user interface 910 are used to optimize the source program. After the developer completes the writing and modification of the source program in the source code writing submodule 921 of the editor 920, the two submodules of the pointer attribute storage submodule 901 and the pointer attribute mapping submodule 902 are used to insert the check statement before the risk statement; after the three submodules of the conventional code optimization submodule 903, the check statement elimination submodule 904 and the pointer attribute elimination submodule 905, the binary code containing the check function is obtained through the check statement expansion submodule 806 and the conventional code generation submodule 907; at the same time, some static check error information is obtained, which is passed to the developer through the interactive error reporting and debugging submodule 911 in the graphical user interface 910 to assist in debugging and modifying; the binary code is input into the real execution environment, and the security issues can be checked in real time according to the real-time input information, and the obtained debugging information is passed to the operation and maintenance personnel to assist in code debugging.

In order to achieve low-overhead and high-security space-based memory security problem detection, referring to the memory security management method of FIG. 4 , FIG. 10 is a flow chart of a memory security management method provided by an embodiment of the present application. As shown in FIG. 10 , steps S1000-S1008 are implemented, and each step is specifically described as follows:

Step S1000, extracting pointer attribute information in the source program through lexical and grammatical analysis.

Step S1001, creating a pointer attribute variable and a pointer attribute storage statement to store pointer attribute information.

Step S1002, designing a check statement in a single instruction format using pointer attribute variables, and inserting the check statement before risk statements such as memory access.

Step S1003: Calling conventional code optimization technology to perform performance tuning.

Step S1004, using a customized VRAP algorithm to eliminate all identical redundant and all partially redundant check statements, while performing static check errors.

Step S1005, using a customized PRE algorithm to eliminate partially identical redundant and partially partially redundant check statements, while performing static check error reporting.

Step S1006: Eliminate redundant pointer attribute storage statements without usage points using a customized DCE algorithm.

Step S1007, expand each check statement into a combination of a comparison instruction and a jump instruction.

Step S1008, generating target execution code by combining the code obtained by performing conventional code optimization processing on the source program.

Figure 11 is an implementation architecture diagram of a memory safety management method provided by an embodiment of the present application. As shown in Figure 11, it is a modified compiler, and its front-end, middle-end, and back-end parts are optimized and designed respectively. First, in the front-end module 1100, it includes a pointer attribute storage submodule 1101 and a pointer attribute mapping submodule 1102, which are used to store pointer attributes and establish the correct mapping of pointer attributes and check statements; in the middle-end module 1110, it includes a conventional code optimization submodule 1111, a check statement elimination submodule 1112, and a pointer attribute elimination submodule 1113. In the middle-end module 1110, the static error result is output to the developer in the form of debugging information to assist them in debugging and modifying the code; in the back-end module 1120, it includes a check statement expansion submodule 1121 and a conventional code generation submodule 1122, which are used to expand the designed single instruction format check statement into a combination of comparison instructions and jump instructions. Thus, a binary code containing a check function can be obtained. When the binary code is running in a real execution environment, debugging information can be provided to the operation and maintenance personnel to assist them in debugging and modifying. Except that the module division and connection method are different from the real-time architecture diagram shown in Figure 9, the specific operation of each step is consistent with the introduction in the flowchart shown in Figure 10, and will not be repeated here.

Figure 12 is an implementation architecture diagram of a memory safety management method provided by an embodiment of the present application. As shown in Figure 12, it is a modified program analysis tool, which includes two parts: static analysis and dynamic analysis. In the static analysis module 1200, it includes a pointer attribute storage submodule 1201, a pointer attribute mapping submodule 1202, a conventional code optimization submodule 1203, a check statement elimination submodule 1204, and a pointer attribute elimination submodule 1205. Five modules are implemented to achieve the correct mapping of pointer attributes and check statements. While eliminating redundant check statements, the static error report results can also be output to the developer in the form of debugging information to assist in debugging and modifying the code; in the dynamic analysis module 1210, it includes a check statement expansion submodule 1211 and a conventional code generation submodule 1212, which can generate binary code containing a check function, and then input it into the simulation execution environment together with the simulation case, and obtain some error information output to the developer to assist in debugging and modifying the code. Except that the module division and connection method are different from the real-time architecture diagram shown in Figure 9, the specific operation of each step is consistent with the introduction in the flow chart shown in Figure 10, and will not be repeated here.

Based on the method in the above embodiment, an embodiment of the present application also provides a memory security management device.

FIG13 is a schematic diagram of the hardware structure of a memory security management device provided in an embodiment of the present application. As shown in FIG13 , the memory security management device 1300 includes: a processing module 1301, and the specific module functions are described as follows:

The processing module 1301 inserts a check statement for checking pointer attributes before the risk statement in the first program. The risk statement is In a statement that calls a pointer to access memory, the pointer attributes are the attributes of the pointer in the risk statement.

The processing module 1301 also performs redundant code elimination on the first converted program and the check statement 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 1301 further performs conversion of machine instructions in the compilation process on the second eliminated program to obtain a second converted program.

The processing module 1301 also generates a target execution file based on at least the second converted program and the first eliminated program; wherein the target execution 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.

In some embodiments, when the processing module 1301 performs redundant code elimination on the first converted program and the check statement respectively, the check object and the check range of the check statement are judged, and the completely identical redundant code and the completely partial order redundant code in the check statement are eliminated to obtain the third eliminated program; the check object and the check range of the check statement are obtained based on at least the risk statement. By hashing the check object of the check statement in the third eliminated program, some identical redundant code and some partial order redundant code in the third eliminated program are eliminated to obtain the second eliminated program.

In some embodiments, when the processing module 1301 inserts a check statement for checking pointer attributes before the risk statement in the first program, a label statement is inserted after the pointer definition statement of 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 save 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 custom statement recognizable by the compilation process; based on the risk statement and the pointer attribute storage statement, a check statement for performing pointer attribute check on the risk statement is determined; wherein, the risk statement is used to determine the check object of the check statement, and the pointer attribute variables contained in the pointer attribute storage statement and the pointer attributes saved in the pointer attribute storage statement are used to determine the check scope of the check statement; wherein the check statement is a second custom statement recognizable by the compilation process; a check statement for checking pointer attributes is inserted before the risk statement.

In some embodiments, after the processing module 1301 eliminates redundant codes from the first converted program and the check statement respectively, it eliminates the redundant codes in the pointer attribute storage statement and the pointer attribute variables contained in the redundant codes in the pointer attribute storage statement to obtain a fourth eliminated program; wherein, the pointer attributes stored in the redundant codes in the pointer attribute storage statement and the pointer attribute variables contained in the redundant codes in the pointer attribute storage statement are used to determine the inspection scope of the redundant codes in the check statement; when the processing module 1301 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.

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

FIG14 is a schematic diagram of the hardware structure of a memory security management device provided in an embodiment of the present application. The network device 1400 may be the above-mentioned memory security management device. As shown in FIG14 , the network device 1400 includes a processor 1410, a memory 1420, a communication interface 1430, and a bus 1440, and the processor 1410, the memory 1420, and the communication interface 1430 are connected to each other via the bus 1440. The processor 1410, the memory 1420, and the communication interface 1430 may also be connected in other connection modes besides the bus 1440.

Among them, 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.

The processor 1410 may be a general-purpose processor, which may be a processor that performs specific steps and/or operations by reading and executing the contents stored in a 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 all or part of the steps of the memory security management method provided in the embodiment shown in FIG. 4 or FIG. 9.

The communication interface 1430 includes an input/output (I/O) interface, a physical interface, and a logical interface, etc., which are used to interconnect devices within the network device 1400, and an interface 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.

The bus 1440 may be any type of communication bus for interconnecting the processor 1410 , the memory 1420 , and the communication interface 1430 , such as a system bus.

The above devices may be arranged on independent chips, or at least partially or completely on the same chip. Whether to arrange each device independently on different chips or to integrate them on one or more chips often depends on the needs of product design. The embodiments of the present application do not limit the specific implementation form of the above devices.

The network device 1400 shown in FIG. 14 is merely exemplary. During implementation, the network 1400 may further include other components, which are not listed one by one in this document.

In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the process or function according to the embodiment of the present invention is generated in whole or in part. 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 computer-readable storage medium. For example, the computer instructions can be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by the computer or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)), etc.

It is understood that the various numerical numbers involved in the embodiments of the present application are only for the convenience of description and are not used to limit the scope of the embodiments of the present application. It should be understood that in the embodiments of the present application, the size of the sequence number of the above-mentioned processes does not mean the order of execution, and 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 the present application.

The above specific implementation methods further illustrate the purpose, technical solutions and beneficial effects of the present application in detail. It should be understood that the above are only specific implementation methods of the present invention and are not intended to limit the scope of protection of the present application. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solutions of the present application should be included in the scope of protection of the present application.

Claims (13)

1. A memory security management method, characterized in that the method comprises:

   Inserting a check statement for checking pointer attributes before a risk statement in the first program; the risk statement is a statement in the first program that calls a pointer for memory access, and the pointer attribute is an attribute of the pointer in the risk statement;

   Eliminating redundant codes from 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 the conversion of machine instructions in the compilation process on the second eliminated program to obtain a second converted program;

   A target execution file is generated based at least on the second converted program and the first eliminated program; wherein the target execution file is used to generate fault information at runtime, and the fault information includes a pointer attribute of a pointer in a first risk statement, and the first risk statement is one of the risk statements in the first program.
2. The method according to claim 1, characterized in that the step of eliminating redundant codes from the first converted program and the check statement respectively comprises:

   By judging the inspection object and inspection scope of the inspection statement, all identical redundant codes and all partially ordered redundant codes in the inspection statement are eliminated to obtain a third eliminated program; the inspection object and inspection scope of the inspection statement are obtained based on at least the risk statement;

   By hashing the check objects of the check statements in the third eliminated program, some identical redundant codes and some partial-order redundant codes in the third eliminated program are eliminated to obtain a second eliminated program.
3. The method according to claim 1, characterized in that the step of inserting a check statement for checking pointer attributes before the risk statement in the first program comprises:

   Inserting a label statement after the pointer definition statement of the first program; the label statement is used to obtain the pointer attribute of the pointer in the risk statement;

   Inserting a pointer attribute storage statement after the annotation statement; the pointer attribute storage statement is used to store the pointer attribute obtained by the annotation statement, the pointer attribute storage statement includes a pointer attribute variable, and the pointer attribute variable is a variable used to represent the pointer attribute; the pointer attribute storage statement is the first custom statement identifiable by the compilation process;

   Based on the risk statement and the pointer attribute storage statement, a check statement for performing a pointer attribute check on the risk statement is determined; wherein the risk statement is used to determine a check 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 a check scope of the check statement; wherein the check statement is a second custom statement identifiable by the compilation process;

   Insert a check statement that checks the pointer properties before the risk statement.
4. The method according to claim 3, characterized in that after the first converted program and the check statement are respectively subjected to redundant code elimination, the method further comprises:

   Eliminating the redundant code in the pointer attribute storage statement and eliminating the pointer attribute variable contained in the redundant code in the pointer attribute storage statement to obtain a fourth post-elimination program; wherein the pointer attribute stored in the redundant code in the pointer attribute storage statement and the pointer attribute variable contained in the redundant code in the pointer attribute storage statement are used to determine the inspection range of the redundant code in the inspection statement;

   The generating a target executable file based at least on the second converted program and the first eliminated program comprises:

   A target execution file is generated based on the second converted program, the first eliminated program, and the fourth eliminated program.
5. The method according to any one of claims 1 to 4 is characterized in that the first program is a program written in C or a C-like language.
6. A memory security management device, characterized in that the device comprises:

   A processing module, configured to insert a check statement for checking pointer attributes before a risk statement in a first program; the risk statement is a statement in the first program that calls a pointer for memory access, and the pointer attribute is an attribute of the pointer in the risk statement;

   The processing module is further used to eliminate redundant codes from the first converted program and the check statement respectively to obtain a first eliminated program. The first converted program is an intermediate representation generated by compiling the first program;

   The processing module is further used to convert the machine instructions in the compilation process on the second eliminated program to obtain a second converted program;

   The processing module is also used to generate a target execution file based on at least the second converted program and the first eliminated program; wherein the target execution file is used to generate fault information at runtime, and the fault information includes a pointer attribute of a pointer in a first risk statement, and the first risk statement is one of the risk statements in the first program.
7. The device according to claim 6, characterized in that when the processing module performs redundant code elimination on the first converted program and the check statement respectively, it is used to:

   By judging the inspection object and inspection scope of the inspection statement, all identical redundant codes and all partially ordered redundant codes in the inspection statement are eliminated to obtain a third eliminated program; the inspection object and inspection scope of the inspection statement are obtained based on at least the risk statement;

   By hashing the check objects of the check statements in the third eliminated program, some identical redundant codes and some partial-order redundant codes in the third eliminated program are eliminated to obtain a second eliminated program.
8. The device according to claim 6, characterized in that when the processing module inserts a check statement for checking pointer attributes before the risk statement in the first program, it is used to:

   Inserting a label statement after the pointer definition statement of the first program; the label statement is used to obtain the pointer attribute of the pointer in the risk statement;

   Inserting a pointer attribute storage statement after the annotation statement; the pointer attribute storage statement is used to store the pointer attribute obtained by the annotation statement, the pointer attribute storage statement includes a pointer attribute variable, and the pointer attribute variable is a variable used to represent the pointer attribute; the pointer attribute storage statement is the first custom statement identifiable by the compilation process;

   Based on the risk statement and the pointer attribute storage statement, a check statement for performing a pointer attribute check on the risk statement is determined; wherein the risk statement is used to determine a check 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 a check scope of the check statement; wherein the check statement is a second custom statement identifiable by the compilation process;

   Insert a check statement that checks the pointer properties before the risk statement.
9. The device according to claim 8, characterized in that after the processing module eliminates redundant codes on the first converted program and the check statement respectively, it is used to:

   Eliminating the redundant code in the pointer attribute storage statement and eliminating the pointer attribute variable contained in the redundant code in the pointer attribute storage statement to obtain a fourth post-elimination program; wherein the pointer attribute stored in the redundant code in the pointer attribute storage statement and the pointer attribute variable contained in the redundant code in the pointer attribute storage statement are used to determine the inspection range of the redundant code in the inspection statement;

   When the processing module generates the target execution file based at least on the second converted program and the first eliminated program, it is used to: generate the target execution file based on the second converted program, the first eliminated program and the fourth eliminated program.
10. The device according to any one of claims 6 to 9 is characterized in that the first program is a program written in C or a C-like language.
11. An electronic device, characterized in that it includes: at least one memory for storing programs; and at least one processor for executing the programs stored in the memory; wherein, when the program stored in the memory is executed, the processor is used to execute the method as described in any one of claims 1-5.
12. A computer-readable storage medium, characterized in that it includes instructions, and when the instructions are executed on a computer, the computer is caused to execute the method for implementing any one of claims 1-5.
13. A computer program product, characterized in that it includes program code, when a computer runs the computer program product, the computer executes the method as described in any one of claims 1-5.