Cloud-computing-based game security data efficient storage and recovery system

Abstract

This invention relates to the field of data security technology, specifically to a cloud-based system for efficient storage and recovery of game security data. The system includes a heterogeneous dual-track compilation module, used to compile and output main and backup track program files based on the game logic calculation node source code, generating a dual-track heterogeneous execution carrier, and calculating and generating a dual-track status checksum based on the dual-track heterogeneous execution carrier. In this invention, the dirty page bitmap index parameters are used to match the underlying memory page table of the exception stack, forming a set of damaged memory addresses. Then, the memory page data associated with the original redundant backup pages is extracted by address and overwritten, while the execution frame records within the exception stack are cleared. This allows the recovery action to simultaneously cover both the data and execution planes, repairing the damaged page content and eliminating the continuous interference of residual call chains on subsequent operations. This is suitable for high-concurrency cloud gaming scenarios with requirements for both real-time performance and security.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and in particular to a cloud-based system for efficient storage and recovery of game security data. Background Technology

[0002] Existing technologies for secure data storage and recovery in cloud computing environments typically focus on result preservation and rollback after failures. Fine-grained state differences, path-level anomalies, and thread-related pollution are difficult to continuously capture, leading to problems often only being addressed after explicit errors occur. By this time, the abnormal state has already spread along the execution chain, memory chain, and session chain, significantly increasing recovery costs. Furthermore, current storage operations often process entire images, entire session states, or entire batches of business objects. While the management path is relatively straightforward, in practice, unaffected content is easily included in backup and recovery, creating additional read / write burdens. Cloud storage bandwidth and computing resources are continuously consumed, and recovery wait stacking is more likely to occur in high-frequency state refresh scenarios. Therefore, improvements are needed. Summary of the Invention

[0003] The purpose of this invention is to address the shortcomings of existing technologies by proposing a cloud-based system for efficient storage and recovery of game security data.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: a cloud-based game security data efficient storage and recovery system includes: The heterogeneous dual-track compilation module is used to calculate the node source code based on the game logic, compile and output the main and backup track program files, generate a dual-track heterogeneous execution carrier, and calculate and generate a dual-track status checksum based on the dual-track heterogeneous execution carrier. The redundancy error detection module is used to perform bitwise XOR operation on the dual-track status verification and internal primary and backup track verification values ​​to extract the difference bits, filter and obtain the pollution path identifier, perform a suspension action on the running thread in the cloud server process pool associated with the pollution path identifier, and generate an abnormal process interception list. The memory copy-on-write module is used to locate the target memory page table entry carrying the game state image in the underlying memory page table according to the cloud game state image, generate the original redundant backup page, receive the termination thread restart request associated with the abnormal process interception list, and extract the dirty page bitmap index parameters. The state reversal and recovery module is used to call the dirty page bitmap index parameters, match the target memory page address set in the memory page table at the bottom layer of the exception stack, generate a damaged memory address set, and extract the address memory page data associated with the original redundant backup page in the security verification storage area based on the damaged memory address set to generate a secure rollback game state.

[0005] Preferably, the step of obtaining the dual-track state checksum is as follows: Based on the source code of the game logic calculation node, the compilation configuration fields in the source code are read segment by segment to locate the processor instruction set identifier, compilation optimization flag and load address perturbation control flag. The main track compilation parameters are written according to the main track compilation path and the backup track compilation parameters are written according to the backup track compilation path. Then, cross-compilation is performed according to the main track compilation parameters and the backup track compilation parameters respectively to output the main track program file and the backup track program file, thus obtaining the main and backup track program files. According to the main and backup rail program files, the main rail program file is loaded into the main rail execution point, and the backup rail program file is loaded into the backup rail execution point. Each operation instruction is synchronously written into the main rail program file and the backup rail program file according to the unified operation instruction sequence. The values ​​of variables in the register area, stack area, and heap area after calculation in the main rail program file are recorded one by one. The values ​​of variables in the register area, stack area, and heap area after calculation in the backup rail program file are also recorded one by one. Then, they are spliced ​​together according to a fixed variable order to form a sequence of internal variable status values ​​after calculation in the main and backup rail program files. Based on the internal variable status value sequence calculated from the main and backup track program files, the internal variable status value sequence of the main track and the internal variable status value sequence of the backup track are separated according to a preset value order. The main track internal variable status value sequence is subjected to a hash operation to extract the main track hash value, and the backup track internal variable status value sequence is subjected to a hash operation to extract the backup track hash value. The main track hash value and the backup track hash value are then combined according to a preset check bit order to form a dual-track status checksum.

[0006] Preferably, the step of obtaining the pollution path identifier is as follows: Based on the dual-track status checksum, the main track check value and the backup track check value are split, aligned bit by bit according to the same check bit order, and XOR flags are executed bit by bit. The number of bits with a value of 1 in the XOR result corresponding to each running path segment is counted, and the number of bits is written into the corresponding running path segment record item to form a running path segment difference bit statistics table. Based on the statistical table of differences in the running path segments, the number of differences in all running path segments is extracted, the fault tolerance threshold is calculated, and then the number of differences in each running path segment is compared with the fault tolerance threshold item by item. Running path segments with a number of differences greater than the fault tolerance threshold are screened out to form the pollution path identification quantity.

[0007] Preferably, the steps for obtaining the abnormal process interception list are as follows: Read the running thread identifier in the cloud server process pool corresponding to each polluted running path segment in the polluted path identifier quantity, write a suspension instruction to the running thread identifier one by one, extract the list of process numbers associated with the suspended running thread identifier, issue a clearing instruction item by item and register the clearing result to form an abnormal process interception list.

[0008] Preferably, the step of obtaining the original redundant backup page is as follows: Based on the cloud gaming state image, locate the target memory page table entry that carries the game state image in the underlying memory page table. Read the read permission flag, write permission flag, and shared mapping flag in the target memory page table entry. First, adjust the write permission flag to a restricted state, then retain the read permission flag and shared mapping flag. Trigger the copy-on-write action when writing to the target memory page later. Then, extract the page header address, page byte content, and page check flag from the corresponding read-only memory page before permission modification, and transfer them to the security check storage area in order of page header address to generate the original redundant backup page.

[0009] Preferably, the steps for obtaining the dirty page bitmap index parameters are as follows: Receive thread restart requests corresponding to each terminated thread in the abnormal process interception list, retrieve memory write operation records corresponding to the thread restart requests in the security verification storage area according to the thread identifier, extract the write page start address, write offset position, write length, and write timing mark from each memory write operation record, and then merge and arrange them according to the thread identifier and the write timing mark to form a memory write operation record sequence. Based on the memory write operation record sequence, the write page start address in each memory write operation record is parsed, and the bitmap offset position is calculated according to the page address mapping rules of the global bitmap structure. The write page start addresses that have written actions are entered into the corresponding bits of the global bitmap structure one by one, and a single-time retention mark is executed for the repeatedly entered write page start addresses. Then, the page address mapping results that are set in the global bitmap structure are summarized to generate dirty page bitmap index parameters.

[0010] Preferably, the step of obtaining the damaged memory address set is as follows: Read the bitmap offset positions corresponding to all set flags in the dirty page bitmap index parameters, convert the bitmap offset positions into the target memory page start address item by item according to the page address mapping rules, and then enter the page table of the underlying memory page table of the exception stack to search for the page table entry corresponding to the target memory page start address item by item. Extract the physical page frame identifier, mapping status identifier, and access status identifier from the page table entry, and filter out the target memory page start addresses with valid mapping status and abnormal access status to form a set of damaged memory addresses.

[0011] Preferably, the step of obtaining the safe rollback game state is as follows: According to the starting address of each target memory page in the damaged memory address set, enter the security verification storage area, retrieve the associated address memory page data corresponding to the same page address in the original redundant backup page, read the page byte sequence, page length mark, and page verification mark in the associated address memory page data, and then write the associated address memory page data page by page to the memory area corresponding to the same page address in the target memory page address space, and record the write-back completion status of the starting address of each target memory page to form the memory page write-back result; Based on the memory page write-back results, the starting address of the target memory page with a valid write-back completion status is selected. The stack top pointer position, stack bottom pointer position, return address record area, and local variable record area corresponding to the execution frame record in the exception stack are located. The stack clear instruction is executed to delete the exception return address in the return address record area, clear the exception residual content in the local variable record area, reset the stack top pointer position and stack bottom pointer position, and then combine the target memory page address space that has been overwritten to reconstruct the game state and generate a safe rollback game state.

[0012] Compared with the prior art, the advantages and positive effects of the present invention are as follows: In this invention, primary and backup track program files are formed around the source code of the game logic calculation nodes. During synchronous calculation, the internal variable state value sequence is extracted to generate a dual-track state checksum. This extends the verification object from a single result comparison to continuous verification at the runtime state level, covering both instruction execution deviations and signs of memory variable drift and path pollution. Therefore, identification can be completed before anomalies spread to the storage layer. A bitwise XOR operation is performed on the primary and backup track checksum values, and the polluted path identifier is filtered based on the difference in bit length. Then, the running threads associated with the polluted path identifiers are suspended and cleared. This compresses the anomaly localization granularity from the process level to the runtime path segment and thread level, avoiding the expansion of the computational interruption range caused by a complete pool shutdown, while balancing isolation accuracy and business continuity. The target memory page table entry is located around the cloud game state image, and unextracted entries are extracted. Before modification, only the memory page data is read and transferred to form the original redundant backup page. This allows the backup object to directly correspond to the underlying page-level content, shortening the mirror copy chain and reducing the burden of repeated storage. Combined with the memory write operation record sequence and global bitmap structure to extract the dirty page bitmap index parameters, the subsequent recovery range can be locked to the actual affected page address range, reducing irrelevant data write-back. The dirty page bitmap index parameters are called to match the underlying memory page table of the exception stack, forming a set of damaged memory addresses. Then, the memory page data associated with the original redundant backup page is extracted by address and overwritten. The execution frame records in the exception stack are cleared, so that the recovery action covers both the data plane and the execution plane. This not only repairs the damaged page content but also eliminates the continuous interference of residual call chains on subsequent operations. It is suitable for high-concurrency cloud gaming scenarios with the operational requirements of both real-time performance and security. Attached Figure Description

[0013] Figure 1 This is a system flowchart of the present invention; Figure 2 A comparison chart of the statistical table of differences in the running path segment and the fault tolerance threshold; Figure 3 This is a graph showing the relationship between dirty page bitmaps and corrupted memory addresses based on copy-on-write. Figure 4 Diagram of the primary and backup cross-compilation path. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0015] Please see Figure 1-4 This invention provides a technical solution: a cloud-based game security data efficient storage and recovery system, comprising: The heterogeneous dual-track compilation module is used to calculate the node source code based on the game logic, compile and output the main and backup track program files, generate the dual-track heterogeneous execution carrier, and calculate and generate the dual-track status checksum based on the dual-track heterogeneous execution carrier. The redundancy error detection module is used to perform bitwise XOR operations on the dual-track status verification and internal primary and backup track verification values ​​to extract the difference bits, filter and obtain the pollution path identifier, perform a suspension action on the running threads in the cloud server process pool associated with the pollution path identifier, and generate an abnormal process interception list. The memory copy-on-write module is used to locate the target memory page table entry that carries the game state image in the underlying memory page table based on the cloud game state image, generate the original redundant backup page, receive the termination thread restart request associated with the abnormal process interception list, and extract the dirty page bitmap index parameters. The state reversal and recovery module is used to call the dirty page bitmap index parameter, match the target memory page address set in the memory page table at the bottom layer of the exception stack, generate the damaged memory address set, and extract the address memory page data associated with the original redundant backup page in the security verification storage area to generate a safe rollback game state.

[0016] The steps for obtaining the dual-track state checksum are as follows: Based on the source code of the game logic calculation node, the compilation configuration fields in the source code are read segment by segment to locate the processor instruction set identifier, compilation optimization flag and load address perturbation control flag. The main track compilation parameters are written according to the main track compilation path and the backup track compilation parameters are written according to the backup track compilation path. Then, cross-compilation is performed according to the main track compilation parameters and the backup track compilation parameters respectively to output the main track program file and the backup track program file, thus obtaining the main and backup track program files. Based on the master and backup rail program files, the master rail program file is loaded into the master rail execution point, and the backup rail program file is loaded into the backup rail execution point. Each operation instruction is synchronously written into the master rail program file and the backup rail program file according to the unified operation instruction sequence. The values ​​of variables in the register area, stack area, and heap area after calculation in the master rail program file are recorded one by one. The values ​​of variables in the register area, stack area, and heap area after calculation in the backup rail program file are also recorded one by one. Then, they are spliced ​​together according to the fixed variable order to form the sequence of internal variable status values ​​after calculation in the master and backup rail program files. Based on the internal variable status value sequence calculated from the main and backup rail program files, the internal variable status value sequence of the main rail and the internal variable status value sequence of the backup rail are separated according to the preset value order. The hash operation is performed on the internal variable status value sequence of the main rail to extract the main rail hash value, and the hash operation is performed on the internal variable status value sequence of the backup rail to extract the backup rail hash value. Then, the hash values ​​of the main rail and the backup rail are combined according to the preset check bit order to form a dual-rail status checksum.

[0017] Specifically, based on the game logic calculation node source code, the parser scans the source code text line by line, focusing on matching and extracting comments or macro definitions containing specific prefixes as compilation configuration fields. For example, it searches for fields in the form of `#pragma compiler_config(target_arch, "x86_64_v3")` or ` / / DUAL_TRACK_CONFIG: opt_level=-O2`, parsing out the processor instruction set identifier, such as ARMv8-A or x86_64. It also extracts compilation optimization flags, such as `-O2` (optimization level 2) or `-Os` (optimize code size), and a load address perturbation control flag, which is a hexadecimal memory offset, such as 0x200000. Subsequently, it constructs the main track compilation parameter set and the backup track compilation parameter set. The main track compilation parameters adopt a high-performance-oriented configuration, such as `{arch: "x86_64", opt: "-O3", aslr_offset:}`. The backup track compilation parameters introduce differentiated settings, such as selecting a different optimization level or enabling specific compiler internal options, configured as {arch: "x86_64", opt: "-O1 -fstack-protector-all", aslr_offset: "0x200000"}. The differentiated settings here reduce the optimization level and increase stack protection. Then, the corresponding cross-compilation toolchain is called, such as using GCC or Clang, to apply the main track compilation parameters to the first round of compilation, generating a main track program file named main_track.o. The backup track compilation parameters are then applied to the second round of compilation, and the load address perturbation control flag is passed to the linker script to adjust the program's base address, generating a backup track program file named backup_track.o, thus obtaining the main and backup track program files.

[0018] Based on the primary and backup program files, a controlled execution environment or sandbox is used to load the two files separately. The primary program file is loaded into the default virtual address space, i.e., the primary execution point, while the backup program file is loaded into a virtual address space with an address offset determined by the previously set load address disturbance control flag 0x200000, constituting the backup execution point. Then, a central instruction scheduler synchronizes the execution of both. This scheduler intercepts all external inputs, such as keystrokes, mouse movements, or network packet arrivals, and converts these events into unified operation instructions. Following a strict execution sequence, the same operation instruction, such as "the player character moves forward 10 units," is synchronously distributed to both the primary and backup program instances. This is done after each preset synchronization point, such as at the end of each game loop's rendering frame or after processing a complete network message. After the information packet is processed, a snapshot of the internal state of the two instances is captured using a debugging interface or memory probe technology. The values ​​of variables in the register area of ​​the main program file after calculation are recorded one by one, including the values ​​of general-purpose registers such as RAX, RBX, RCX and instruction pointer register RIP. At the same time, the values ​​of key variables in the stack area are recorded. The addresses of local variables are located and their contents are read by analyzing the stack frame pointer RBP, as well as the memory block data pointed to by the pointer returned by the memory allocation function (such as malloc) in the heap area. The same recording process is performed on the backup program file to obtain the variable values ​​in its register area, stack area and heap area. Finally, according to a fixed variable sorting rule, such as "registers in alphabetical order, stack variables in address from high to low, and heap variables in allocation order", the values ​​of variables with the same name in the main and backup tracks are interleaved or concatenated in sequence to form a long byte sequence, that is, the sequence of internal variable state values ​​after calculation of the main and backup program files.

[0019] Based on the internal variable state value sequence calculated from the primary and backup rail program files, this long byte sequence is split according to a preset value order that is the reverse of the concatenation order. For example, if the sequence is in the form of [RAX_main, RAX_backup, RBX_main, RBX_backup, ...], the elements with indices 0, 2, 4, ... are extracted to reconstruct the primary rail internal variable state value sequence, and the elements with indices 1, 3, 5, ... are extracted to reconstruct the backup rail internal variable state value sequence, thus separating the independent state data of the primary and backup rails. Next, a deterministic hash algorithm, such as SHA-256, is called on the separated primary rail internal variable state value sequence, using the entire sequence's byte content as input for calculation, i.e., H_main = SHA256(byte_sequence_main). After the operation, a 32-byte primary rail hash value is obtained. Similarly, the same hash operation is performed on the backup rail internal variable state value sequence, i.e., H_backup. =SHA256(byte_sequence_backup) yields a 32-byte backup track hash value. Then, to integrate these two hash values ​​while preserving their source information, they are merged according to a preset checksum combination rule. This rule is not a simple concatenation, but rather uses byte interleaving. Specifically, a 64-byte empty buffer is created, and then the first byte of the primary track hash value, the first byte of the backup track hash value, the second byte of the primary track hash value, and the second byte of the backup track hash value are sequentially filled in. This process is repeated until all bytes of both hash values ​​are filled into the buffer. This final 64-byte data is the dual-track status checksum.

[0020] The steps for obtaining pollution path identifiers are as follows: Based on the dual-track status checksum, the main track check value and the backup track check value are split, aligned bit by bit according to the same check bit order, and XORed bit by bit. The number of bits with a value of 1 in the XOR result of each running path segment is counted, and the number of bits is written into the corresponding running path segment record item to form a running path segment difference bit statistics table. Based on the statistical table of differences in operating path segments, the number of differences in all operating path segments is extracted, the fault tolerance threshold is calculated, and then the number of differences in each operating path segment is compared with the fault tolerance threshold item by item. Operating path segments with more than the fault tolerance threshold are screened out to form the pollution path identifier. The formula for calculating the fault tolerance threshold is: ; in, This is the fault tolerance threshold. The average number of differences across all path segments is calculated using the following formula: , The standard deviation of the number of differences across all running path segments is calculated using the following formula: , Based on the fault tolerance amplification factor, This is the fluctuation sensitivity coefficient. The maximum value among all differences in the number of bits across all running path segments. It is the minimum value among the difference bits of all running path segments. This represents the total number of running path segments. For the first The sequence number of each running path segment. For the first The difference in the number of bits per running path segment To prevent division by zero of the stable term, To prevent the removal of zero bias terms.

[0021] Specifically, based on the dual-track state checksum, the 64-byte sequence is first split. Following the interleaving rules used during its generation, bytes with even indices (0, 2, 4, ..., 62) are extracted and concatenated sequentially to reconstruct a 32-byte (256-bit) main track checksum value. Simultaneously, bytes with odd indices (1, 3, 5, ..., ...) are extracted. 63) The two 256-bit checksum values ​​are then concatenated sequentially to reconstruct a 32-byte (256-bit) backup track checksum. Next, these two 256-bit checksum values ​​are bit-aligned. From the most significant bit to the least significant bit, an XOR operation is performed on each pair of bits in the same position. The XOR operation rule is: 0 for identical bits, 1 for dissimilar bits. This process generates a completely new 256-bit binary sequence, where each "1" marks a difference in the primary and backup track states at the corresponding bit. Subsequently, this difference needs to be associated with the specific execution context, i.e., the "running path segment." A running path segment can be defined as the processing cycle of a complete game logic frame, or the complete process of a specific function from entry to return. Throughout the entire execution process, at the end of each running path segment, the aforementioned dual-track state checksum generation and comparison are performed once. Then, for the 256-bit XOR result sequence generated for that running path segment, bit manipulation instructions (such as the POPCNT instruction in the x86 architecture) or loop counting are used to count the total number of bits with a value of "1". This total number is the difference bit number for that running path segment. Finally, the unique identifier of each running path segment (for example, it could be the frame number Frame_1024 or the function call stack hash FuncStack_0xABCD...) and its corresponding difference bit number are stored as a record in a dynamic array or hash table, such as {'path_id': 'Frame_1024', 'diff_bits': 8}. These records are continuously collected to form a running path segment difference bit statistics table.

[0022] The fault tolerance threshold calculation formula combines the conventional outlier detection method in statistics (mean plus a multiple of the standard deviation) with a dynamic adjustment term sensitive to the data distribution pattern. Part One This constitutes a basic threshold that can tolerate most random, harmless differences that conform to a Gaussian distribution. The second part, namely the coefficients... The control involves complex fractions, while also introducing the difference in extreme values ​​of the difference bits. and the total number of running path segments As a key variable, and through the logarithmic function Non-linear scaling is applied when the overall fluctuation range of the difference bits is large ( (For larger numbers), the threshold will be increased accordingly to avoid being overly sensitive to occasional large fluctuations; however, at the same time, the denominator... The term makes the observed sample size When the sample size is large enough, this boosting effect will weaken because a large sample size makes statistical properties (such as mean and standard deviation) more reliable, and accidental extreme values ​​should not overly affect the overall judgment.

[0023] The baseline tolerance amplification factor is used to adjust the width of the baseline threshold, determining the tolerance for deviations from the average level. Its value is set based on statistical analysis of historical normal operation data. Before the system goes live, at least 10 different types of cloud games are collected with over 24 hours of runtime path segment difference data under attack-free, normal operation conditions to form a baseline dataset. The mean and standard deviation of this dataset are calculated, and its distribution histogram is plotted. The goal of setting this is to make the base threshold It can cover 99.5% of the data points in the benchmark dataset, which typically corresponds to about 2.8 standard deviations in a normal distribution. Through repeated iterative testing, an optimal [database / database] is determined. Values, for example, if the test finds that when At that time, 99.53% of the normal variation data fell within the threshold, while when If the coverage rate drops to 99.42%, then 2.0 is a reasonable choice. The value, in this embodiment, is determined using the method described above. The value is 1.5.

[0024] The fluctuation sensitivity coefficient controls how sensitive the threshold is to the overall fluctuation range of the difference bits (i.e., the extreme value difference). Its value determines the system's response strength to sudden, large-amplitude state deviations. The acquisition process involves a series of "micro-attack" injection experiments in a controlled environment. For example, using memory debugging tools, a single byte or a memory word is randomly modified during game runtime to simulate slight data corruption, and the difference in the number of bits caused by these attacks is recorded. The goal is to set a The value that makes the threshold calculated by the formula... Being able to precisely capture these anomalous differences caused by minute attacks, without triggering them due to normal extreme fluctuations, requires a trade-off between detection sensitivity and false alarm rate. For example, setting a series of candidate... For each value (e.g., 0.1, 0.2, ..., 1.0), run 100 mini-attack tests and calculate the detection success rate and the number of false positives during normal operation. Select the test with the highest success rate while keeping the number of false positives below 1 per hour. Value, for example, when At that time, the detection success rate was 95% and the false alarm rate met the requirements, while At that time, the success rate did not improve significantly, but the false alarm rate increased, so 0.8 was chosen as the final value.

[0025] The maximum value among all differences in the number of bits across all running path segments. These two parameters, representing the minimum number of difference bits across all run path segments, are directly obtained from the run path segment difference bit statistics table generated in the previous step, and are used in each calculation of the fault tolerance threshold. Previously, iterated through all the difference bits of all running path segments recorded in the current statistics table. The maximum and minimum values ​​can be found through a single linear scan. This process involves no complex calculations, only data extraction. For example, if the current running path segment difference bit statistics table contains data for 500 running path segments with difference bit values ​​of [5, 8, 3, 12, ..., 25, 4, 9, 2], traversing this array can determine the maximum value. The minimum value is 25. The two values ​​are 2, which reflect the maximum and minimum dispersion of the dual-track state difference within the current statistical period.

[0026] The total number of run path segments represents the sample size used to calculate the current fault tolerance threshold. It is directly equal to the total number of records in the run path segment difference statistics table. This table is either a sliding window or a periodically cleared buffer. For example, the system may be set to recalculate the fault tolerance threshold every 10 minutes or after collecting 500 run path segment data points. Under this setting, when the statistics table is full... The value is 500. This parameter plays a crucial smoothing role in the denominator of the formula, when the sample size... When the system is very small, it is more sensitive to fluctuations; when When the value is large, it indicates that the statistical data is more representative, and the system's tolerance to single anomalies becomes more robust through the smoothing effect of the logarithmic function. In this embodiment, the statistical period is set to 500 running path segments, therefore... The value is 500.

[0027] For the first The number of difference bits in the 1st running path segment is basic data directly read from the running path segment difference bit statistics table, representing the 1st running path segment's difference bit count. Within each execution time slice, the degree of difference in the primary and backup track program states is obtained in detail in the preceding steps. Specifically, it involves counting the number of "1"s in the statistical result after performing an XOR operation on the dual-track state checksum. For example, in a statistical period containing 500 execution path segments, the statistical table stores a sequence of 500 integers, such as [5, 8, 3, 12, 7, ..., 25, 4, 9, 2]. When calculating the mean and standard deviation... It equals 5. It equals 8, and so on, until... The value equals 2; this sequence is used to calculate the dynamic threshold. The basis of all statistics.

[0028] and All values ​​are 0.000001.

[0029] Calculations based on parameters: The parameters obtained from the runtime path segment difference bit statistics table are set as follows: Total number of running path segments ; Average number of differences across all running path segments ; Standard deviation of the number of differences in all running path segments ; The maximum value among all path segment differences ; Minimum of the number of differences among all running path segments ; Based on experience and experiments, the coefficients are set as follows: Basic fault tolerance amplification factor ; Fluctuation sensitivity coefficient ; The numerical stability terms are as follows: Zero-division stabilization term ; Preventing zero bias term ; Substituting the above parameters into the fault tolerance threshold The calculation formula is used to obtain .

[0030] The results indicate that, within the current statistical period, after comprehensively considering the average level, fluctuation, extreme value range, and sample size of the difference bits, the calculated adaptive fault tolerance threshold is 18.81. This value defines the boundary between normal and abnormal conditions. For newly generated running path segments, the difference bits... It will be compared with this threshold, if If so, the path segment is considered normal, and minor state differences are tolerated; if If the number of differences is greater than the calculated fault tolerance threshold, the path segment will be judged as abnormal and marked as a contaminated path identifier, thereby triggering the subsequent error isolation and recovery process.

[0031] The steps to obtain the list of abnormal process interceptors are as follows: Read the running thread identifiers in the cloud server process pool corresponding to each polluted running path segment in the polluted path identifier quantity, write suspend instructions to the running thread identifiers one by one, extract the list of process numbers associated with the suspended running thread identifiers, issue clear instructions item by item and register the clearing results to form an abnormal process interception list.

[0032] Specifically, the process reads the polluted path identifiers, which are a list containing multiple polluted execution path segment identifiers, such as ['Frame_1024', 'FuncStack_0xABCD...']. It iterates through each identifier in this list and uses a pre-built mapping table to find the specific thread identifier executing that path segment within the cloud server process pool. This mapping table is populated when the thread is created, with the path segment identifier as the key and the thread ID (TID) as the value, such as TID_12345. After obtaining the thread identifier, a SIGSTOP signal is immediately sent to the thread through the operating system kernel interface. This is a suspend instruction that cannot be caught, blocked, or ignored, forcing the thread to pause execution. The result of sending is recorded as "success" or "failure". After confirming that the thread has been successfully suspended, the thread's status information in the operating system process scheduler is read, specifically by parsing the / proc / [TID] / status file and extracting its status information. The Tgid field in the code, which is the thread group ID, is the process ID (PID) to which the thread belongs, such as PID_54321. This PID is added to a pending set to avoid duplicate operations. Then, a SIGKILL signal is issued to this PID as a clearing instruction. This signal will unconditionally terminate the entire process and all its threads. After the instruction is issued, the clearing result is verified by polling the / proc file system to check if a directory named with the PID exists. If the directory disappears, the clearing result is recorded as "success". If the directory still exists after the set timeout (e.g., 500 milliseconds), it is recorded as "failure" and an error log is recorded. The suspended thread identifier, the associated process number, the suspended status, and the clearing result are recorded as an entry, such as {thread_id: TID_12345, process_id: PID_54321, suspend_status: 'SUCCESS', clear_status: 'SUCCESS'}. All these entries are summarized to form an abnormal process interception list.

[0033] The steps to obtain the original redundant backup pages are as follows: Based on the cloud gaming state image, locate the target memory page table entry that carries the game state image in the underlying memory page table. Read the read permission flag, write permission flag, and shared mapping flag in the target memory page table entry. First, adjust the write permission flag to a restricted state, then retain the read permission flag and shared mapping flag. Trigger the copy-on-write action when writing to the target memory page later. Then, extract the page header address, page byte content, and page check flag from the corresponding read-only memory page before permission modification, and transfer them to the security check storage area in order of page header address to generate the original redundant backup page.

[0034] Specifically, based on the cloud gaming state image, the starting address and size of the image in the virtual memory space are first determined, for example, starting from 0x80000000 and having a size of 2GB. Then, using the operating system's memory page size (usually 4KB) as a unit, all memory pages within that address range are traversed. For each virtual page address, such as 0x80001000, its corresponding underlying memory page table entry (PTE) is located by querying the multi-level page table structure. This process starts from the top-level page table directory (PGD), parsing downwards level by level to the page parent directory (PUD), page intermediate directory (PMD), and finally reaching the page table (PT) to find... The kernel retrieves the access control bits stored in the PTE containing the virtual address mapping information. Specifically, it reads the read permission flag (e.g., the R / W bit in an x86 architecture PTE), the write permission flag (also an R / W bit), and the shared mapping flag. Before modification, it forcibly sets the write permission flag of the PTE from 1 (writable) to 0 (read-only), while keeping the read permission flag and the shared mapping flag unchanged. This operation is performed through a kernel-level function call. The modified PTE is then written back to memory. This setting ensures that any subsequent write operation to this memory page will trigger a page fault. When a Fault occurs, the operating system's Copy-on-Write mechanism is activated. Before any permissions are modified, a complete backup of the memory page is immediately performed. Specifically, the page header address (0x80001000) is extracted, and the 4096 bytes of the page's internal bytes are copied to a buffer using the memcpy function. A CRC32 checksum (e.g., 0xABCDEF12) is calculated on the copied content as a page checksum marker. Finally, the page header address, page content, and page checksum marker are stored as a structure and appended to a pre-allocated, protected security checksum storage area in ascending order of the page header address. This process is continuously performed on all memory pages in the state mirror to generate the original redundant backup page.

[0035] The steps to obtain the dirty page bitmap index parameters are as follows: Receive thread restart requests corresponding to each terminated thread in the abnormal process interception list, retrieve memory write operation records corresponding to the thread restart requests in the security verification storage area according to the thread identifier, extract the write page start address, write offset position, write length, and write timing mark from each memory write operation record, and then merge and arrange them according to the thread identifier and the write timing mark to form a sequence of memory write operation records. Based on the memory write operation record sequence, the write page start address in each memory write operation record is parsed, and the bitmap offset position is calculated according to the page address mapping rules of the global bitmap structure. The write page start addresses that have occurred are entered into the corresponding bits of the global bitmap structure one by one, and a single-time retention mark is executed for the repeatedly entered write page start addresses. Finally, the page address mapping results that are set in the global bitmap structure are summarized to generate dirty page bitmap index parameters.

[0036] Specifically, when a thread restart request is received from an external management module or user-triggered request targeting a terminated thread in the abnormal process interception list, this request contains a clear thread identifier, such as TID_12345. First, based on this thread identifier, a search is performed in the security verification storage area. This storage area not only stores the original redundant backup pages but also maintains a real-time log of memory write operations triggered by the copy-on-write mechanism. Each record in this log contains information about which thread performed a write operation on which memory address at what time. The search process involves filtering all log records where the thread identifier field matches TID_12345. For each matching memory write operation record, for example: {timestamp: 1678886400.123, thread_id: TID_12345, page_addr: 0x80001000, offset: 2048, length: 4, data: 0xDEADBEEF}, extract the key metadata one by one: write the page start address (0x80001000), which identifies the modified memory page; write offset position (2048), which is the byte offset within the page; write length (4), which is the size of the modified data; and write timing mark (1678886400.123), a high-precision timestamp. After extracting all write operation records related to TID_12345, merge them according to the thread identifier, and arrange these records in strict ascending order according to the write timing mark. This arrangement reconstructs the precise time sequence of all write operations that caused changes in memory state before the thread was terminated, thus forming an ordered sequence of memory write operation records for a specific thread.

[0037] Based on the sequential memory write operation record sequence generated in the previous step, a global bitmap structure is initialized. The size of this bitmap is determined by the total virtual memory space of the cloud server. For example, for a 1TB virtual address space and a 4KB page size, a bitmap of 1TB / 4KB = 2^28 bits is required. All bits of the bitmap are initially set to 0. Then, each record in the memory write operation record sequence is traversed, and the write page start address in the record is parsed out, for example, 0x80001000. Next, this physical address is converted into an offset position in the bitmap according to a globally unified page address mapping rule. The rule is: Bitmap offset position = write page start address / page size. For example, 0x80001000 / 4096 = 524289. After obtaining the bitmap offset position, the bit of the corresponding index in the global bitmap structure is set to 1. This operation uses a bitwise OR operation (bitmap[index] |= 1) This operation automatically handles the problem of repeated entries. That is, no matter whether a memory page is written once or multiple times, the corresponding bit in the bitmap will only be set to 1 once. This is the implementation of the single-retention flag. After traversing the entire memory write operation record sequence, the entire global bitmap structure is scanned again to summarize the indices of all bits set to 1, that is, the bitmap offset positions. These index values ​​are collected into a list, such as [524289, 524291, 524300, ...]. This list is the final dirty page bitmap index parameter.

[0038] The steps to obtain the damaged memory address set are as follows: Read the bitmap offset positions corresponding to all set flags in the dirty page bitmap index parameters, convert the bitmap offset positions into the target memory page start address item by item according to the page address mapping rules, and then enter the page table of the underlying memory page table of the exception stack to search for the page table entry corresponding to the target memory page start address item by item. Extract the physical page frame identifier, mapping status identifier, and access status identifier from the page table entry, filter out the target memory page start addresses with valid mapping status and abnormal access status, and form a set of damaged memory addresses.

[0039] Specifically, the dirty page bitmap index parameter is read. This parameter is an integer list containing the bitmap offset positions corresponding to all memory pages marked as dirty, for example, [524289, 524291, 524300]. Each bitmap offset position in this list is traversed, and a reverse conversion is performed according to a predefined page address mapping rule: target memory page start address = bitmap offset position × page size. Setting the page size to 4096 bytes, the offset position 524289 is converted to the target memory page start address 524289 × 4096 = ... 0x80001000. This conversion is performed on all offset positions in the list to obtain a temporary list of target memory page start addresses. Then, for each target memory page start address in this temporary list, within the exception stack context of the current process, the physical base address of the top-level page table directory is obtained by accessing the CPU's control register (e.g., the CR3 register in x86-64 architecture). Starting from this base address, using the high-order bits of the target memory page start address as an index, the four-level page table structure (Page Global Directory PGD, Page Parent Directory PUD, Page Middle Directory PMD, Page Table PT) is traversed level by level until the lowest-level page table entry (PTE) managing the memory page is located. The page table entry is then extracted from this PTE. The physical page frame identifier (i.e., the base address of the physical memory page), and several status and access control bits, including the mapping status identifier (Present bit, value 1 indicates that it has been mapped to physical memory) and the access status identifier (Dirty bit, value 1 indicates that the page has been written to since the last zeroing), are then filtered. The filtering conditions are: the mapping status identifier must be valid, that is, the Present bit is 1, and the access status identifier must be abnormal. Here, abnormal is defined as the Dirty bit being 1, because a page marked as dirty means that it contains write content from a terminated abnormal process. The starting addresses of all target memory pages that meet these two conditions are collected to form a set of damaged memory addresses.

[0040] The steps to safely roll back the game state are as follows: According to the starting address of each target memory page in the damaged memory address set, enter the security verification storage area, retrieve the associated address memory page data corresponding to the same page address in the original redundant backup page, read the page byte sequence, page length mark, and page verification mark in the associated address memory page data, and then write the associated address memory page data page by page to the memory area corresponding to the same page address in the target memory page address space, and record the write-back completion status of the starting address of each target memory page to form the memory page write-back result; Based on the memory page write-back results, the starting address of the target memory page with a valid write-back status is selected. The stack top pointer position, stack bottom pointer position, return address record area, and local variable record area corresponding to the execution frame record in the exception stack are located. The stack clear instruction is executed to delete the exception return address in the return address record area, clear the exception residual content in the local variable record area, reset the stack top pointer position and stack bottom pointer position, and then combine the target memory page address space that has been overwritten to reconstruct the game state and generate a safe rollback game state.

[0041] Specifically, based on the starting address of each target memory page in the damaged memory address set, for example, 0x80001000, this address is used as the key to quickly retrieve the page in the security verification storage area. This storage area is implemented as a hash table structure, storing the original redundant backup pages of all protected memory pages. The retrieval operation returns the associated address memory page data structure that matches the original address. If successfully found, three core parts are read from this data structure: the page byte sequence, which is an array of 4096 bytes, representing the original, uncontaminated content of the memory page; the page length marker, with a value of 4096, used to verify data integrity; and the page checksum, a 32-bit checksum calculated using the CRC32 algorithm during backup, for example, 0xABCDEF12. Before performing the recovery write, the CRC checksum of the read page byte sequence is run again. The CRC32 algorithm calculates a new checksum and compares it with the stored page checksum. If they match perfectly, it proves that the backup data is complete and has not been tampered with. At this point, a kernel-level memory operation function is called to write the 4096-byte page byte sequence page by page into the memory area specified by the target memory page's starting address 0x80001000 in the current memory space by forcibly overwriting each page. After the write is complete, the write-back completion status of the target memory page's starting address is recorded as "success" in a temporary result record table. If the CRC32 check fails, it indicates that the backup page is corrupted and cannot be used for recovery. In this case, its write-back completion status is recorded as "failure," and an error log is recorded. This process is repeated for all addresses in the damaged memory address set. The final result record table is the memory page write-back result.

[0042] Based on the memory page write-back results, the result record table is first traversed to filter out the starting addresses of all target memory pages marked as "valid" (i.e., "successful") in the write-back completion status. These addresses represent that their corresponding memory regions have been successfully restored to a clean state. Next, for the thread about to be restarted, its execution stack needs to be cleaned up. By accessing the thread's kernel control block (TCB), the memory region of its stack and key register contexts are located, including the preset positions of the stack top pointer (e.g., the RSP register in x86-64 architecture) and the stack bottom pointer (RBP register). The record areas related to the previous execution frame in the exception stack are located, including the return address record area storing function return addresses and the local variable record area used to store local variables. A complete stack clearing instruction sequence is executed. This sequence first calls functions such as memset to clear the stack. The entire memory region from the current top to the bottom of the stack is overwritten with zeros. This clears all residual exception content in the local variable record area and erases the exception return address in the return address record area. Then, the values ​​of the RSP and RBP registers stored in the thread context are reset to the initial top address of the thread's stack space, i.e., a known and safe location. At the same time, the value of the instruction pointer register (RIP) is set to a predefined safe rollback point, such as the starting address of the game's main loop. Finally, combined with the target memory page address space that has been overwritten, the memory data and the thread execution context (stack and instruction pointer) are now in a clean and known state. By sending a signal to the operating system scheduler to resume thread execution (e.g., SIGCONT), the thread restarts execution from the safe rollback point, completing the reconstruction of the game state and generating a safe rollback game state.

Claims

1. A cloud-based system for efficient storage and recovery of game security data, characterized in that: The system includes: The heterogeneous dual-track compilation module is used to calculate the node source code based on the game logic, compile and output the main and backup track program files, generate a dual-track heterogeneous execution carrier, and calculate and generate a dual-track status checksum based on the dual-track heterogeneous execution carrier. The redundancy error detection module is used to perform bitwise XOR operation on the dual-track status verification and internal primary and backup track verification values ​​to extract the difference bits, filter and obtain the pollution path identifier, perform a suspension action on the running thread in the cloud server process pool associated with the pollution path identifier, and generate an abnormal process interception list. The memory copy-on-write module is used to locate the target memory page table entry carrying the game state image in the underlying memory page table according to the cloud game state image, generate the original redundant backup page, receive the termination thread restart request associated with the abnormal process interception list, and extract the dirty page bitmap index parameters. The state reversal and recovery module is used to call the dirty page bitmap index parameters, match the target memory page address set in the memory page table at the bottom layer of the exception stack, generate a damaged memory address set, and extract the address memory page data associated with the original redundant backup page in the security verification storage area based on the damaged memory address set to generate a secure rollback game state.

2. The cloud-based game security data efficient storage and recovery system according to claim 1, characterized in that, The steps for obtaining the dual-track state checksum are as follows: Based on the source code of the game logic calculation node, the compilation configuration fields in the source code are read segment by segment to locate the processor instruction set identifier, compilation optimization flag and load address perturbation control flag. The main track compilation parameters are written according to the main track compilation path and the backup track compilation parameters are written according to the backup track compilation path. Then, cross-compilation is performed according to the main track compilation parameters and the backup track compilation parameters respectively to output the main track program file and the backup track program file, thus obtaining the main and backup track program files. According to the main and backup rail program files, the main rail program file is loaded into the main rail execution point, and the backup rail program file is loaded into the backup rail execution point. Each operation instruction is synchronously written into the main rail program file and the backup rail program file according to the unified operation instruction sequence. The values ​​of variables in the register area, stack area, and heap area after calculation in the main rail program file are recorded one by one. The values ​​of variables in the register area, stack area, and heap area after calculation in the backup rail program file are also recorded one by one. Then, they are spliced ​​together according to a fixed variable order to form a sequence of internal variable status values ​​after calculation in the main and backup rail program files. Based on the internal variable status value sequence calculated from the main and backup track program files, the internal variable status value sequence of the main track and the internal variable status value sequence of the backup track are separated according to a preset value order. The main track internal variable status value sequence is subjected to a hash operation to extract the main track hash value, and the backup track internal variable status value sequence is subjected to a hash operation to extract the backup track hash value. The main track hash value and the backup track hash value are then combined according to a preset check bit order to form a dual-track status checksum.

3. The cloud-based game security data efficient storage and recovery system according to claim 1, characterized in that, The steps for obtaining the pollution path identifier are as follows: Based on the dual-track status checksum, the main track check value and the backup track check value are split, aligned bit by bit according to the same check bit order, and XOR flags are executed bit by bit. The number of bits with a value of 1 in the XOR result corresponding to each running path segment is counted, and the number of bits is written into the corresponding running path segment record item to form a running path segment difference bit statistics table. Based on the statistical table of differences in the running path segments, the number of differences in all running path segments is extracted, the fault tolerance threshold is calculated, and then the number of differences in each running path segment is compared with the fault tolerance threshold item by item. Running path segments with a number of differences greater than the fault tolerance threshold are screened out to form the pollution path identification quantity.

4. The cloud-based game security data efficient storage and recovery system according to claim 1, characterized in that, The steps for obtaining the abnormal process interception list are as follows: Read the running thread identifier in the cloud server process pool corresponding to each polluted running path segment in the polluted path identifier quantity, write a suspension instruction to the running thread identifier one by one, extract the list of process numbers associated with the suspended running thread identifier, issue a clearing instruction item by item and register the clearing result to form an abnormal process interception list.

5. The cloud-based game security data efficient storage and recovery system according to claim 1, characterized in that, The steps for obtaining the original redundant backup pages are as follows: Based on the cloud gaming state image, locate the target memory page table entry that carries the game state image in the underlying memory page table. Read the read permission flag, write permission flag, and shared mapping flag in the target memory page table entry. First, adjust the write permission flag to a restricted state, then retain the read permission flag and shared mapping flag. Trigger the copy-on-write action when writing to the target memory page later. Then, extract the page header address, page byte content, and page check flag from the corresponding read-only memory page before permission modification, and transfer them to the security check storage area in order of page header address to generate the original redundant backup page.

6. The cloud-based game security data efficient storage and recovery system according to claim 1, characterized in that, The steps for obtaining the dirty page bitmap index parameters are as follows: Receive thread restart requests corresponding to each terminated thread in the abnormal process interception list, retrieve memory write operation records corresponding to the thread restart requests in the security verification storage area according to the thread identifier, extract the write page start address, write offset position, write length, and write timing mark from each memory write operation record, and then merge and arrange them according to the thread identifier and the write timing mark to form a memory write operation record sequence. Based on the memory write operation record sequence, the write page start address in each memory write operation record is parsed, and the bitmap offset position is calculated according to the page address mapping rules of the global bitmap structure. The write page start addresses that have written actions are entered into the corresponding bits of the global bitmap structure one by one, and a single-time retention mark is executed for the repeatedly entered write page start addresses. Then, the page address mapping results that are set in the global bitmap structure are summarized to generate dirty page bitmap index parameters.

7. The cloud-based game security data efficient storage and recovery system according to claim 1, characterized in that, The steps for obtaining the damaged memory address set are as follows: Read the bitmap offset positions corresponding to all set flags in the dirty page bitmap index parameters, convert the bitmap offset positions into the target memory page start address item by item according to the page address mapping rules, and then enter the page table of the underlying memory page table of the exception stack to search for the page table entry corresponding to the target memory page start address item by item. Extract the physical page frame identifier, mapping status identifier, and access status identifier from the page table entry, and filter out the target memory page start addresses with valid mapping status and abnormal access status to form a set of damaged memory addresses.

8. The cloud-based game security data efficient storage and recovery system according to claim 1, characterized in that, The steps for obtaining the secure rollback game state are as follows: According to the starting address of each target memory page in the damaged memory address set, enter the security verification storage area, retrieve the associated address memory page data corresponding to the same page address in the original redundant backup page, read the page byte sequence, page length mark, and page verification mark in the associated address memory page data, and then write the associated address memory page data page by page to the memory area corresponding to the same page address in the target memory page address space, and record the write-back completion status of the starting address of each target memory page to form the memory page write-back result; Based on the memory page write-back results, the starting address of the target memory page with a valid write-back completion status is selected. The stack top pointer position, stack bottom pointer position, return address record area, and local variable record area corresponding to the execution frame record in the exception stack are located. The stack clear instruction is executed to delete the exception return address in the return address record area, clear the exception residual content in the local variable record area, reset the stack top pointer position and stack bottom pointer position, and then combine the target memory page address space that has been overwritten to reconstruct the game state and generate a safe rollback game state.

Images