A method and system for automatically protecting safety-critical data integrity based on compiler-defined sections isolated from a link script

Abstract

The application discloses a kind of based on compiler self-defined section and the safety-critical data integrity automatic protection method and system isolated with link script, belong to computer software security field, comprising: the address and length information of safety-critical variable are stored in compiler self-defined link section by compiler section attribute instruction and additional anti-optimization attribute;In link script, self-defined section is placed in independent storage area;Offline check value is calculated and saved;After safety-critical variable completes initial assignment, power-on self-test and initial sealing are executed, the integrity check value of the current data of all safety variables is calculated and used as sealing reference;Before each application cycle executes business logic, current check value is recalculated and compared with sealing reference, if consistent, then allow executing business logic, if inconsistent, then execute fault safety response, if legal modification is carried out, then recalculate check value.The application does not need to manually maintain variable list, and can automatically and efficiently protect the integrity of safety-critical data.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and more specifically to a method and system for automatically protecting the integrity of security-critical data based on the isolation of compiler-defined segments and linker scripts. Background Technology

[0002] In computer security systems, software must meet data integrity requirements. The data integrity requirements for software in various industries are: (1) Runtime data integrity verification - all safety-critical / safety-related global and static data must be monitored for runtime integrity to ensure that random hardware failures such as single-event upsets (SEU) and memory bit flips can be detected in a timely manner. At the same time, it must have the ability to detect illegal memory tampering caused by software logic errors (such as wild pointer writing, array out-of-bounds access, stack overflow, etc.); (2) Data coupling and control coupling analysis - security standards generally require data coupling and control coupling analysis of safety-critical software to prove that data interaction between modules / components will not produce unexpected fault propagation; (3) Data isolation within the address space - in modular software architecture, operating system-level memory protection (MMU / MPU) usually only provides isolation between processes or partitions. However, all threads and modules within the same process / partition / address space share the complete address space. Wild pointers, array out-of-bounds access, and stack overflows in any code region can directly destroy the global / static security data of other modules in the same address space.

[0003] The existing technical solutions have significant shortcomings in the following aspects: First, the manual maintenance of safety variable inventories carries a fundamental risk of omissions. In current engineering practices, the identification and maintenance of safety-critical variables rely almost entirely on manual processes. Developers must manually list each safety-critical variable in separate configuration files, Excel spreadsheets, or dedicated tools. With code and inventory separated, developers may forget to update the inventory when adding or modifying variables. In large industrial software projects (with codebases reaching hundreds of thousands to millions of lines), such omissions are almost unavoidable.

[0004] Second, there is a lack of low-level isolation at the physical memory layout level. Existing upper-level software protection measures—mutexes, semaphores, access permission checks, ASLR, stack canary, etc.—all operate at the logical / software layer and cannot prevent out-of-bounds writes at the physical memory layout level. Stack overflows can bypass the canary and directly overwrite adjacent data segments, and heap out-of-bounds writes can exceed allocation boundaries and pollute subsequent memory areas. Although linker scripts controlling segment layout is a basic function of toolchains such as GCC, current technologies lack a systematic method to centrally isolate the index information of safety-critical variables automatically annotated at compile time through the linker script and form a complete closed loop with runtime verification.

[0005] Third, the verification timing is singular and cannot cover the entire software lifecycle. Most existing solutions only perform data integrity verification once during power-on initialization (such as Flash ECC verification and firmware signature verification), which implicitly assumes that the data will not change after initialization. However, SEU can occur at any time during operation, and software logic defects can also cause illegal writes at any time during operation. A single power-on verification cannot cover faults that occur during runtime.

[0006] Fourth, there is a lack of an integrated automated verification loop from compilation to execution. In existing solutions, the integrity marking of variables and module-level verification are often pieced together from multiple independent tools or processes, resulting in data flow breaks between each stage and an inability to form a credible chain of integrity evidence.

[0007] Fifth, solutions relying on dedicated hardware are difficult to implement in engineering. Some academic research has proposed integrity verification schemes based on Merkle Trees and dedicated hardware circuits, but these schemes require dedicated verification circuits built into the processor, making them unsuitable for deployment on commercially available embedded processors widely used in industry. Furthermore, their design goals are mostly to defend against external security attacks (Security) rather than to detect random hardware failures (Safety).

[0008] Therefore, how to provide a method and system for automatically protecting the integrity of global and static variable data from compile time to runtime is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0009] In view of this, the present invention provides an automatic protection method and system for the integrity of security-critical data based on the isolation of compiler-defined segments and linker scripts. Utilizing the compiler-defined segment mechanism, the address and length information of security-critical variables scattered across various source files are declaratively incorporated into compiler-named segments during compilation. These compiler-defined segments are then placed in an independent storage area physically separated from ordinary data segments, stack segments, and heap segments by the linker script. At runtime, the isolated security data areas are periodically checked using segment boundary symbols exported by the linker as the traversal range, thus constructing a four-stage joint data integrity protection pipeline: "compilation annotation—linking isolation—initial verification—runtime verification".

[0010] To achieve the above objectives, the present invention adopts the following technical solution: On the one hand, this invention provides an automatic protection method for the integrity of security-critical data based on the isolation of compiler-defined segments and linker scripts, including: S1: In the source file, the address and length information of each safety-critical variable are stored in the compiler-defined link segment through compiler segment attribute directives. At the same time, anti-optimization attributes are added so that the variable indexes in each source file are automatically converged to the named segment during the compilation stage. S2: Place the custom segment in a separate storage area in the linker script; S3: Calculate and save the offline verification value of the custom link segment; S4: During system initialization, after the safety-critical variables have been initially assigned values, power-on self-test and initial sealing are performed synchronously. S5: Before executing business logic in each application cycle, recalculate the current verification value using the same traversal method and verification algorithm as the initial sealing, and compare it with the existing verification value; if they match, the business logic can be executed; if they do not match, a fault-safe response is executed. S6: If the business logic makes a legitimate modification to the security-critical variables during the current period, the verification value of all current variable data will be recalculated and sealed immediately after the modification is completed.

[0011] Preferably, the compiler segment attribute instruction in S1 is implemented through a compiler macro. The macro takes the module name as a parameter and statically defines a record constant array at compile time that contains runtime address pointers and variable byte lengths for all security-critical variables of the module.

[0012] Preferably, the linker script in S2 uses the KEEP instruction to protect the custom link segment from being removed by the linker's unreferenced segment garbage collection mechanism, and exports boundary symbols for the custom link segment; the independent storage area is implemented through the address area definition in the linker script, and does not overlap with the code segment, ordinary data segment, stack segment and heap segment in physical address space.

[0013] Preferably, the power-on self-test in S4 specifically includes: traversing the memory area where the safety-critical data is located, calculating the power-on verification value, comparing it with the offline verification value, and if they are inconsistent, determining that the data is abnormal and the system refuses to enter the normal operation state; if they are consistent, entering the operation state.

[0014] Preferably, calculating the offline verification value of the custom link segment in S3 specifically includes: traversing all variable addresses and length information recorded in the custom link segment, using a verification algorithm to calculate the integrity verification value of the current data of all security variables, and saving the verification value as a runtime sealing benchmark.

[0015] On the other hand, the present invention also provides an automatic protection system for the integrity of security-critical data based on the isolation of compiler-defined segments and linker scripts, comprising: The module is used to store the address and length information of each security-critical variable in the source file into the compiler-customized linking segment through compiler segment attribute instructions, and at the same time attach anti-optimization attributes so that the variable indexes in each source file are automatically converged to the named segment during the compilation stage; the linker script puts the custom segment into an independent storage area, calculates the offline verification value of the custom linking segment and saves it. The initial sealing module is used to perform power-on self-test and initial sealing synchronously after the safety-critical variables have been initially assigned their initial values ​​during system initialization. The periodic verification module is used to recalculate the current verification value using the same traversal method and verification algorithm as the initial sealing before executing business logic in each application cycle. It then compares the current verification value with the existing verification value of the sealing benchmark in the previous cycle. If they match, the business logic is allowed to be executed. If they do not match, a fault safety response is executed. If the business logic has made a legitimate modification to the safety-critical variables in this cycle, the verification value of all current variable data is recalculated and sealed immediately after the modification is completed.

[0016] As can be seen from the above technical solution, compared with the prior art, the present invention discloses a method and system for automatic protection of the integrity of security-critical data based on the isolation of compiler-defined segments and linker scripts, which has the following beneficial effects: (1) This invention only requires a compiler macro following the declaration of each safety-critical global or static variable. The addition, deletion, or modification of variables is automatically reflected in the content of the custom segment during the compilation phase, without the need to manually maintain variable information in any external manifest file, database, or configuration table. This eliminates the blind spot in verification caused by "code and manifest not being synchronized" from the root.

[0017] (2) The present invention places the secure data segment into an independent storage area that is separate from the physical address of the ordinary data RAM by linking script. Low-level memory corruption behaviors such as stack overflow, heap out-of-bounds, and ordinary data segment out-of-bounds are fundamentally blocked because they cannot cross the memory area boundary defined by the linking script.

[0018] (3) Power-on self-test verifies the correctness of firmware burning and the initial memory state during system startup; runtime periodic inspection covers newly occurring SEU bit flips and software logic tampering in each cycle of software operation. The two stages are seamlessly connected in the time domain, fully covering the entire life cycle from system power-on to continuous operation. The benchmark verification value used by power-on self-test is the "golden reference value" calculated offline and solidified in ROM. By comparing it with the real-time calculated value during runtime, it can simultaneously detect burning errors and initial memory anomalies.

[0019] (4) A closed-loop protection mechanism is formed during operation by establishing a baseline-verification-legitimate modification-resealing system. Legitimate modifications are seamlessly connected to the next verification after updating the baseline through resealing, which protects the data from accidental tampering without hindering normal business data updates. Each module is sealed and verified independently. When the verification fails, the specific functional module can be directly located, supporting module-level fault isolation and functional degradation.

[0020] (5) It is entirely based on the features of standard compilers and linkers, implemented in pure software, with zero dependency on dedicated hardware. No dedicated hardware verification circuits need to be embedded in the processor, and it can be directly deployed on almost all mainstream embedded and general-purpose processor platforms.

[0021] (6) Automatic support for data coupling analysis of functional safety standards. The metadata such as the address, length, and module to which all safety-critical variables belong is automatically marked by the compiler into a custom segment, which can be directly extracted from the symbol table and link mapping file of the generated executable image to support the data coupling and control coupling analysis required by functional safety standards in various industries. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0023] Figure 1 This is a diagram of the overall system architecture and data flow.

[0024] Figure 2 This is a schematic diagram of the physical layout of the memory.

[0025] Figure 3 This is a diagram illustrating the continuous protection cycle of sealing, calibration, and resealing.

[0026] Figure 4 The flowchart for verification calculation is provided.

[0027] Figure 5 This is a timing diagram for a single application cycle. Detailed Implementation

[0028] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0029] This invention discloses an automatic protection method for the integrity of security-critical data based on the isolation of compiler-defined segments and linker scripts, such as... Figure 1-5 As shown, it includes: S1: In the source file, the address and length information of each safety-critical variable are stored in the compiler-defined link segment through compiler segment attribute directives. At the same time, anti-optimization attributes (such as the used attribute) are attached, so that the variable indexes in each source file are automatically aggregated into the named segment during the compilation stage, without the need for manual maintenance of the external variable list.

[0030] The compiler segment attribute directive is implemented through a compiler macro. This macro takes the module name as a parameter and statically defines an array of constant records at compile time containing runtime address pointers and variable byte lengths for all safety-critical variables of that module. The compiler-provided custom segment attribute directive (such as `__attribute__((section("custom segment name")))` in a GCC-compatible compiler) places this record into the specified compiler-defined segment. An example is shown below: #define CRIT_VAR(mod, ...)\ static const crit_var_record_t _crit_mod_##mod[]\ __attribute__((used,section(".crit_vars")))= { \ __VA_ARGS__\ } S2: Place the custom segment in a separate storage area in the linker script; S3: Calculate and save the offline verification value of the custom link segment.

[0031] The linker script uses the KEEP instruction to protect the custom linker segments from being removed by the linker's unreferenced segment garbage collection mechanism, and exports boundary symbols for the custom linker segments, thus fixing the start and end addresses of the safe data segments in memory during the linking stage. These symbols are declared as external symbols in the C code, and the start and end addresses of each segment in memory are directly obtained through these symbols at runtime.

[0032] Independent storage areas are defined through address regions in the linker script and do not overlap with the code segment, ordinary data segment, stack segment, and heap segment in physical address space.

[0033] Because the secure data area and the ordinary data area are located in independent storage areas with non-overlapping physical addresses, common low-level memory corruption behaviors such as buffer overflows in the code segment, array out-of-bounds errors in the ordinary data segment, stack overflows in the stack segment, and heap out-of-bounds errors in the heap segment are fundamentally blocked because they cannot cross the boundaries of the areas defined by the linker script.

[0034] S4: During system initialization, after the safety-critical variables have been initially assigned values, power-on self-test and initial sealing are performed synchronously.

[0035] The power-on self-test specifically includes: traversing the memory area where the security-critical data is located, calculating the power-on check value, and comparing it with the baseline check value (offline check value) that is pre-calculated offline and solidified in the read-only storage area (such as Flash fixed address). If they are inconsistent, the data is determined to be abnormal, indicating that the firmware burning is incorrect, the image is damaged, or the initial memory is abnormal, and the system refuses to enter the normal operating state; if they are consistent, the initial sealing is performed.

[0036] The initial sealing process specifically includes: traversing all variable addresses and length information recorded within the custom link segment, calculating the integrity check value of the current data for all security variables using a verification algorithm, and saving the check value as the runtime sealing baseline to a secure storage area, which is physically isolated from the ordinary variable storage area. This sealing baseline value is declared by the compiler segment attribute and stored in a separate .seal_value segment (physically isolated from the ordinary variable segment), coexisting with the protected variables within the SAFE_RAM area; each time CRIT_COMMIT() is called, the crit_seal() function recalculates and updates this value in place. Since SAFE_RAM remains powered on between application cycles, the sealing baseline value is naturally maintained across cycles.

[0037] Example of linking scripts: .crit_vars : { __crit_start = .; KEEP (.crit_vars)) __crit_end = .; } > SAFE_RAM / The seal reference value (g_crit_seal_value) storage area is located in the same SAFE_RAM area as the protected variables. / .seal_value(NOLOAD): { = ALIGN(4); (.seal_value) } > SAFE_RAM The linker script above places the .crit_vars segment (safety critical variable record table) and the .seal_value segment (sealing baseline value g_crit_seal_value) in the SAFE_RAM independent storage area, which is completely isolated from the ordinary data segment (.data / .bss), stack segment and heap segment in terms of physical address.

[0038] S5: Before executing business logic in each application cycle, the current checksum is recalculated using the same traversal method and verification algorithm as the initial sealing, and compared with the existing checksum. If they match, it indicates that the data of all protected variables has not been accidentally changed since the last sealing, allowing the business logic to be executed normally in this cycle. If they do not match, it indicates that the data has been accidentally changed—the detection effect of this verification mechanism is unrelated to the cause of the damage. No matter how the data is changed (direct overwriting due to code logic errors, wild pointers, array out-of-bounds errors, hardware bit flips, or others), it will fail as long as it is inconsistent with the sealing benchmark—the preset fault safety response will be executed, including reporting fault codes, function degradation, prohibiting the output of critical control signals until the system enters a safe state.

[0039] The corresponding validation macro is defined as follows, and is used to call it before executing business logic in each application cycle: / Safety-critical data integrity verification macro: If verification fails, a fault-tolerant response will be executed. / #define CRIT_AUDIT()\ do {\ uint32_t _cur = 0xFFFFFFFF; extern crit_var_record_t __crit_start[];\ extern crit_var_record_t __crit_end[];\ size_t _cnt = __crit_end - __crit_start;\ for(size_t _i=0;_i<_cnt; _i++){\ _cur=crc32_step(_cur,\ __crit_start[_i].addr,\ __crit_start[_i].size); }\ if ((_cur ^ 0xFFFFFFFF) != g_crit_seal_value) {\ crit_safe_fault_handler(); Fail-safe response / \ }\ while (0) The usage method is as follows: / Declare multiple safety-critical variables / static uint32_t engine_speed = 0; static uint8_t cmd_speed = 0; static uint32_t system_mode = MODE_NORMAL; CRIT_VAR(motor_ctrl, { &engine_speed, sizeof(engine_speed)}, { &cmd_speed, sizeof(cmd_speed)}, { &system_mode, sizeof(system_mode)} ); void app_task_10ms(void) { CRIT_AUDIT(); / Periodic checks are performed before business logic is executed. / engine_speed = get_sensor_value(); cmd_speed = compute_cmd_speed(); system_mode = update_mode(); CRIT_COMMIT(); / After all variables are updated, reseal once. / } S6: If the business logic makes a legitimate modification to a security-critical variable during the current cycle, the sealing operation will be re-executed immediately after the update: the verification value will be recalculated and saved based on the latest legitimate variable data, replacing the original sealing benchmark value, to ensure that the verification comparison in the next cycle refers to the latest legitimate data status. This forms a continuous loop protection of "sealing → verification → legitimate modification → resealing → verification in the next cycle → ...".

[0040] Specifically, in conjunction with the legal modification of safety-critical variables and automatic resealing, the following implementation can be defined: / Safety-critical variable record structure / typedef struct { void addr; / variable runtime address / size_t size; / variable byte length / } crit_var_record_t; / The seal reference value declaration is stored in a separate .seal_value section, physically isolated from the ordinary variable section. / static uint32_t g_crit_seal_value __attribute__((section(".seal_value"))); / g_crit_seal_value is declared in the .seal_value section, updated at runtime by crit_seal(), and persisted across cycles. / void crit_seal(void) { uint32_t crc = 0xFFFFFFFF; extern crit_var_record_t __crit_start[]; extern crit_var_record_t __crit_end[]; size_t count = __crit_end - __crit_start; for (size_t i = 0; i < count; i++) { crc = crc32_step(crc, __crit_start[i].addr, __crit_start[i].size); } g_crit_seal_value = crc ^ 0xFFFFFFFF; } Corresponding safety-critical variable sealed macro (module level, no parameters): / Module-level sealing macro: Reseals all registered safety-critical variables upon execution. / #define CRIT_COMMIT() \ do { crit_seal();} while (0) Here is an example of usage: / Declare multiple safety-critical variables / static uint32_t engine_speed = 0; static uint32_t system_mode = MODE_NORMAL; static uint8_t cmd_speed = 0; CRIT_VAR(motor_ctrl, { &engine_speed, sizeof(engine_speed)}, { &cmd_speed, sizeof(cmd_speed)}, { &system_mode, sizeof(system_mode)} ); / After all business logic within the module is completed, a unified sealing process will be executed. / CRIT_COMMIT(); / All variable updates across the entire module are uniformly marked for integrity by the last seal. / / / No need to call the sealing macro separately for each variable The following is a complete usage example in an aviation embedded software scenario. Assume that within the same process of an ARINC 653 partition, there are two functional modules: a flight control module and a navigation module, each possessing safety-critical static / global variables that require integrity protection: / ========== flight_control.c ========== / / Flight control module – a safety-critical variable / static float cmd_pitch; / Pitch commands / static float cmd_roll; / Roll command / static uint32_t actuator_status; / Actuator status / / Compilation phase: Register module variables to user-defined segments / CRIT_VAR(flight_control, { &cmd_pitch, sizeof(cmd_pitch)}, { &cmd_roll, sizeof(cmd_roll)}, { &actuator_status, sizeof(actuator_status)} ); void flight_control_task(void) { CRIT_AUDIT(); / Pre-run verification: Ensure that critical data in this module has not been accidentally modified. / / Read sensor data and calculate control laws (ordinary assignment). / cmd_pitch = compute_pitch_cmd(); cmd_roll = compute_roll_cmd(); actuator_status = ACTIVE; CRIT_COMMIT(); / After all variables are updated, reseal once. / } / ========== navigation.c ========== / / Navigation Module – Safety-Critical Variable / static double latitude; static double longitude static uint8_t nav_quality; CRIT_VAR(navigation, { &latitude, sizeof(latitude)}, { &longitude, sizeof(longitude)}, { &nav_quality, sizeof(nav_quality)} ); void navigation_task(void) { CRIT_AUDIT(); / Navigation data integrity verification / latitude = parse_gps_lat(); longitude = parse_gps_lon(); nav_quality = QUALITY_GOOD; CRIT_COMMIT(); / After all variables in the navigation module are updated, a resealing is performed. / } In this example, the two modules belong to different compilation units (.c files). Each module only needs to call CRIT_AUDIT() at the entry point of its corresponding task function and use CRIT_COMMIT() when assigning values ​​to safety-critical variables. During compilation, the CRIT_VAR macro automatically aggregates the variable addresses and length information of each module into the same .crit_vars custom link segment, and the linker script places this segment in the independent storage area SAFE_RAM. The collaboration of these three macros allows the modules to share the same integrity protection mechanism without mutual agreement, which meets the integrity protection requirements of multi-module data coupling and control coupling within ARINC 653 partitions.

[0041] Furthermore, the specific algorithm for runtime verification can be CRC32, CRC64, MD5, SHA-256, etc.

[0042] The above S1-S6 constitute a three-pronged technical approach of "compilation annotation—linkage isolation—initial verification—runtime verification". The specific algorithm for runtime verification (such as CRC32, CRC64, MD5, SHA-256, etc.) is selected for the embodiments of this invention; the organization of module control records (segment division method, structure field design, etc.) is also selected for the embodiments; whether each secure data segment is arranged continuously within an independent area is also selected for the embodiments. None of the above constitutes a limitation on the scope of protection. Any software system, regardless of its application field, that uses the above-mentioned four-stage combined approach of "compilation annotation—linkage isolation—initial verification—runtime verification" to protect the data integrity of global or static variables falls within the protection scope of this invention.

[0043] This invention is implemented entirely based on standard compiler and linker features, requiring no special hardware support. It is compatible with mainstream real-time operating systems and general-purpose operating systems (such as Linux, VxWorks, FreeRTOS, QNX, etc.), and with mainstream processor platforms such as ARM, x86, PowerPC, RISC-V, Loongson, and Phytium. The compiler segment attribute instructions cover custom segment mechanisms provided by various compilers in the industry, including but not limited to GCC and Clang / LLVM's __attribute__((section)), IAR's @ syntax, MSVC's __declspec(allocate) and #pragma section, and TI CCS's #pragma DATA_SECTION, etc.

[0044] On the other hand, the present invention also provides an automatic protection system for the integrity of security-critical data based on the isolation of compiler-defined segments and linker scripts, comprising: The module is used to store the address and length information of each security-critical variable in the source file into the compiler-customized linking segment through compiler segment attribute instructions, and at the same time attach anti-optimization attributes so that the variable indexes in each source file are automatically converged to the named segment during the compilation stage; the linker script puts the custom segment into an independent storage area, calculates the offline verification value of the custom linking segment and saves it. The initialization sealing module is used to perform power-on self-test and initial sealing after the safety-critical variables have been initially assigned values ​​during system initialization. The periodic verification module is used to recalculate the current verification value using the same traversal method and verification algorithm as the initial sealing before executing business logic in each application cycle, and compare it with the existing verification value. If they match, the business logic can be executed; if they do not match, a fault safety response is executed. If the business logic has made a legitimate modification to the safety-critical variables in this cycle, the verification value of all current variable data will be recalculated immediately after the modification is completed.

[0045] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0046] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for automatically protecting the integrity of security-critical data based on the isolation of compiler-defined segments and linker scripts, characterized in that, include: S1: In the source file, the address and length information of each safety-critical variable are stored in the compiler-defined link segment through compiler segment attribute directives. At the same time, anti-optimization attributes are added so that the variable indexes in each source file are automatically converged to the named segment during the compilation stage. S2: Place the custom link segment in a separate storage area in the linker script; S3: Calculate and save the offline verification value of the custom link segment; S4: During system initialization, after the safety-critical variables have been initially assigned values, power-on self-test and initial sealing are performed synchronously. S5: Before executing business logic in each application cycle, recalculate the current verification value using the same traversal method and verification algorithm as the initial sealing, and compare it with the existing verification value; if they match, the business logic can be executed; if they do not match, a fault-safe response is executed. S6: If the business logic makes a legitimate modification to the security-critical variables during the current period, the verification value of all current variable data will be recalculated and sealed immediately after the modification is completed.

2. The automatic protection method for the integrity of security-critical data based on the isolation of compiler-defined segments and linker scripts as described in claim 1, characterized in that, The compiler segment attribute instructions described in S1 are implemented through a compiler macro. The macro takes the module name as a parameter and statically defines a record constant array at compile time that contains runtime address pointers and variable byte lengths for all security-critical variables of the module.

3. The automatic protection method for the integrity of security-critical data based on the isolation of compiler-defined segments and linker scripts as described in claim 1, characterized in that, The linker script described in S2 uses the KEEP instruction to protect the custom link segment from being removed by the linker's unreferenced segment garbage collection mechanism, and exports boundary symbols for the custom link segment; the independent storage area is implemented through the address area definition in the linker script, and does not overlap with the code segment, ordinary data segment, stack segment and heap segment in physical address space.

4. The automatic protection method for the integrity of security-critical data based on the isolation of compiler-defined segments and linker scripts according to claim 1, characterized in that, The power-on self-test described in S4 specifically includes: traversing the memory area where the safety-critical data is located, calculating the power-on verification value, comparing it with the offline verification value, and if they are inconsistent, the data is determined to be abnormal and the system refuses to enter the normal operation state; if they are consistent, the system enters the operation state.

5. The automatic protection method for the integrity of security-critical data based on the isolation of compiler-defined segments and linker scripts according to claim 1, characterized in that, The calculation of the offline verification value of the custom link segment in S3 specifically includes: traversing all variable addresses and length information recorded in the custom link segment, using a verification algorithm to calculate the integrity verification value of the current data of all security variables, and saving the verification value as the runtime sealing benchmark.

6. An automatic protection system for the integrity of security-critical data based on the isolation of compiler-defined segments and linker scripts, characterized in that, include: The module is used to store the address and length information of each security-critical variable in the source file into the compiler-customized linking segment through compiler segment attribute instructions, and at the same time attach anti-optimization attributes so that the variable indexes in each source file are automatically converged to the named segment during the compilation stage. In the linker script, the custom segment is placed in an independent storage area, and the offline verification value of the custom linking segment is calculated and saved. The initial sealing module is used to synchronously perform power-on self-test and initial sealing after the safety-critical variables have been initially assigned values ​​during system initialization. The periodic verification module is used to recalculate the current verification value using the same traversal method and verification algorithm as the initial sealing before executing business logic in each application cycle, and compare it with the existing verification value. If they match, the business logic can be executed; if they do not match, a fault safety response is executed. If the business logic has made a legitimate modification to the safety-critical variables in this cycle, the verification value of all current variable data will be recalculated and sealed immediately after the modification is completed.

Images