A method for integrity measurement of a satellite-borne embedded system based on link symbol topology

Abstract

This invention discloses a method for measuring the integrity of a spaceborne embedded system based on link symbol topology. In the static injection phase, a linker script is configured to inject symbols at critical memory segment boundaries, generating hierarchical hybrid fingerprints and redundantly persisting them to non-volatile storage. In the dynamic verification phase, a lightweight program is started before the operating system takes over, performing hierarchical dual-dimensional and SEU-resistant temporal redundancy verification, supporting multi-container dedicated isolation verification. In the linkage blocking phase, anomalies are forcibly blocked and primary / backup linkage is triggered, collecting eight types of fault contexts and supporting on-orbit updates. This invention solves the problems of traditional hash methods failing to detect layout anomalies and high time consumption, reducing complexity to O(K), achieving sub-millisecond-level measurement decoupled from image volume, adapting to spaceborne radiation-resistant, cloud-native, and redundancy scenarios, and meeting the high reliability requirements of aerospace.

Description

Technical Field

[0001] This invention relates to the fields of embedded system information security and functional safety technology, specifically to a method for measuring the integrity of spaceborne embedded systems based on linked symbol topology. This method is particularly suitable for spaceborne computing platforms with extreme requirements for real-time startup, radiation resistance, and on-orbit maintainability, such as spaceborne cloud-native systems or primary / backup redundant control devices employing real-time operating systems and highly reliable processor architectures. Background Technology

[0002] Embedded systems are core control units in aerospace, industrial control, and other fields. In particular, spaceborne embedded systems undertake critical tasks such as space mission management, payload control, inter-satellite link communication, and cloud-native container scheduling. The integrity of their memory layout and topology consistency during startup directly determines the spacecraft's on-orbit safety and mission continuity. With the evolution of aerospace technology, current spaceborne systems are mostly based on real-time operating systems and highly reliable processor architectures, and are gradually transitioning to primary / backup redundancy and cloud-native multi-container architectures. Firmware image sizes have grown to tens of megabytes. However, existing integrity verification technologies mainly suffer from the following three core blind spots, making it difficult to meet the extreme requirements of spaceborne scenarios: 1. Limitations of traditional TPM / TEE-assisted hash verification: This solution relies on a hardware root of trust to perform a full hash measurement on the firmware. Although widely used, it has a fatal flaw. (1) Lack of semantic awareness: Hash verification only applies to static binary data streams ("content level") and cannot detect "space layout" anomalies such as segment overlap and address drift caused by linker script tampering. That is, it cannot verify the correctness of the logical distribution of data in the physical address space, leading to the risk of system crashes where "the content is legal but the layout is illegal".

[0003] (2) The time and space overhead increases linearly: Due to the O(N) complexity, when processing large-capacity satellite images, pure software verification and TPM hardware initialization will generate delays of hundreds of milliseconds or even seconds, which severely restricts the hard real-time capability of the satellite system to "instantaneously reset" after being interfered with by rays.

[0004] (3) Lack of radiation redundancy: It is not adapted to the radiation resistance characteristics of onboard non-volatile storage (such as FRAM), the reference data lacks redundancy design, and is extremely susceptible to single event flip (SEU) to cause reference failure and mistakenly kill normal systems.

[0005] 2. Limitations of Stack Overflow Protection Mechanisms: For example, GCC's `-fstack-protector` is a runtime-based mitigation technique. It only detects dynamic stack overflows by inserting canary values ​​into stack frames, failing to cover layout consistency in globally static areas such as kernel code segments, read-only data segments, and cloud-native container pooling segments. Furthermore, this mechanism lacks anti-radiation design; canary values ​​themselves are easily tampered with by SEUs, and it cannot achieve segmented isolation protection in multi-container scenarios, making it a localized defense rather than a system-level measure.

[0006] 3. Limitations of Memory Protection Unit (MPU) Configuration: The MPU is a hardware access control mechanism, but it contains a logical paradox. (1) Security vacuum: The MPU can only block illegal access (post-event blocking) and cannot actively verify the legality of the layout before startup, resulting in a security vacuum period from "after reset to before the MPU configuration takes effect".

[0007] (2) Lack of logical closure in configuration baseline: The configuration parameters of the MPU are highly dependent on the base address symbol provided by the software. If the memory segment has drifted due to SEU or linker script tampering during the startup phase, the MPU will establish a "legitimate" protected area based on an incorrect baseline, creating a security illusion.

[0008] (3) Lack of linkage mechanism: When a single device MPU fails, it cannot trigger the automatic takeover of the main and backup machines, which can easily lead to task interruption.

[0009] Furthermore, existing technologies are severely inadequate for adaptability in new spaceborne scenarios: for spaceborne cloud-native architectures, there is a lack of container-specific layout verification mechanisms, making it impossible to accurately isolate segment anomalies in a single container and posing a risk of container escape; for primary and backup redundant configurations, there is a lack of automatic takeover logic after verification anomalies; for on-orbit maintenance, there is a lack of dynamic update mechanisms for baseline data, requiring re-mass production and solidification after firmware upgrades, resulting in extremely high operation and maintenance costs.

[0010] The linker script is the underlying specification that defines the memory layout of a spaceborne system, precisely managing the physical mapping relationships of each memory segment and the export of global symbols. In the harsh radiation environment of space, SEUs caused by high-energy particles can lead to potential jumps in the base address or load address mapping table of memory segments, directly causing layout logic errors. Unfortunately, none of the existing solutions mentioned above utilize the global symbols exported by the linker script to build a "compile-time topology solidification - boot-time verification linkage" mechanism, thus failing to address this problem at its root.

[0011] In summary, there is an urgent need for a pre-measurement method that balances content integrity and location relevance, has low overhead (O(K) complexity), high compatibility, and strong radiation resistance, in order to meet the ECSS-E-ST-40C aerospace software engineering standard and the GJB2786A military software development requirements, and to build a solid startup safety defense for the spaceborne system. Summary of the Invention

[0012] Technical problems to be solved To address the shortcomings of the existing technologies mentioned above, and considering the practical application requirements of spaceborne embedded systems in cloud-native multi-container, primary / backup redundancy, and space radiation environments, this invention aims to solve the following core technical problems: 1. Addressing the "layout consistency measurement blind spot" problem in traditional content-level verification: This invention addresses the semantic gap in traditional hash verification, which can only verify static binary content and cannot perceive spatial layout logic. It resolves structural logic errors such as segment offsets, illegal segment overlaps, and address drifts caused by linker script tampering or single-event flips (SEUs). This invention aims to fill the security blind spot of "valid content but invalid layout," achieving an effective measurement of the authenticity and topological consistency of the physical distribution of the memory address space.

[0013] 2. Addressing the "Real-time vs. Overhead" Contradiction Caused by Strong Coupling Between Boot Latency and Image Size: This invention addresses the issue that the increasing size of onboard firmware images (tens of MB) leads to excessively long processing times for traditional hash verification (O(N) complexity), failing to meet instantaneous reset requirements. The goal is to deeply decouple verification complexity from image size, reducing it to a constant O(K) level, only related to the number of critical memory segments. This ensures verification time remains stable at the microsecond / sub-millisecond level, adapting to the low computing power of onboard processors and meeting hard real-time boot constraints.

[0014] 3. Addressing the "trust root logic paradox" problem in hardware protection mechanisms during initial startup: This invention addresses the security vacuum period that exists in hardware mechanisms such as the Memory Protection Unit (MPU) during initial reset, and the initial lack of a trust loop due to the high dependence of its configuration parameters on unverified link symbols. The invention aims to provide a pre-emptive self-verification mechanism before the operating system takes over the hardware, providing a reliable physical topology benchmark for subsequent MPU hardware security configuration and eliminating the "security illusion" of establishing protection zones based on erroneous addresses.

[0015] 4. Addressing the shortcomings of "multi-dimensional adaptability and radiation resistance reliability" in complex spaceborne scenarios: This invention addresses the difficulty of existing technologies simultaneously meeting the requirements of spaceborne cloud-native multi-container isolation, primary / backup redundancy takeover, and radiation resistance. It aims to solve the challenges of container escape detection and the vulnerability of baseline data to SEU flipping in cloud-native scenarios through hierarchical verification, container-specific metrics, and triple-modal redundancy design. This ensures that the metric mechanism complies with the stringent initialization process controls of GJB 2786A. ECSS-E-ST-40C / Q-ST-80C are high reliability standards.

[0016] 5. Addressing the issues of "ambiguous fault tracing and difficulty in updating baselines" in long-term on-orbit operation scenarios: Existing solutions suffer from insufficient fault information, inability to distinguish between physical faults (SEUs) and logical attacks (tampering), and difficulty in dynamically synchronizing baseline data after firmware upgrades. This invention aims to establish a multi-dimensional fault context acquisition and compressed storage mechanism to achieve accurate profiling of fault types (such as distinguishing between SEUs and malicious tampering), and to provide secure dynamic updating capabilities for on-orbit baseline data, thereby reducing the operation and maintenance costs and risks throughout the entire lifecycle of the spaceborne system.

[0017] Technical solution The core innovation of this invention lies in utilizing static linking symbols as cross-stage security anchors: the memory layout logic (topology) during compilation is injected into the executable file as global symbols. During the startup phase (before the operating system takes over), the physical address and content of the symbols are actively verified, achieving cross-stage linkage between "compile-time logic solidification" and "startup-time topology verification." This invention addresses the extreme requirements of spaceborne systems for "radiation resistance, on-orbit maintainability, cloud-native adaptation, and redundancy fault tolerance," designing a low-intrusion, O(K) complexity (K being the number of critical segments) and engineering-feasible measurement system. This method is adaptable to various spaceborne real-time operating systems and embedded processor architectures. The specific implementation process is divided into the following three stages: 1. Static Injection and Baseline Construction Phase: During firmware construction, start and end boundary symbols are injected into critical memory segments by configuring the linker script, thereby completing fingerprint generation, topology construction, and redundant solidification of baseline data.

[0018] (1) Hierarchical hybrid fingerprinting mechanism: Combining the different security requirements of different memory segments on the satellite, a hierarchical fingerprinting strategy is designed to balance security and computational overhead.

[0019] a) SL1 (Highest Security Level): Covers the interrupt vector segment (.vector), system startup segment (.start), and kernel code segment (.text). It adopts a high-security mode, based on the chip's unique serial number or device batch number, and combines strong encryption algorithms such as AES-128 to generate a hardware-bound encrypted fingerprint to prevent firmware from being cloned or tampered with at the underlying level.

[0020] b) SL2 (Medium Security): Covers read-only data segments (.rodata) and cloud-native container pooled memory segments. Employs a hybrid approach (e.g., simplified round-based encryption + fixed canary identifiers) to reduce decryption overhead while ensuring container boundary security.

[0021] c) SL3 (Basic Security Level): Covers initialized data segments (.data), uninitialized data segments (.bss), and the system stack segment (.stack). It uses a generic mode (fixed canary identifier, such as 0x5A5A5A5A) for rapid detection of segment overflows or large-scale memory failures.

[0022] (2) Dynamic Topology Construction: The physical address range of each segment is explicitly defined in the linker script, and the address difference between adjacent segments is calculated as the offset benchmark between segments. For the spaceborne cloud-native multi-container scenario, a "container segment dynamic template" is introduced, which supports the automatic generation of exclusive boundary symbols (such as bsp_section_container[ID]_pool_begin) at compile time based on the configuration (such as container ID 0~15), realizing a strong binding of "container identifier - boundary symbol - topology benchmark".

[0023] (3) Radiation-hardened reference solidification: The generated boundary symbol address, fingerprint content, inter-segment offset, reference version number, and on-orbit update identifier are integrated into a reference data packet. Using a triple modular redundancy (TMR) mechanism, three copies of this data packet are stored at intervals in a radiation-hardened non-volatile memory module (such as FRAM). During reading, majority voting logic is used to automatically correct reference data bit transitions caused by single-event upsets (SEUs).

[0024] 2. Dynamic Topology Measurement and Verification Phase: A lightweight verification program is triggered during the initialization period of the Board Support Package (BSP) before the operating system kernel takes over. This program does not rely on the MMU or file system and performs hierarchical two-dimensional verification through pure hardware instructions.

[0025] (1) Two-dimensional topology measurement: ① Location correlation verification: extract the actual physical address of the boundary symbol, compare it with the base address, and calculate the actual offset of adjacent segments to detect whether there is memory layout drift caused by linker script tampering or SEU address register flipping; ② Content integrity verification: compare the actual value at the boundary symbol with the base fingerprint to ensure that the beginning and end of the critical segment are not overwritten or maliciously tampered with; ③ Hierarchical blocking strategy: first verify the SL1 segment, and if it is abnormal, immediately block the start; if SL1 is normal, then verify the SL2 and SL3 segments in turn, and select blocking or downgrade operation according to the strategy.

[0026] (2) Temporal Redundancy Check (SEU-resistant Design): A "dual sampling + periodic inspection" mechanism is adopted. Two consecutive checks are performed on the same critical segment (with an interval of microseconds). The segment is only considered to pass if the two results are consistent, thus preventing transient SEU interference during the check process. In addition, a lightweight review is performed on the SL1 core segment within a short period of time after the kernel takes over (e.g., within 100 mm) to compensate for the security blind spot during the startup handover period.

[0027] (3) Container-specific verification logic: Adapted to cloud-native architecture, the verification program first reads the "container ID - symbol" binding relationship to confirm the legal address range of the current container, and then performs a two-dimensional verification for the container's exclusive symbol. If a container segment is abnormal, only the loading of that container is blocked, without affecting the system core and the operation of other containers, thus achieving fault isolation.

[0028] (4) Performance characteristics: The verification complexity is O(K), decoupled from the tens of MB image size. The verification time is stable in the sub-millisecond range, meeting the requirements of hard real-time startup and instantaneous reset of the spaceborne system.

[0029] 3. Linkage Interception, Source Tracing and Update Phase: Establish an anomaly response closed loop to improve the system's fault tolerance and maintainability.

[0030] (1) Primary and backup machine linkage blocking: If the verification fails, the kernel jump instruction is forcibly cut off to prevent "running with defects". Combined with the on-board primary and backup machine redundancy architecture, when the primary machine is abnormal, it actively sends a status code to the backup machine; after receiving it, the backup machine immediately starts its own verification, and quickly takes over the task after passing the verification; if both machines fail, the system is triggered to enter safe mode (such as minimum system reset).

[0031] (2) Multi-dimensional Fault Source Tracing: Automatically collects and compresses eight types of key fault context information to a non-volatile storage area. This information specifically includes: abnormal segment identifiers and container IDs (to locate the fault source), fingerprint measured values ​​and baseline values ​​(to determine the degree of content damage), abnormal physical addresses and offsets (to determine topology drift), suspected SEU location bits (to distinguish physical flips), CPU core register snapshots (to restore the current state), triple redundancy majority voting records (to diagnose memory health), the verification program's own CRC status (to prevent false alarms), and high-precision fault timestamps. This enables the ground control terminal to accurately distinguish between physical faults (SEUs) and logical attacks (tampering) based on panoramic data.

[0032] (3) Safe on-orbit baseline update: Supports receiving "baseline update instructions" via the telemetry and control link. The system performs digital signature verification on the new baseline data packet, writes it to the storage area and performs TMR hardening to update the "on-orbit update identifier". On the next startup, the verification program automatically loads the new baseline, thereby supporting baseline synchronization after firmware on-orbit upgrade without the need for re-mass production or return to the factory.

[0033] Beneficial effects The core difference between this invention and existing technologies lies in elevating the integrity measurement dimension of embedded systems from a single "content level" to a "topological logic level," constructing a cross-stage trust chain from "compile-time logic solidification" to "boot-time physical verification." By combining the extreme resource constraints and high reliability requirements of spaceborne systems, the specific beneficial effects of this invention are as follows: 1. This invention achieves deep decoupling between verification overhead and image size, overcoming the real-time bottleneck of startup: Traditional hash verification has a time complexity of O(N) (N is the number of image bytes), which generates a latency of hundreds of milliseconds when processing tens of megabytes of onboard images, and this latency increases linearly with software iteration. This invention reduces the verification complexity to O(K) (K is the number of critical memory segments, typically only 3-10), completely decoupling the verification time from the firmware image size, exhibiting deterministic constant-time characteristics (sub-millisecond / microsecond level). This characteristic greatly improves the deterministic startup performance of the system, perfectly meeting the hard real-time requirement of "instantaneous recovery" after a satellite experiences a single-event upset (SEU) reset.

[0034] 2. Filling the security blind spot in layout and constructing a dual semantic measurement system of "content + layout": This invention breaks through the semantic gap of traditional solutions that "only verify content, not location." By introducing location correlation verification, it achieves explicit measurement of memory physical topology for the first time, effectively intercepting the risk of segment drift where "content is legal but location is illegal" caused by address register jumps due to linker script tampering or SEU. Combined with content integrity verification using cryptographic fingerprints, this invention constructs a three-dimensional defense system of physical topology and logical content, significantly improving the depth defense capability of spaceborne systems during the startup phase.

[0035] 3. Significantly improves radiation resistance and system reliability in complex space environments: This invention designs multiple fault-tolerant mechanisms for space radiation environments.

[0036] (1) Reference data reliability: Through triple modular redundancy (TMR) storage and majority voting mechanism, the reference data bit flip caused by SEU is effectively corrected.

[0037] (2) Reliability of the verification process: Time-domain redundancy verification (double sampling) and self-testing of the verification program are adopted to prevent the verification logic itself from being interfered with by SEU.

[0038] (3) Quantitative effect: Compared with the non-redundant design, the present invention can reduce the failure rate of startup anomalies caused by SEU by more than 90%, ensuring that the system will not enter a deadlock state due to transient failure.

[0039] 4. Deeply adapt to the spaceborne cloud-native architecture to achieve fine-grained container isolation and traceability: In response to the spaceborne cloud-native trend, this invention designs a container-specific boundary symbol injection and ID binding mechanism.

[0040] (1) Fault isolation: When an anomaly is detected in a container segment (such as container escape or kernel overwriting), only the startup of that container is blocked, without affecting the system core and the operation of other containers, thus solving the problem of resource waste caused by the traditional "one-size-fits-all" blocking.

[0041] (2) Accurate source tracing: By collecting multi-dimensional fault context, the ground control station can accurately distinguish between physical faults (SEU) and logical attacks (tampering), improving fault troubleshooting efficiency by 60% and significantly reducing on-orbit operation and maintenance costs.

[0042] 5. Enhance system business continuity and on-orbit maintainability (1) Redundancy takeover: Establish a primary and backup machine linkage blocking mechanism to solve the problem of task interruption caused by single machine verification failure, and improve system availability to over 99.9%.

[0043] (2) Dynamic update: Provides a secure on-orbit reference data update channel, supports reference synchronization after firmware OTA upgrade, without the need for re-mass production and solidification or return to the factory, and adapts to the actual needs of long-term on-orbit operation and frequent iteration of the spaceborne system.

[0044] 6. High compatibility and low engineering intrusion: This invention requires no modification to processor hardware (such as MMU / TPM) or reconstruction of the operating system kernel. It can be implemented simply through standardized configuration of linker scripts (such as GNU LD) and lightweight code embedded with BSP. This solution has minimal intrusion into existing engineering systems, can be quickly adapted to various spaceborne real-time operating systems and mainstream processor architectures, and has extremely high engineering promotion value. Attached Figure Description

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

[0046] Figure 1This is a schematic diagram of the overall process of the startup integrity measurement method based on link symbol topology of this invention. The diagram fully illustrates the logical closed loop of the entire lifecycle spanning the ground construction phase and the onboard operation phase. Specifically, Phase 1 (S1) describes how the linker script is used to implement hierarchical hybrid fingerprint injection and topology benchmark construction during the ground compilation phase; Phase 2 (S2) details how the verification program performs radiation-resistant dual-dimensional physical measurement and container isolation verification during the initial stage of onboard startup; Phase 3 (S3) clarifies the blocking mechanism when the system detects anomalies, the fault-tolerant logic of primary and backup machine linkage, and the safe interaction process that supports dynamic updates of on-orbit benchmarks.

[0047] Figure 2 This diagram illustrates a comparison of onboard image integrity verification calculations. By visually comparing the traditional hash verification method (based on O(N) linear complexity) with the topology metric method proposed in this invention (based on O(K) constant complexity), it demonstrates the technical advantages of this invention in terms of deep decoupling of computational overhead and image volume. The diagram clearly shows the leap in verification time from seconds / hundreds of milliseconds to microseconds, and the shift in metric dimensions from single content to a dual semantic of "content + physical topology." This aims to support the technological advancements of this invention in achieving instantaneous reset and filling layout security blind spots in onboard hard real-time scenarios.

[0048] Figure 3 This is a schematic diagram of the memory topology and physical address mapping of a spaceborne system. The diagram, along with a physical address growth axis, fully presents the key layout, including the interrupt vector segment (.vector), system startup segment (.start), kernel code segment (.text), read-only data segment (.rodata), cloud-native container pooling segment, initialized data segment (.data), uninitialized data segment (.bss), and system stack segment (.stack). The diagram not only illustrates the differentiated protection logic of the three security levels (SL1-SL3), but also establishes a "logical firewall" between segments through global boundary symbols (anchor points) at the beginning and end of each segment. This clarifies how the invention intercepts the risks of illegal segment overlap and address offsets caused by SEU or tampering through topological measurements of the entire memory space.

[0049] Figure 4 This diagram illustrates the interaction between the fault tracing data structure and the on-orbit baseline update. The upper part of the diagram shows how the system automatically collects eight types of key context information after detecting a topology anomaly and stores them cyclically in 48-byte compressed format in the FRAM tracing area. The lower part details the secure interaction process where the ground control terminal issues a new topology baseline through an encrypted signature channel, and the onboard system performs triple-modular redundancy (TMR) physical hardening and on-orbit update identifier switching. This aims to support the maintainability and fault diagnosis capabilities of this invention during its long-life on-orbit operation. Detailed Implementation

[0050] The following is a further detailed description of the present invention in combination with specific embodiments. The protection scope of the present invention is not limited to the following embodiments. Any equivalent transformation or modification based on the content of the specification and drawings of the present invention shall be included in the protection scope of the present invention. It should be noted that in this embodiment, the spaceborne real-time operating system (StarHeart) and the embedded processor architecture (ARM Cortex-R5) are taken as examples for illustration, but the present invention is equally applicable to other real-time operating systems and processor architectures. This embodiment follows the ECSS-E-ST-40C aerospace software engineering standard and the GJB 2786A military software development requirements. The core storage module preferably uses radiation-resistant FRAM.

[0051] Embodiment 1: Complete verification process for the spaceborne cloud-native + primary / backup redundancy scenario This embodiment corresponds to a typical high-value scenario of spaceborne cloud-native multi-containers and primary / backup redundancy. As Figure 1 shown, the execution process of this method is mainly divided into three stages: static injection, dynamic verification, and linkage blocking. The system memory layout is as Figure 3 shown, including key memory segments of three security levels SL1 - SL3. All core features are implemented based on the ARM Cortex-R5F spaceborne SoC. The specific steps are as follows: 1. Static injection stage ( Figure 1 S1 in ): Topology construction, fingerprint injection, and benchmark solidification Figure 3 (1) Layout definition and symbol injection: Combine

[0052] to configure the GNU LD link script, define the preset physical address ranges of each key memory segment, and strictly follow the address alignment requirements of the processor architecture. Through the linker symbol definition instruction, boundary symbols are injected at the beginning and end of each segment. For the container pooling segment, exclusive symbols are injected in the format bsp_section_container[ID]_[Type]_begin / end, and the container ID is configured as 0 - 3 (to adapt to the requirement of 4 containers), realizing the strong binding of "container identification - boundary symbol - topology benchmark".

[0053] (2) Hybrid fingerprint generation: Read the unique serial number (UID) of the spaceborne CPU and generate fingerprints according to hierarchical configuration. For the SL1 segment, the AES-128 algorithm (accelerated by the SoC hardware engine or optimized by software look-up table) is used in combination with the UID to generate encrypted fingerprints; for the SL2 segment, a hybrid mode (reduced-round encryption + fixed canary identifier 0x5A5A5A5A) is used; for the SL3 segment, a general mode (fixed canary identifier) is used. The modes of each segment are independently configured through linker script macro definitions.

[0053] (3) Baseline data solidification: The address difference between adjacent segments is calculated as the inter-segment offset base. The symbol address, fingerprint content, offset, base version number (bound to firmware V1.0) and on-orbit update identifier are integrated into a baseline data packet and stored in radiation-resistant FRAM (starting from address 0x00040000) using triple modular redundancy (TMR). Three copies are stored with an 8-byte interval to physically isolate and resist multiple bit flips.

[0054] 2. Dynamic verification stage ( Figure 1 S2): Pre-verification during BSP initialization (1) Intervention timing: After system reset, before entering the operating system kernel entry point, a lightweight verification program embedded in the BSP (implemented in pure bare-metal C / assembly, with no OS dependency) is triggered. The program directly addresses the physical address and does not depend on the MMU.

[0055] (2) Self-calibration of the verification program: Before starting, the CRC-32 value of the verification program itself, which is embedded in the FRAM, is read and compared to prevent the verification logic from being tampered with by SEU.

[0056] (3) Hierarchical two-dimensional verification: Executed according to the priority of SL1 > SL2 > SL3.

[0057] a) Location correlation verification: Location correlation verification: Extract the actual physical address of the boundary symbol, obtain a valid benchmark through TMR voting, compare it, verify the inter-segment offset, and detect memory layout drift.

[0058] b) Content integrity verification: Extract the actual data at the boundary, compare it with the benchmark fingerprint, and detect boundary tampering.

[0059] (4) Anti-SEU temporal redundancy: Perform two checks on the same critical segment (1 mm apart), and the result is consistent if they are considered to be passed. Within 100 mm after the kernel takes over, perform a lightweight recheck on the SL1 core segment.

[0060] (5) Performance: This embodiment involves 14 boundary anchor points (K=7), the verification logic complexity is O(7), and the actual execution time is expected to be stable within 80 mm. Figure 2 As shown, compared to the O(N) complexity of traditional hash verification which increases linearly with the image size, this embodiment demonstrates a significant advantage in computational efficiency, fully meeting the requirements for instantaneous reset.

[0061] 3. Joint blocking, source tracing, and on-orbit updates ( Figure 1 (S3) (1) Abnormal Interception and Coordination: If a container's second segment starting address offset (>1 byte) is detected, the kernel jump is immediately blocked, and an exception code is sent to the standby machine. Upon receiving the exception code, the standby machine initiates a self-test and quickly takes over the task. If the standby machine also fails, the system enters minimal safe mode.

[0062] (2) Fault tracing: such as Figure 4 As shown, upon detecting an anomaly, the verification program automatically collects eight types of fault context information and compresses and packages it into a 48-byte fault snapshot. This information includes: anomaly segment identifier and container ID, measured fingerprint value and baseline value, anomaly physical address and offset, SEU suspected location bits, CPU core register snapshot, triple-modulus redundancy majority voting record, the verification program's own CRC status, and a high-precision fault timestamp. This data packet is stored in a cyclic overlay mode in a dedicated FRAM traceability area (supporting 100 historical records). After being transmitted back from the ground via the telemetry and control link, the system can accurately determine whether the fault type is physical damage caused by a single-event upset or a logical attack caused by malicious tampering of the link script.

[0063] (3) On-orbit baseline update: see Figure 4 The timing interaction process involves the following steps: After the firmware is upgraded to V1.1, the ground system issues a reference update command containing a digital signature. Once the signature is verified by the onboard system, the new reference is written to the FRAM and solidified using TMR, with the update flag marked as "updated". The new reference is automatically loaded upon the next startup, eliminating the need for factory return.

[0064] Example 2: Lightweight Implementation for Resource-Constrained Microsatellite Scenarios This embodiment is adapted to the scenario of small satellites with low computing power and low memory. The core retains SL1 / SL2 level verification and simplifies non-core functions: 1. Lightweight Static Injection: All segments use a fixed canary identifier (0x5A5A5A5A), removing encryption algorithm overhead. Symbols are injected only into the SL1 kernel segment and the SL2 read-only segment; the SL3 and container segments are not involved in verification. Baseline data is stored in a single copy (version number is retained for updates).

[0065] 2. Lightweight Dynamic Verification: Eliminate SEU dual verification and self-check, and perform only one two-dimensional comparison.

[0066] 3. Simplified response: Verification failure immediately blocks the process without triggering primary / standby linkage. Fault tracing only records the abnormal segment identifier and fingerprint value.

[0067] 4. Performance: With K=2, the verification time is <30μs, significantly reducing resource consumption.

[0068] Example 3: Implementation of High-Reliability Core Equipment Scenarios This embodiment strengthens radiation resistance end-to-end verification for core equipment such as star management systems and adapts to the StarHeart system Hook mechanism: 1. Full-link Hook verification: The verification program embeds Hook_0 (after hardware initialization and before transfer) to verify the integrity of the static image in Flash; and embeds Hook_1 (after transfer and before jump) to verify the topology structure after loading in RAM, eliminating the risk of tampering in the storage and transmission links.

[0069] 2. Enhanced Radiation Resistance: The reference data uses an enhanced TMR (16-byte copy interval). The verification program code is stored in dual copies in FRAM, and the copy consistency is checked first at startup.

[0070] 3. Fine-grained response: SL1 exception triggers master-slave switchover and records a full CPU register snapshot; SL2 exception records information and allows degraded operation (only core tasks are retained) to maximize system availability.

[0071] Example 4: Implementation of Container Anomaly Isolation in Spaceborne Multi-Container Scenarios This embodiment verifies the isolation logic of 8 containers (ID 0~7) in a cloud-native scenario: 1. Static Binding: Enable "Container Section Templates" to inject a unique symbol (e.g., bsp_section_container7_pool_end) into each container, all configured as SL2-level hybrid fingerprints. Baseline data is bound to the "Container ID - Symbol" relationship.

[0072] 2. Dynamic Isolation: The verification program reads the binding relationship and verifies each container segment in turn. When an abnormal fingerprint of container segment 5 is detected (determined to be container escape), only the startup of container 5 is blocked, without affecting the system core and the operation of the other 7 containers.

[0073] 3. Precise source tracing: Record the abnormal fingerprint and ID of container 5, and the ground team will determine that it is a logical isolation failure rather than a physical fault.

[0074] In summary, this invention, through its flexible configuration strategy, covers various application scenarios ranging from resource-constrained micro-nano satellites to high-performance cloud-native satellites. It verifies the significant advantages of the solution in terms of low intrusion, low overhead, radiation resistance, and on-orbit maintainability, and has extremely high engineering application value.

Claims

1. A method for measuring the integrity of a spaceborne embedded system based on link symbol topology, characterized in that, Includes the following steps: (1) Static injection stage: Configure the linker script, determine multiple key memory segments of the embedded system and divide them into security levels, inject boundary symbols at the beginning and end of each key memory segment, generate hybrid fingerprints, construct a link symbol topology structure containing physical addresses, fingerprints and inter-segment offsets, and solidify the generated baseline data into the non-volatile storage module through a redundancy mechanism. (2) Dynamic verification phase: During the initialization period of the board-level support package before the operating system kernel of the spaceborne system takes over, a lightweight verification program is started, the benchmark data is read and hierarchical two-dimensional verification is performed according to the security level priority; the two-dimensional verification includes the location correlation verification of the physical address of the comparison boundary symbol and the content integrity verification of the comparison symbol content; (3) Linkage blocking and source tracing stage: If the verification fails, the startup will be forcibly stopped, eight types of fault source tracing information will be collected, and fault-tolerant operations will be performed according to the preset strategy.

2. The method according to claim 1, characterized in that, The security levels of the critical memory segments are divided into at least three levels: SL1 is the interrupt vector segment, system startup segment, and kernel code segment; SL2 is the read-only data segment and container pooled memory segment; SL3 is the initialized data segment, uninitialized data segment, and system stack segment; the hybrid fingerprint in the SL1 segment uses an encrypted fingerprint based on a hardware unique identifier.

3. The method according to claim 1, characterized in that, The redundancy mechanism in step (1) is triple modular redundancy (TMR), and the non-volatile storage module includes ferroelectric random access memory (FRAM); when reading the reference data in step (2), a majority voting mechanism is used to obtain valid data.

4. The method according to claim 1, characterized in that, In step (2), SEU redundancy verification is performed: the dual-dimensional verification of the same critical segment is performed at least twice consecutively, and it is determined to pass only when the two results are consistent; and within a preset time after the operating system kernel takes over, the SL1 level memory segment is inspected and reviewed.

5. The method according to claim 1, characterized in that, For the spaceborne cloud native multi-container scenario, step (2) independently verifies the memory segment of a single container by binding the predefined container ID with the boundary symbol; if an anomaly is found, only the loading of that container is blocked.

6. The method according to claim 1, characterized in that, The fault-tolerant operation in step (3) includes: triggering the standby machine to take over when the host machine is abnormal, and entering the system security mode if both machines are abnormal.

7. The method according to claim 1, characterized in that, The method also includes an on-orbit reference update step: receiving and verifying the encrypted signature command issued by the ground telemetry and control link, performing tri-mode redundancy solidification on the new reference data, and updating the on-orbit update identifier.

8. The method according to claim 1, characterized in that, The eight types of fault tracing information collected in step (3) include: abnormal segment identifier and container ID, fingerprint measured value and baseline value, abnormal physical address and offset, suspected bit of single-event flip SEU, CPU core register snapshot, TMR majority voting record, verification program CRC status, and fault timestamp.

9. The method according to claim 1, characterized in that, The time complexity of the method is O(K), where K is the number of critical memory segments. The verification time is decoupled from the total size of the firmware image and remains in the sub-millisecond range.

10. A spaceborne embedded system, characterized in that, It includes a processor and a memory storing a computer program, wherein the processor executes the program to implement the method as described in any one of claims 1 to 9.

Images