Model compilation security evaluation method and system based on structure detection and differential analysis

Abstract

The present disclosure provides a model compilation security evaluation method and system based on structural detection and differential analysis, relating to the technical field of compilation security evaluation, comprising: calling a compiler for compilation to generate intermediate representations and compilation products in each stage; performing single-file static detection on the intermediate representation graph file to identify neural network backdoor patterns embedded in the form of mathematical calculation structures in the graph; reading the intermediate representation graph file before and after operator fusion, performing differential analysis on the intermediate representation graph file before and after fusion, and identifying abnormal operators or data streams injected in the fusion stage; performing differential analysis on the kernel source code file and the machine code disassembly file to identify malicious tampering injected in the code generation or binary compilation stage; and synthesizing the detection results of multiple identification processes to perform final security evaluation on the model compilation process and generate a structured evaluation report. The present disclosure improves the identification capability of abnormal structures or potential backdoor logic hidden in the model compilation stage.

Description

Technical Field

[0001] This disclosure relates to the field of compiler security assessment technology, specifically to a model compiler security assessment method and system based on structure detection and differential analysis. Background Technology

[0002] The statements in this section are merely background information relating to this disclosure and do not necessarily constitute prior art.

[0003] With the widespread application of deep learning models in various intelligent systems, model security has become a growing concern. Recent research indicates that attackers may implant backdoors during model training or deployment, causing the model to behave normally under normal input but generate malicious output under specific triggering conditions, thus posing a serious threat to system security. Therefore, conducting security assessments during model deployment to identify potentially anomalous computational structures or backdoor mechanisms is of paramount importance.

[0004] Existing security detection methods for deep learning models primarily focus on the model training or inference phases, such as detecting anomalous responses through input perturbation, activation analysis, or model behavior analysis. However, these methods typically rely on model execution results or input-output behavior, lacking direct analysis of the model's internal structure and making it difficult to identify backdoor logic hidden within the model's computational structure. Furthermore, in actual deployment, deep learning models usually require compiler transformation and optimization to generate multi-stage intermediate representations (IR) and underlying execution code, while existing security detection methods rarely consider security risks during the model compilation process.

[0005] Specifically, the existing technology still has the following limitations:

[0006] (1) There is a lack of security detection mechanism for IR structure during model compilation.

[0007] During the compilation of deep learning models, high-level computation graphs are progressively converted into various inference parameters (IRs) and processed through operator fusion and scheduling optimization. However, most existing technologies only focus on the original model structure or model inference behavior, lacking methods for structural analysis of the compiled IRs. This makes it difficult to promptly detect abnormal computational patterns or potential backdoor logic hidden in the intermediate computational structure.

[0008] (2) There is a lack of systematic verification methods for changes in the output of the compilation stage.

[0009] During model compilation, structural changes often occur between the IRs generated at different stages, such as operator fusion, scheduling rearrangement, or buffer adjustment optimizations. Current technologies lack effective methods for systematically differentiating the outputs of each stage before and after compilation, making it difficult to determine whether the structural changes generated during compilation conform to the normal compilation process, thus hindering the timely detection of potential abnormal structures.

[0010] (3) Lack of security analysis capabilities for underlying computing kernels and hardware execution code.

[0011] In modern deep learning compilation frameworks, some computations are further compiled into low-level executable code on GPUs or other hardware platforms. Current technologies mostly remain at the high-level model or intermediate representation level, lacking methods for structural analysis of the low-level executable code. This makes it difficult to detect malicious code or abnormal instructions that may be hidden in the underlying computational logic.

[0012] (4) Lack of a unified security assessment method across compilation levels.

[0013] Deep learning models typically undergo multiple compilation stages from high-level computational graphs to final executable code, with complex transformation relationships between different levels. Existing technologies often only detect a single level and lack a security assessment mechanism that can systematically analyze the entire model compilation process, making it difficult to fully identify potential security risks during compilation. Summary of the Invention

[0014] To address the aforementioned issues, this disclosure proposes a model compilation security assessment method and system based on structure detection and differential analysis. By utilizing the intermediate representations (IRs) generated at each stage during the compilation process of a deep learning model and the final compilation product, static analysis and difference comparison are performed on the compilation products of the same model at different levels of abstraction. This systematically detects backdoor patterns or malicious tampering behaviors that may be injected into the compilation chain, and ultimately forms a comprehensive security assessment conclusion.

[0015] According to some embodiments, the present disclosure adopts the following technical solutions:

[0016] A model compilation security assessment method based on structural detection and differential analysis includes:

[0017] The compiler is invoked to compile the deep learning model, generating intermediate representations at each compilation stage and the final compilation output;

[0018] Read the intermediate representation graph file from the compilation stage and perform single-file static detection to construct an auxiliary analysis structure. Based on the auxiliary analysis structure, identify the neural network backdoor pattern embedded in the graph in the form of a mathematical calculation structure to complete the first level of recognition process.

[0019] Read the intermediate representation graph files before and after operator fusion, perform differential analysis on the intermediate representation graph files before and after fusion, identify abnormal operators or data streams injected during the fusion stage, and complete the second level of identification process.

[0020] Differential analysis is performed on the kernel source code file and the machine code disassembled file to identify malicious tampering injected during the code generation or binary compilation stage, thus completing the third level of identification process.

[0021] Based on the combined detection results from the three levels, a final security assessment of the model compilation process is conducted, generating a structured assessment report.

[0022] According to some embodiments, the present disclosure adopts the following technical solutions:

[0023] A model compilation security assessment system based on structural detection and differential analysis includes:

[0024] The compilation module is invoked to call the compiler to compile the deep learning model, generating intermediate representations at each compilation stage and the final compilation output;

[0025] The first-level recognition module is used to read the intermediate representation graph file during the compilation stage, perform single-file static detection, construct an auxiliary analysis structure, and identify the neural network backdoor pattern embedded in the graph in the form of a mathematical calculation structure based on the auxiliary analysis structure, thus completing the first-level recognition process.

[0026] The second-level identification module is used to read the intermediate representation graph files before and after operator fusion, perform differential analysis on the intermediate representation graph files before and after fusion, identify abnormal operators or data streams injected during the fusion stage, and complete the second-level identification process.

[0027] The third-level identification module is used to perform differential analysis on the kernel source code file and the machine code disassembled file to identify malicious tampering injected during the code generation or binary compilation stage, thus completing the third-level identification process.

[0028] The security assessment module integrates the detection results from the three levels to conduct a final security assessment of the model compilation process and generate a structured assessment report.

[0029] According to some embodiments, the present disclosure adopts the following technical solutions:

[0030] A computer program product includes a computer program that, when executed by a processor, implements the model compilation security assessment method based on structure detection and differential analysis.

[0031] According to some embodiments, the present disclosure adopts the following technical solutions:

[0032] A non-transitory computer-readable storage medium is provided for storing computer instructions, which, when executed by a processor, implement the aforementioned model compilation security assessment method based on structure detection and differential analysis.

[0033] According to some embodiments, the present disclosure adopts the following technical solutions:

[0034] An electronic device includes a processor, a memory, and a computer program; wherein the processor is connected to the memory, the computer program is stored in the memory, and when the electronic device is running, the processor executes the computer program stored in the memory to enable the electronic device to perform the model compilation security assessment method based on structure detection and differential analysis.

[0035] Compared with the prior art, the beneficial effects of this disclosure are as follows:

[0036] This disclosure presents a model compilation security assessment method based on structure detection and differential analysis, filling the gap in structure security detection for intermediate representations during model compilation and achieving systematic coverage of multiple types of backdoor mathematical structures. Unlike existing technologies that rely on indirect detection methods based on model input / output or weight statistics, this disclosure can directly match backdoor computation logic, accurately locating trigger mask variables, malicious output paths, and normal output paths when they are explicitly present in the intermediate representation, and providing equivalent mathematical expressions. This provides clear evidence for manual review and avoids missed detections due to the difficulty in covering trigger conditions. Simultaneously, this disclosure introduces a transparent variable alias tracking mechanism, which can identify the same logical mask variable after multiple shape transformations or type conversions, ensuring effective detection of backdoor structures even under multiple pass-through operations such as attention masks. Furthermore, by identifying the original model parameters and distinguishing them from intermediate computation variables, it can suppress false positives of additive trigger injection detectors for legitimate normalization operations, improving detection accuracy while maintaining the sensitivity of true backdoor detection.

[0037] This disclosure presents a model compilation security assessment method based on structural detection and differential analysis. It establishes a systematic difference verification method for structural changes during the compilation stage, enabling effective identification of anomaly injections during the fusion stage. This disclosure performs difference analysis across three dimensions: operator set, buffer set, and external computing kernel set, by comparing the scheduler intermediate representation before and after fusion optimization. Regarding the operator set, operators that only appear after fusion and whose type is not a fused scheduling node are identified as anomalies, indicating a single source of false alarms, which can be eliminated by checking the external kernel name. Regarding the buffer set, an alarm is triggered when the number of buffers after fusion exceeds 1.5 times that before fusion, which can identify additional data flow branches or hidden intermediate paths. Regarding the external kernel set, new kernels that only appear after fusion are reported, providing targets for kernel-level analysis. The detection results are output in a structured report format, clearly indicating the quantity of each type of difference and the corresponding nodes, facilitating manual location and review.

[0038] This disclosure presents a model compilation security assessment method based on structure detection and differential analysis, filling a gap in the methodology for verifying the security of GPU underlying computing kernel machine code. It achieves cross-level integrity verification based on source code-machine code consistency. This disclosure establishes a consistency detection method for kernel source code and disassembled machine code, covering low-level attacks such as data tampering, illegal disclosure, and malicious keyword embedding. By constructing an interpretable set of constants, it derives allowed values ​​in the machine code based on source code constants and legal compilation transformations, transforming potential injection constant judgment into set queries. This achieves verifiable false alarm suppression and can be automatically updated with the source code, focusing on abnormally large numerical constants. In terms of rule design, this disclosure formulates eight independent rules, covering various attack paths such as logical bitwise operation injection, floating-point arithmetic bias, non-logical constant overwriting, and global storage anomalies. When the same instruction may trigger multiple rules, a rule name and evidence composite key are used for deduplication to ensure consistency between confidence scores and the number of alarms.

[0039] This disclosure presents a model compilation security assessment method based on structure detection and differential analysis, constructing a unified security assessment framework across compilation layers and achieving systematic security coverage of the compilation process. Existing technologies typically only perform security detection on a single stage of the model, lacking a unified assessment across compilation layers, allowing attackers to implant backdoors in blind spots. This disclosure extends the detection scope from the high-level computation graph to the scheduler intermediate representation and GPU machine code, forming a detection chain covering three layers: operator semantics, operator fusion and scheduling, and hardware execution. The high-level layer is used to identify backdoors implanted during the training or deployment phase, the scheduler layer detects anomalies during the fusion optimization phase, and the machine code layer captures binary tampering. Each layer of detection is independent and can trigger alarms individually. The results are uniformly summarized, providing analysts with a complete chain of evidence from computational semantics to hardware execution. The entire process is statically analyzed, requiring no model inference, and is not limited by triggering conditions. Detection time is in the seconds range, meeting the needs of batch security screening before deployment. Attached Figure Description

[0040] The accompanying drawings, which form part of this disclosure, are used to provide a further understanding of this disclosure. The illustrative embodiments of this disclosure and their descriptions are used to explain this disclosure and do not constitute an undue limitation of this disclosure.

[0041] Figure 1 This is a flowchart of a model compilation security assessment method based on structural detection and differential analysis according to an embodiment of this disclosure;

[0042] Figure 2 This is a schematic diagram illustrating compiler calls and intermediate product generation in an embodiment of this disclosure;

[0043] Figure 3 This is a schematic diagram of static detection of a single file in the high-level computational graph IR of this disclosure embodiment;

[0044] Figure 4 This is a schematic diagram of the scheduler IR difference analysis process before and after fusion according to an embodiment of this disclosure;

[0045] Figure 5 This is a schematic diagram illustrating the differential analysis process of kernel source code files and machine code disassembled files according to an embodiment of this disclosure. Detailed Implementation

[0046] The present disclosure will be further described below with reference to the accompanying drawings and embodiments.

[0047] It should be noted that the following detailed descriptions are illustrative and intended to provide further explanation of this disclosure. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0048] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this disclosure. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms “comprising” and / or “including” are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0049] Example 1

[0050] One embodiment of this disclosure provides a model compilation security assessment method based on structure detection and differential analysis, the method steps of which include:

[0051] Step 1: Call the compiler to compile the deep learning model, generating intermediate representations for each compilation stage and the final compilation output;

[0052] Step 2: Read the intermediate representation graph file from the compilation stage and perform single-file static detection to build an auxiliary analysis structure. Based on the auxiliary analysis structure, identify the neural network backdoor pattern embedded in the graph in the form of a mathematical calculation structure to complete the first level of recognition process.

[0053] Step 3: Read the intermediate representation graph files before and after operator fusion, perform differential analysis on the intermediate representation graph files before and after fusion, identify abnormal operators or data streams injected during the fusion stage, and complete the second level of identification process;

[0054] Step 4: Perform differential analysis on the kernel source code file and the machine code disassembled file to identify malicious tampering injected during the code generation or binary compilation stage, thus completing the third level of identification process;

[0055] Step 5: Based on the combined detection results from the three levels, conduct a final security assessment of the model compilation process and generate a structured assessment report.

[0056] As an example, addressing the lack of systematic security assessment of the deep learning model compilation process and the difficulty in identifying abnormal computational structures or potential backdoor logic inserted during the compilation stage in existing technologies, this disclosure proposes a model compilation security assessment method based on structure detection and differential analysis. It provides a method capable of structural analysis of the intermediate representations generated at multiple stages during the deep learning model compilation process to identify possible abnormal computational patterns or potential backdoor structures. By comparing and analyzing the intermediate representations generated at different stages of the compilation process, it verifies whether the changes between the products of each stage conform to the normal compilation process, thereby discovering possible abnormal structural changes. It also provides a structure analysis method for the underlying computational kernel and disassembled code to identify abnormal computational logic or malicious code that may be hidden in the hardware execution code. Finally, it provides a unified security assessment mechanism across compilation levels, achieving systematic security analysis of the model compilation process through multi-level structure detection of the high-level computation graph, intermediate scheduling representation, and underlying execution code. The specific implementation process is as follows:

[0057] Step 1: Compiler calls and intermediate product generation

[0058] like Figure 2 As shown, the deep learning model to be tested is input into the compiler, triggering the complete compilation process, and all intermediate products are retained at each compilation stage.

[0059] This disclosure employs static analysis, requiring neither real data nor triggering inputs to activate backdoors. It only requires the compiler to traverse the complete topology of the computation graph and generate corresponding compilation outputs, rather than obtaining model prediction results. This disclosure is not limited to a specific compiler or deep learning framework; it is applicable to any model compilation system capable of outputting intermediate representations at each stage during the compilation process.

[0060] Step 2: First level, static detection of high-level computational graph IR single file

[0061] This step performs single-file static detection on the high-level computation graph (IR) file to identify neural network backdoor patterns embedded in the high-level computation graph in the form of mathematical computational structures. For example... Figure 3 As shown, the specific testing process includes the following sub-steps:

[0062] Step 21: Read the FX graph (function-level computation graph) file, parse it line by line using regular expressions, extract all operator nodes and their data dependencies in the computation graph, forming a unified "operator-variable" data flow representation. Specifically:

[0063] (1) For each node row with the format "variable name = basic operator interface.operator name (parameter list)", extract the variable name, operator name and parameter list information in the row and construct a basic operator mapping table. The storage format of the mapping table is: {variable name: (operator name, [parameter list])};

[0064] (2) For each node row with the format "variable name = primitive operator interface.operator name (parameter list)", extract the variable name, operator name and parameter list information in the row and construct a primitive operator mapping table. The storage format of the mapping table is consistent with the basic operator mapping table.

[0065] (3) When parsing the parameter list, the nested parameter structure in the parameter list is accurately identified by tracking the nesting depth of the parentheses, ensuring that the result of splitting the parameters with commas as delimiters is accurate.

[0066] Step 22: Before performing backdoor detection, construct the following three types of auxiliary analysis structures:

[0067] (1) Construction of variable alias mapping:

[0068] Traditional backdoor detection methods treat variables that have undergone shape transformations as independent variables, resulting in the same quantity being unable to be identified as the same mask variable after operations such as dimensional expansion. This invention introduces a transparent operator alias tracking mechanism, which enables mask variables to be consistently identified after any number of transparent pass-through operations, significantly reducing the false negative rate.

[0069] In FX graphs, there exists a class of transparent transitive operators whose output is numerically equivalent to the first input, changing only the shape or data type without altering the numerical semantics.

[0070] For the aforementioned transparent transitive operator, a variable alias mapping is established. Furthermore, for cases involving chained transits, path compression is performed to unify all chained aliases into the final canonical variable names.

[0071] (2) Identification of all-1 tensor sets:

[0072] Scan all operators under the basic operator interface to identify variables that generate all-one tensors. After the alias mapping is constructed, include all alias variables that point to the above all-one tensor variables into the all-one tensor set.

[0073] (3) Constructing the activation gated variable mapping:

[0074] Scan all operators under the basic operator interface, identify the output variables of activation functions with limited output value ranges, and construct a soft-gated variable mapping in the format: {gated variable name: normalized input variable name}. These variables can be used by attackers as soft-trigger weights to replace hard masks and implement more covert backdoors.

[0075] Step 23: Based on the auxiliary analysis structure, execute the following seven types of backdoor detectors in parallel.

[0076] [Detector A] Standard Blending Backdoor Detection (High Confidence):

[0077] Detect the following standard hybrid backdoors with the following mathematical forms:

[0078] result = mask * malicious_output + (1 - mask) * normal_output

[0079] Detection logic:

[0080] (1) Traverse all subtraction operators in the computation graph, identify computation forms such as “sub(1.0, variable)” or “sub(all-1 tensor, variable)”, and establish the corresponding “1-mask” computation relationship mapping; at the same time, identify the equivalent reverse subtraction computation forms and include them in the computation relationship mapping.

[0081] (2) Traverse all multiplication operators in the computation graph, identify operations that use the result of “1-mask” as the multiplication factor, and establish the multiplication relation mapping of “(1-mask)*B”.

[0082] (3) Continue to traverse all multiplication operators, identify operations with mask variable mask as multiplication factor, and establish the multiplication relation mapping of “mask*A”.

[0083] (4) Traverse all addition operators in the computation graph and identify operations that use both “mask*A” and “(1-mask)*B” as addition factors;

[0084] When this structure is detected, it can be determined that a complete data flow closure relationship has been formed.

[0085] [Detector B] Equivalent form of linear interpolation (Lerp) (high confidence):

[0086] Identify the linear interpolation operation in the computation graph. Its mathematical form is: lerp(start, end, weight) ≡(1-weight)*start + weight*end. This formula is directly equivalent to the standard blending structure.

[0087] [Detector C] Where Conditional Selection Backdoor Detection (Medium Confidence):

[0088] Detect conditional selection backdoors with the following mathematical forms:

[0089] result = where(trigger_condition, malicious_output, normal_output)

[0090] Scan all WHERE operators and report cases where the condition parameter, truth parameter, and false parameter are all variable names, in order to exclude valid constant condition branches.

[0091]

Detector D

[0092] Detect hybrid backdoors with the following mathematical transformations:

[0093] result = normal + mask * (malicious - normal)

[0094] ≡ mask * malicious + (1 - mask) * normal

[0095] Detection logic:

[0096] (1) Traverse all subtraction operators in the computation graph, collect difference calculation relationships of the form sub(A, B), and establish difference mapping.

[0097] (2) Continue to traverse the multiplication operators, identify the operation that uses the mask variable and the above difference result as the multiplication factor, i.e., the form mul(mask, diff), and establish the corresponding multiplication relation mapping.

[0098] (3) Traverse the addition operators, identify the operation structure of the form add(B, delta), and verify whether the variable B in it belongs to the same logical tensor as the minuend B in the aforementioned difference calculation sub(A, B).

[0099] If all of the above conditions are met, it is determined to be a complete difference-based mixed calculation structure.

[0100] [Detector E] Additive Triggered Injection Detection (Medium Confidence):

[0101] Detect additive injection backdoors of the following mathematical form:

[0102] result = normal_output + trigger * delta_vector

[0103] Detection conditions: Both factors in the multiplication must be intermediate calculation variables; the base variables in the addition must also be intermediate variables; exclude result variables that have been covered by detectors A and D to avoid duplicate reporting.

[0104] Identification of original model parameters: In the FX diagram, model weights and biases are injected in the form of argN_M (such as arg0_1, arg3_1, etc.). They can be distinguished from intermediate runtime calculation variables through regular expression matching, thereby reducing the probability of falsely reporting legitimate LayerNorm normalization as injection operations.

[0105] [Detector F] Activation function-gated backdoor detection (low confidence):

[0106] Detecting backdoor variants that replace hard masks with soft activation function gating:

[0107] gate= sigmoid(trigger_feature)

[0108] result = gate * malicious + base

[0109] Detection logic:

[0110] First, traverse the multiplication operators in the computation graph, identify the operation structure with the gate variable as the multiplication factor, that is, the gated multiplication relationship in the form of mul(gate_var, other), and establish the corresponding mapping relationship.

[0111] Then, the addition operators are traversed to identify superposition operation structures of the form add(base, gate_mul_result), where gate_mul_result is the calculation result of the aforementioned gated multiplication.

[0112] When the result of a gated multiplication is detected to be involved in an addition operation, it can be determined that a gated superposition calculation structure has been formed.

[0113] [Detector G] Source path anomaly detection (low confidence):

[0114] Each node in the FX graph is accompanied by a source code location annotation. Scanning all such annotations identifies source paths that do not belong to known standard framework directories. These paths may point to custom malicious code modules inserted by attackers. Simultaneously, the number of nodes lacking call stack information is counted; this serves as supplementary clues when there are too many anomalies.

[0115] Step 24: Classify the results identified by each detection module into three levels: high, medium, and low, based on their confidence level.

[0116] (1) High confidence: refers to a computational pattern that is highly consistent with the typical mathematical structure characteristics of backdoors, has a clear structural matching relationship, and has a low false alarm probability, such as the standard weighted hybrid structure and its equivalent linear interpolation form.

[0117] (2) Medium confidence: refers to a computational pattern that has certain abnormal features in structure but may also appear in some legal models, such as conditional selection structure, additive perturbation injection form and abnormal source path.

[0118] (3) Low confidence: refers to the computational patterns that are common in normal models and only have weak correlation features. They are only used as auxiliary references, such as equivalent weighted hybrid deformation structures, activation function gating structures, and nodes that lack call stack information.

[0119] Based on the above confidence level classification, the system makes a comprehensive security judgment according to the following set rules:

[0120] (1) When a structural high-confidence result is detected, it is determined that a backdoor structure has been detected and a manual security review must be carried out immediately;

[0121] (2) When a confidence result in a structured form is detected, it is determined that a backdoor structure may exist, and manual verification is recommended;

[0122] (3) When only medium confidence anomalies related to the source path are detected, it is determined that there is an abnormal risk in the model source, and it is recommended to check the model acquisition and construction process;

[0123] (4) When only low-confidence results are detected, it is determined that there are suspicious signs, and further analysis and verification are recommended;

[0124] (5) When no abnormal structure is detected, it is determined that no suspicious features are found.

[0125] Step 3: Second level, analysis of the IR differences between the schedulers before and after fusion.

[0126] This step performs differential analysis on the scheduler IR before and after operator fusion. The purpose is to verify whether the structural changes introduced by the compiler's operator fusion optimization process conform to normal compilation behavior, thereby identifying anomalous operators or data flows injected during the fusion phase. For example... Figure 4 As shown, the specific process is as follows:

[0127] Step 31: Scheduler IR Structure Analysis

[0128] Read the contents of the scheduler IR file before and after operator fusion, perform structure parsing using regular expressions, and extract key elements from the computation graph: operator set, buffer set, and external kernel mapping.

[0129] Step 32: Calculation of structural statistical information before and after fusion

[0130] The number distribution of various operators in the scheduler IR before and after fusion is statistically analyzed, as well as the total number of operators and the total number of buffers, to analyze the scale of structural changes brought about by fusion optimization.

[0131] Step 33: Operator set difference comparison and abnormal operator identification

[0132] Perform set difference operation on the operator sets of IR before and after fusion:

[0133] (1) Operators that exist only before fusion: usually correspond to operators that are eliminated or rearranged by fusion, which is a normal fusion behavior;

[0134] (2) Operators that exist only after fusion: their types need further analysis:

[0135] If it is a fusion scheduling node, it is a normal fusion outcome;

[0136] If it is a basic scheduling node or an external kernel scheduling node, it is an anomaly: such operators did not exist before fusion, but appeared out of thin air after fusion and are not fused nodes. It is necessary to manually confirm whether they are reasonably added operators or malicious computing nodes that have been injected.

[0137] Step 34: Buffer Structure Difference Analysis

[0138] Calculate the difference in the intermediate buffer set before and after fusion:

[0139] (1) Buffers that exist only before fusion: These are usually temporary buffers that are internalized during fusion and are considered normal behavior;

[0140] (2) Buffers that exist only after fusion: their quantity needs to be considered;

[0141] If the total number of buffers after merging exceeds 1.5 times the total number of buffers before merging, an abnormal alarm will be triggered, indicating that there may be additional data flow branches or hidden intermediate computation paths.

[0142] Step 35: External Computation Kernel Difference Analysis

[0143] Perform set difference operation on the sets of external kernel names in the IR before and after fusion:

[0144] (1) External kernel names that only appear after fusion: These need to be manually reviewed to confirm whether they are operator calls added for expected optimization or unexpected external computations injected.

[0145] (2) External kernel names that only appear before fusion: usually replaced by fusion, which is normal behavior and can be selectively monitored.

[0146] Step 36: Summarize the differences

[0147] By combining the difference detection results of operators, buffers, and external kernels, a structured analysis report is generated to identify possible abnormal compilation behaviors.

[0148] The report includes: overall statistical information, a list of various discrepancies and anomaly markers, and a list of specific nodes that require manual verification.

[0149] Step 4: The third level involves differential analysis of the kernel source code file and the machine code disassembled file.

[0150] This step performs differential analysis on the disassembled files obtained by disassembling the kernel source code files and their corresponding machine code files. The purpose is to verify whether the computational operations at the machine code level are consistent with the computational semantics at the source code level, thereby detecting malicious tampering injected during code generation or binary compilation. For example... Figure 5 As shown, the specific process is as follows:

[0151] Step 41: Parsing Source Code Files and Machine Code Files

[0152] (1) Read the kernel source code file and extract the following information: operator set, integer constant set, floating-point constant set, integer bitwise operation flag, and list of suspected keyword hits.

[0153] (2) Read the disassembled file and parse only the code section. For each instruction in the code section, extract: instruction offset, predicate, mnemonic, operand list, hexadecimal immediate value set, and decimal floating-point literal set.

[0154] Step 42: Construct an interpretable set of constants

[0155] This disclosure proposes the concept of an "interpretable constant set," which derives the range of legally occurring constants at the machine code level based on constant information at the source code level. This set is used to distinguish between machine code constants generated by normal compiler behavior and injected illegal constants. The rules for constructing the interpretable constant set are as follows:

[0156] (1) Construction of integer interpretable sets:

[0157] For each integer constant c in the source code, add the product of c and {1, 2, 4, 8, 16, 32, 64, 128, 256} to the set, covering the case where the compiler scales the constant for vectorization and memory alignment purposes;

[0158] For each floating-point constant f in the source code, add its IEEE-754 single-precision bit mode to the set to cover the case where the compiler embeds floating-point constants as integers into logical operation instructions;

[0159] Includes common GPU compiler built-in constants, including: common integer overflow boundaries, IEEE-754 special values, and bit patterns of commonly used floating-point values;

[0160] Add common thread / address bitmasks to cover the normal requirements of GPU thread bundle index calculation;

[0161] Only constants with an absolute value greater than 0x1000 are included in the review scope. Constants with an absolute value less than this threshold are common immediate values ​​and are not used as the basis for alarms.

[0162] (2) Construction of floating-point interpretable sets:

[0163] Add all floating-point constants and their negative values ​​to the source code;

[0164] Add the floating-point form of integer constants in the source code, along with their reciprocals and negative reciprocals;

[0165] Includes common GPU compiler floating-point constants and power-of-2 constants.

[0166] Step 43: Multi-rule consistency check

[0167] Based on the above analysis results and the set of interpretable constants, the following eight detection rules are executed:

[0168]

Rule 1

[0169] Scan all logical operation instructions in the disassembled code. If a logical operation instruction carries a hexadecimal immediate value greater than 0x1000 and is not in the set of interpretable integers, a critical risk warning is triggered. The basis for this rule is that logical operation constants appearing in the disassembled code that cannot be derived from source code constants are highly likely to be injected bitmasks.

[0170]

Rule 2

[0171] The SASS instruction sequence is traversed using a sliding window with a default window size of 8 instructions. Each global storage instruction is used as the endpoint. The window is then checked to see if floating-point calculation, logical bitwise operation, and global storage instructions exist simultaneously and in the order of floating-point calculation → bitwise operation → storage.

[0172] If the above conditions are met, a critical risk alarm will be triggered. This sequence pattern corresponds to the data corruption characteristic of "normal floating-point calculation → result tampering → write back to memory".

[0173]

Rule 3

[0174] Scan all logical operation instructions with predicates. If the hexadecimal immediate value carried by the instruction is greater than 0x1000 and is not in the set of interpretable integers, a critical risk warning is triggered. Predicate-protected logical operations mean that attackers can only perform tampering operations on threads that meet specific conditions, making them highly targeted.

[0175]

Rule 4

[0176] Scan the disassembled file for all hexadecimal constants carried by logical operation instructions. For each constant greater than 0x1000 that is not in the set of interpretable integers, trigger a high-risk alert and report the constant value and the instruction it belongs to. This rule supplements rule 1, reporting only once for repeated occurrences of the same constant.

[0177]

Rule 5

[0178] The system scans the filtered content of kernel source code files and comment lines of disassembled files for predefined suspicious keywords. Within the source files, keyword scanning targets only comment text and string literals.

[0179]

Rule 6

[0180] Using a sliding window with a default window size of 8 instructions, the system scans for decimal floating-point literals carried by floating-point calculation instructions within the window preceding the global storage instructions. If a floating-point literal cannot be found in the interpretable floating-point set, a high-risk alert is triggered.

[0181]

Rule 7

[0182] The system scans the window preceding each global memory instruction using a shorter sliding window with a default window size of 3 instructions. High-risk alerts are triggered for all non-logical operation instructions within the window that carry uninterpretable immediate constants greater than 0x1000. This rule covers variants where attack constants are written via direct register assignment, integer addition, or integer multiplication instructions.

[0183]

Rule 8

[0184] The number of store instructions appearing in the kernel source code files is counted and denoted as `source_stores`. Simultaneously, the number of global store instructions appearing in the disassembled file is counted and denoted as `sass_stores`. The formula for calculating the maximum allowed number of store instructions is:

[0185] expected_max = source_stores × 6 + 2

[0186] When `sass_stores` exceeds `expected_max`, a high-risk alert is triggered if the excess is no more than 5 stores; if the excess exceeds 5 stores, it is recommended to escalate to a critical alert. If `source_stores` is 0 and `sass_stores` is greater than 0, a high-risk alert is triggered directly. Injected additional global storage operations may correspond to data leakage, i.e., writing intermediate computation results or model parameters to memory addresses controlled by the attacker, thus posing a threat to model security.

[0187] Step 44: Deduplication and Confidence Score of Detection Results

[0188] The detection of all rule-triggered events was performed to remove duplicates using (rule name, evidence string) as a composite key, thus preventing the same disassembled instruction from being repeatedly reported by multiple rules and resulting in inflated scores.

[0189] Discoveries are grouped according to the severity level of the rules, and a confidence score is calculated: if any severe or high-risk discovery is found, it is considered an infection; if only medium-risk discovery is found, it is considered suspicious; if no discovery is found, it is considered clean.

[0190] Step 5: Comprehensive Security Assessment

[0191] Based on the combined detection results from the three detection levels, a final security assessment of the model compilation is conducted, generating a structured assessment report.

[0192] The comprehensive evaluation adopts the following judgment logic:

[0193] (1) If a high-confidence or medium-confidence structural backdoor pattern is found in a single file of the high-level diagram IR static detection, it is determined to be a high-risk backdoor and needs to be manually reviewed immediately.

[0194] (2) If the IR differential analysis before and after fusion finds non-fusion-type abnormal operators that only exist before fusion, or an abnormal increase in the number of buffers, or the addition of external kernels, it is determined that there are suspicious structural changes in the compilation process, and the fusion stage needs to be checked.

[0195] (3) If differential analysis of kernel source code disassembly reveals a serious or high-risk level alarm, it is determined that there is injection behavior at the machine code level, and the code generation stage needs to be checked;

[0196] (4) If no abnormalities are found in the above three layers of detection, the model compilation process is deemed safe.

[0197] The comprehensive security assessment report includes the following: a detailed list of findings for each level of detection module, individual judgment conclusions for each level of module, the overall security level, and recommended follow-up actions.

[0198] Example 2

[0199] One embodiment of this disclosure provides a model compilation security assessment method based on structure detection and differential analysis. This example uses the BERT pre-trained model as an example model. This model is a natural language processing model based on the Transformer architecture and can be applied to practical scenarios such as text classification and sentiment analysis. The specific method is as follows:

[0200] The BERT model is compiled by the compiler, which traverses the complete topology of its computation graph and generates corresponding multi-stage intermediate representations and the final compilation product. Without the need for actual data input, forward inference of the model, or acquisition of model prediction results, the computation graph structure and intermediate representations of each stage are analyzed based on the method proposed in this application, thereby realizing the identification and detection of abnormal patterns.

[0201] Example 3

[0202] One embodiment of this disclosure provides a model compilation security assessment system based on structural detection and differential analysis, comprising:

[0203] The compilation module is invoked to call the compiler to compile the deep learning model, generating intermediate representations at each compilation stage and the final compilation output;

[0204] The first-level recognition module is used to read the intermediate representation graph file during the compilation stage, perform single-file static detection, construct an auxiliary analysis structure, and identify the neural network backdoor pattern embedded in the graph in the form of a mathematical calculation structure based on the auxiliary analysis structure, thus completing the first-level recognition process.

[0205] The second-level identification module is used to read the intermediate representation graph files before and after operator fusion, perform differential analysis on the intermediate representation graph files before and after fusion, identify abnormal operators or data streams injected during the fusion stage, and complete the second-level identification process.

[0206] The third-level identification module is used to perform differential analysis on the kernel source code file and the machine code disassembled file to identify malicious tampering injected during the code generation or binary compilation stage, thus completing the third-level identification process.

[0207] The security assessment module integrates the detection results from the three levels to conduct a final security assessment of the model compilation process and generate a structured assessment report.

[0208] Example 4

[0209] One embodiment of this disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the aforementioned model compilation security assessment method based on structure detection and differential analysis.

[0210] Example 5

[0211] One embodiment of this disclosure provides a non-transitory computer-readable storage medium for storing computer instructions, which, when executed by a processor, implement the model compilation security assessment method based on structure detection and differential analysis.

[0212] Example 6

[0213] One embodiment of this disclosure provides an electronic device, including: a processor, a memory, and a computer program; wherein the processor is connected to the memory, the computer program is stored in the memory, and when the electronic device is running, the processor executes the computer program stored in the memory to enable the electronic device to perform the model compilation security assessment method based on structure detection and differential analysis.

[0214] The core idea of ​​this disclosure is to perform multi-level static analysis on the intermediate representations and final compilation artifacts generated at each stage of the deep learning model compiler's compilation process. Through single-file backdoor pattern detection, compilation-stage differential analysis, and source-machine code consistency verification, the security of the model compilation process is assessed. This method does not depend on a specific compiler, deep learning framework, or hardware backend.

[0215] This disclosure uses the PyTorch compiler as an example, but its multi-level detection approach is also applicable to other compiler frameworks such as Apache TVM, Google XLA, and TensorRT. Each framework can implement backdoor pattern detection, difference analysis, and consistency verification at the corresponding stage, which are equivalent to the steps of this invention.

[0216] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0217] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0218] While the specific embodiments of this disclosure have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of this disclosure. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of this disclosure are still within the scope of protection of this disclosure.

Claims

1. A model compilation security assessment method based on structural detection and differential analysis, characterized in that, include: The compiler is invoked to compile the deep learning model, generating intermediate representations at each compilation stage and the final compilation output; Read the intermediate representation graph file from the compilation stage and perform single-file static detection to construct an auxiliary analysis structure. Based on the auxiliary analysis structure, identify the neural network backdoor pattern embedded in the graph in the form of a mathematical calculation structure to complete the first level of recognition process. The process of reading intermediate representation graph files during the compilation stage and performing single-file static detection to construct an auxiliary analysis structure, and then identifying neural network backdoor patterns embedded in the graph in the form of mathematical computation structures based on the auxiliary analysis structure, includes reading function-level computation graph files, parsing them line by line using regular expressions, and extracting all operator nodes and their data dependencies in the computation graph. Specifically: For each node row in the format "variable name=basic operator interface.operator name", extract the variable name, operator name and parameter list information in that row to construct a basic operator mapping table; For each node row in the format "variable name = primitive operator interface.operator name", extract the variable name, operator name and parameter list information in that row to construct a primitive operator mapping table; Parse the parameter list and accurately identify the nested parameter structure by tracking the nesting depth of parentheses; The auxiliary analysis structure is constructed to identify backdoor patterns of neural networks embedded in the graph in the form of mathematical calculation structures. This includes variable alias mapping construction, full-1 tensor set identification, and activation gate variable mapping construction. Based on the auxiliary analysis structure, seven types of backdoor detectors are executed in parallel. The results identified by each detector are classified into three levels according to their confidence level: high, medium, and low. Based on the confidence level classification, a comprehensive security judgment is made according to the set rules. The activation gate variable mapping construction process is as follows: scan all operators under the basic operator interface, identify the output variables of activation functions with limited output value range, and construct soft gate variable mappings in the format: {gate variable name: normalized input variable name}. These variables are used by attackers as soft trigger weights to replace hard masks and achieve more covert backdoors. The seven types of backdoor detectors include: standard hybrid backdoor detection, linear interpolation equivalent form, Where conditional selection backdoor detection, equivalent blending deformation detection, additive triggering injection detection, activation function gated backdoor detection, and source path anomaly detection. Read the intermediate representation graph files before and after operator fusion, perform differential analysis on the intermediate representation graph files before and after fusion, identify abnormal operators or data streams injected during the fusion stage, and complete the second level of identification process. The process involves reading intermediate representation graph files before and after operator fusion, performing differential analysis on these files, and identifying anomalous operators or data streams injected during the fusion stage. This includes: Read the contents of the intermediate representation graph file of the scheduler before and after operator fusion, perform structure parsing using regular expressions, and extract the key elements of the computation graph: operator set, buffer set, and external kernel mapping; The distribution of the number of various operators in the intermediate representation graph file of the scheduler before and after fusion is statistically analyzed, as well as the total number of operators and the total number of buffers, to analyze the scale of structural changes brought about by fusion optimization. Perform set difference operation on the operator set of intermediate representation graph files before and after fusion, and calculate the difference between the intermediate buffer set before and after fusion; Perform set difference operation on the set of external kernel names in the intermediate representation graph files before and after fusion; By combining the difference detection results of operators, buffers, and external kernels, a structured analysis report is generated to identify any abnormal compilation behaviors. Differential analysis is performed on the kernel source code file and the machine code disassembled file to identify malicious tampering injected during the code generation or binary compilation stage, thus completing the third level of identification process. The differential analysis of kernel source code files and machine code disassembled files to identify malicious tampering injected during code generation or binary compilation includes: Parsing source code files and machine code files; Construct an interpretable set of constants and deduce the range of legally occurring constants at the machine code level based on constant information at the source code level. Based on the parsing results and the set of interpretable constants, eight detection rules are executed; the eight detection rules include operator consistency detection, abnormal calculation sequence detection before writing, condition bit operation detection, constant source auditing, suspicious keyword scanning, floating-point constant injection detection, generalized constant overwriting detection before writing, and abnormal number of storage operations detection. For all rule-triggered detection findings, duplicates are removed using the rule name and evidence string as a composite key, and the findings are grouped according to the rule severity level, and a confidence score is calculated. Based on the combined detection results from the three levels, a final security assessment of the model compilation process is conducted, generating a structured assessment report.

2. The model compilation security assessment method based on structural detection and differential analysis as described in claim 1, characterized in that, The combined detection results from the three levels are used to conduct a final security assessment of the model compilation process, generating a structured assessment report, including: The comprehensive assessment is performed using the set judgment logic. If a high-confidence or medium-confidence structural backdoor pattern is found in the static detection of the single file of the high-level diagram, it is judged to be a high-risk backdoor and needs to be manually reviewed immediately. (2) If the differential analysis of the intermediate representation graph files before and after fusion finds non-fusion-type abnormal operators that only exist before fusion, or an abnormal increase in the number of buffers, or the addition of external kernels, it is determined that there are suspicious structural changes in the compilation process, and the fusion stage needs to be checked. (3) If differential analysis of kernel source code disassembly reveals a serious or high-risk level alarm, it is determined that there is injection behavior at the machine code level, and the code generation stage needs to be checked; (4) If no abnormalities are found in the above three layers of detection, the model compilation process is deemed safe.

3. A model compilation security assessment system based on structural detection and differential analysis, characterized in that, Specifically, the model compilation security assessment method based on structural detection and differential analysis as described in any one of claims 1-2 includes: The compilation module is invoked to call the compiler to compile the deep learning model, generating intermediate representations at each compilation stage and the final compilation output; The first-level recognition module is used to read the intermediate representation graph file during the compilation stage, perform single-file static detection, construct an auxiliary analysis structure, and identify the neural network backdoor pattern embedded in the graph in the form of a mathematical calculation structure based on the auxiliary analysis structure, thus completing the first-level recognition process. The second-level identification module is used to read the intermediate representation graph files before and after operator fusion, perform differential analysis on the intermediate representation graph files before and after fusion, identify abnormal operators or data streams injected during the fusion stage, and complete the second-level identification process. The third-level identification module is used to perform differential analysis on the kernel source code file and the machine code disassembled file to identify malicious tampering injected during the code generation or binary compilation stage, thus completing the third-level identification process. The security assessment module integrates the detection results from the three levels to conduct a final security assessment of the model compilation process and generate a structured assessment report.

4. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the model compilation security assessment method based on structure detection and differential analysis as described in any one of claims 1-2.

5. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium is used to store computer instructions, which, when executed by a processor, implement the model compilation security assessment method based on structure detection and differential analysis as described in any one of claims 1-2.

6. An electronic device, characterized in that, include: The device includes a processor, a memory, and a computer program; wherein the processor is connected to the memory, the computer program is stored in the memory, and when the electronic device is running, the processor executes the computer program stored in the memory to enable the electronic device to perform the model compilation security assessment method based on structural detection and differential analysis as described in any one of claims 1-2.

Images