CN114238023A - Method and device for controlling multi-thread program redundant execution - Google Patents

Method and device for controlling multi-thread program redundant execution Download PDF

Info

Publication number
CN114238023A
CN114238023A CN202111564357.9A CN202111564357A CN114238023A CN 114238023 A CN114238023 A CN 114238023A CN 202111564357 A CN202111564357 A CN 202111564357A CN 114238023 A CN114238023 A CN 114238023A
Authority
CN
China
Prior art keywords
variant
system call
thread
slave
main
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111564357.9A
Other languages
Chinese (zh)
Inventor
韩首魁
潘传幸
张高举
李昂
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhengzhou Angshi Information Technology Co ltd
Original Assignee
Zhengzhou Angshi Information Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zhengzhou Angshi Information Technology Co ltd filed Critical Zhengzhou Angshi Information Technology Co ltd
Priority to CN202111564357.9A priority Critical patent/CN114238023A/en
Publication of CN114238023A publication Critical patent/CN114238023A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3051Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3065Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/544Buffers; Shared memory; Pipes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/50Indexing scheme relating to G06F9/50
    • G06F2209/5018Thread allocation

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Hardware Redundancy (AREA)

Abstract

The application discloses a method and a device for controlling the redundant execution of a multithread program, which aim to record and process the main variant system call which needs to be synchronized in a slave variant through monitoring the thread level system call of the main variant and replay the system call record of the main variant to the slave variant end, so that each thread of the slave variant executes a system call sequence which is consistent with the main variant, thereby avoiding the multithreading disorder execution problem of different variants in a mimicry software process and correspondingly avoiding the generation of false positive errors during voting, in addition, the application only records and replays partial system calls (namely the system calls which need to be synchronized in the slave variant) in an aiming mode, such as file reading and writing, file replacement and the like, thereby finally voting only partial system calls are needed, and a monitor does not need to intervene in each system call executed by the variant, therefore, the safety of the mimicry software kernel is further improved.

Description

Method and device for controlling multi-thread program redundant execution
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for controlling redundant execution of a multithreading program.
Background
The mimicry software is a software individual with equivalent function and different structure, the mimicry software can be expressed as a plurality of processes or a plurality of threads, the mimicry software execution architecture uses a software diversification technology to construct a variant set with equivalent function, each variant selected from the set is endowed with the same input during running, and then the output behavior of each variant is monitored through a monitor and the divergence between the variants is detected. The dynamic software execution architecture is a continuation and supplement of diversified technologies to solve security problems, and can be added into an execution framework as a variant 'source' as long as diversified individuals meet attack surfaces to a certain extent and are not intersected in a large range. The execution of the software for the emulation does not seek to protect some information in the program which can be utilized by an attacker by using an 'encryption' method, as long as diversified program variants have a spatial or temporal difference in exploitation among each other.
The applicant finds that the current design of the kernel of the mimicry software has a safety problem, and the multi-thread out-of-order execution of different variants in the process of the mimicry software can cause false positive errors in voting.
Disclosure of Invention
In view of the above, the present application provides a method and an apparatus for controlling redundant execution of a multithread program, which are used to at least partially solve the technical problem of the existing mimicry software execution mode.
The specific technical scheme is as follows:
a method of controlling redundant execution of a multi-threaded program, comprising:
monitoring thread-level system calls of the master variant;
determining whether the monitored thread-level system call is a system call which needs to be synchronized from a variant; wherein the master variant and the slave variant each comprise a same number of multiple threads;
if so, recording the thread-level system call to update the system call record of the main variant; the system call record includes: each thread of the main variant corresponds to a system calling sequence which is generated according to a time line and needs to be synchronized to each system call of the slave variant;
and recording and replaying the system call to the slave variant end so that each thread of the slave variant executes a system call sequence consistent with the corresponding thread of the master variant.
Optionally, the monitoring the thread-level system call of the main variant includes:
and monitoring the thread-level system call of the main variant by intercepting the thread-level system call instruction of the main variant.
Optionally, after determining whether the monitored thread-level system call is a system call to be synchronized from a variant, the method further includes:
if not, stopping intercepting the thread-level system call so as to enable the program of the main variant to continue running.
Optionally, the determining whether the monitored thread-level system call is a system call that needs to be synchronized from a variant includes:
determining whether the thread-level system call is a system call which influences the multithreading redundant execution result and causes the execution result to change;
if yes, determining the thread-level system call as a system call needing synchronization from the variant;
if not, determining the thread-level system call to be a system call that does not need to be synchronized from the variant.
Optionally, in the executing process of the master variant or the slave variant, the master variant or the slave variant calls a system before and after the master variant or the slave variant to use a mutual exclusion lock to use a shared resource; and for the system call needing synchronization, one variant can only have one thread to execute the system call at the same time.
Optionally, the method uses a decision module to intercept the thread-level system call of the master variant, and determines whether the intercepted thread-level system call is a system call that needs to be synchronized in the slave variant.
Optionally, the decision module supports instruction interception and decision of a Linux multi-variant execution environment of an x86 framework, and can be deployed in a cross-platform execution variant.
Optionally, the method uses a buffer synchronization module to record the thread-level system call;
the buffer area synchronization module opens up a buffer area, records thread level system call of the main variant and the thread level system call of the main variant to the opened buffer area, maintains execution sequence of different system calls of different threads of the main variant, and synchronizes the recorded system call sequence to the slave variant, so that each thread of the slave variant executes each system call of the thread corresponding to the main variant according to the same sequence.
Optionally, the master variant and the slave variant are independent of each other, functionally equivalent, and structurally different.
An apparatus for controlling redundant execution of a multi-threaded program, comprising:
a monitoring unit for monitoring thread-level system calls of the master variant;
the determining unit is used for determining whether the monitored thread-level system call is a system call which needs to be synchronized from a variant; wherein the master variant and the slave variant each comprise a same number of multiple threads;
a recording unit, configured to perform recording processing on the thread-level system call to update a system call record of the main variant if the determining unit is yes; the system call record includes: each thread of the main variant corresponds to a system calling sequence which is generated according to a time line and needs to be synchronized to each system call of the slave variant;
and the replay unit is used for replaying the system call record to the slave variant end so that each thread of the slave variant executes a system call sequence consistent with the corresponding thread of the main variant.
According to the scheme, the method and the device for controlling the redundant execution of the multithreading program provided by the application can be used for controlling the redundant execution of the multithreading program, by monitoring the thread-level system call of the main variant, performing the record processing on the monitored main variant system call needing to be synchronized in the slave variant in a targeted manner, and recording and replaying the system call of the main variant to the slave variant end, each thread of the slave variant executes the system call sequence consistent with the main variant, so that the problem of multi-thread out-of-order execution of different variants in the mimicry software process is avoided, and accordingly, the false positive error generated in voting can be avoided, in addition, only part of the system calls (namely the system calls needing to be synchronized in the slave variant) are recorded and replayed in a targeted manner, such as file reading and writing, file replacement and the like, so that only part of the system calls are needed to be voted finally, and the monitor does not need to intervene in each system call executed by the variant, therefore, the safety of the mimicry software kernel is further improved.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
FIG. 1 is a flow chart illustrating a method for controlling redundant execution of a multi-threaded program according to the present application;
FIG. 2 is an application architecture diagram of a method of controlling redundant execution of a multi-threaded program as provided herein;
FIG. 3 is a schematic diagram illustrating a synchronization strategy of a buffer synchronization module provided in the present application;
fig. 4 is a block diagram of an apparatus for controlling redundant execution of a multi-thread program according to the present application.
Detailed Description
For the sake of reference and clarity, the technical terms, abbreviations or abbreviations used hereinafter are to be interpreted in summary as follows:
page table: is a data structure used by virtual memory systems to store a mapping between logical addresses and physical addresses. The process is divided into pages, the page table has rows, and each row records the corresponding relation between one page of the process and the page number and the block number of the physical block stored in the process. The page table is used for address translation.
TLB: translation Lookaside Buffer, also translated into page table cache, Translation bypass cache, a type of cache for the CPU.
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
The applicant researches and discovers that the structure of a simulation software execution environment is complex and is generally composed of a monitor, an executor and a voter, the current simulation software kernel design is problematic from the security point of view, the monitor needs to intervene in each system call executed by a variant, the memory damage is caused by great loss due to too many special functions for frequently comparing and copying complex data structures, and in the case of the kernel monitor, the monitor is easy to endanger the whole system, once the right is submitted, the whole system is exposed to the outside, and the operation is very costly due to the need of switching a page table and a TLB (Translation Lookaside Buffer). In addition, when the voter votes whether the output results of different variants are the same according to the output behaviors of the different variants and the divergence between the output behaviors, false positive errors are generated during voting due to the fact that the multithread of the different variants is executed out of order in the mimicry software process, namely false error reporting information that the output results of the different variants are inconsistent is given out due to the fact that the execution orders of the different variants on system calling are different, and false alarms are generated.
In order to at least partially solve the above technical problems of the existing mimicry software execution mode, embodiments of the present application provide a method and an apparatus for controlling redundant execution of a multi-thread program.
As shown in fig. 1, a flowchart of a method for controlling redundant execution of a multithread program provided in an embodiment of the present application specifically includes:
step 101, monitoring the thread-level system call of the master variant.
In order to overcome the problem of multi-thread out-of-order execution of different variants in a mimicry software process and further avoid false positive errors, the embodiment of the present application proposes a concept of a master variant and a slave variant, wherein the master variant runs first, and the slave variant is controlled to execute operations (system calls) in the same order for synchronization by capturing the order in which the master variant executes the operations (system calls).
The master variant and the slave variant are different variants which are independent, functionally equivalent and structurally different, and specifically can be different variants in a functionally equivalent variant set constructed by a software diversification technology by using a simulated software execution architecture. When different variants are executed, each variant selected from the set is endowed with the same input, the output behavior of each variant is monitored through a monitor, the divergence between the variants is detected, and finally, whether the output results of the different variants are consistent or not is voted.
The number of threads in each variant in the variant set is multiple, namely the number of threads n of each variant is more than or equal to 2.
According to the embodiment of the application, the thread-level system call of the main variant is monitored by intercepting the thread-level system call instruction of the main variant.
Step 102, determining whether the monitored thread-level system call is a system call which needs to be synchronized from a variant; wherein the master variant and the slave variant each comprise a same number of multiple threads.
After intercepting the thread level system call of the main transformer, determining whether the intercepted thread level system call is a system call which can influence the multithreading redundant execution result to cause the execution result to change, if so, determining that the thread level system call is a system call which needs to be synchronized from the variant, and if not, determining that the thread level system call is a system call which does not need to be synchronized from the variant.
That is, the present application performs synchronization from variants only for some sensitive system calls that may affect the multithreading redundant execution result and cause a change in the execution result, such as sensitive system calls for file reading and writing, file replacement, and the like, which are also calls with a high security factor.
The embodiment of the application specifically adopts a judgment module to intercept the thread-level system call instruction of the master variant, and judges whether the intercepted thread-level system call is a system call which needs to be synchronized in the slave variant.
In implementation, referring to the application architecture diagram of the method for controlling the redundant execution of the multi-thread program provided in fig. 2, optionally, the architecture includes an application program and a monitoring agent, and the application program is an application program of a master variant or a slave variant.
As shown in fig. 2, in the user state, the monitoring agent is equivalent to an independent process, and includes a decision module and a buffer synchronization module, where the decision module is configured to intercept a thread-level system call instruction of the master variant, and determine whether the intercepted thread-level system call is a system call that needs to be synchronized in the slave variant, that is, the decision module is configured to dynamically select a system call for executing a system call synchronization task, and is responsible for screening a system call that meets multiple threads of the master variant and needs to be synchronized in the slave variant during execution.
The decision module supports instruction interception and decision of the Linux multi-variant execution environment of the x86 framework and can be deployed in cross-platform execution variants.
103, if yes, recording the thread-level system call to update the system call record of the main variant; the system call record includes: and each thread of the main variant corresponds to a system call sequence which is generated according to a time line and needs to be synchronized to each system call of the slave variant.
After the monitoring agent intercepts the system call of the main transformer, the judgment module judges, if the slave transformer needs to be synchronously processed, the judgment module sends the system call to the buffer zone synchronization module, and the buffer zone synchronization module is adopted to record and process the thread-level system call.
The buffer synchronization module receives the thread-level system call transmitted by the decision module, applies for opening up a buffer, records the thread-level system call of the main variant and the thread to which the main variant thread-level system call belongs to the opened buffer, and maintains the execution sequence of different system calls of different threads of the main variant to form a system call sequence of each thread of the main variant, which can be specifically combined with the system call sequence of the thread m1 and the system call sequence of the thread m2 of the main variant-variant 1 recorded in the buffer, as shown in fig. 3.
Specifically, a semaphore mutual exclusion method is adopted to identify a thread in a buffer area, the buffer area records the system calling sequence of a main variant after the main variant thread is executed every time, and the variant execution system calling is executed in series in the execution process every time, so that the aim of multithreading redundant execution is fulfilled.
And 104, recording and replaying the system call to a slave variant end so that each thread of the slave variant executes a system call sequence consistent with a corresponding thread of the main variant.
On the basis of generating a system call sequence of each thread of a main variant through monitoring and recording processing of main variant system calls, after the main variant is executed, a buffer synchronization module synchronizes the recorded system call sequence to a slave variant, namely, copies the system call sequence of each thread of the main variant to a corresponding thread of the slave variant, and realizes recording and replaying the system call of the main variant to a slave variant end, so that each thread of the slave variant (such as threads s1 and s2 of slave variant-variant 2 in fig. 3) executes each system call of a thread corresponding to the main variant (a slave variant thread s1 corresponds to a main variant thread m1, and a slave variant thread s2 corresponds to a main variant thread m2) according to the same sequence, thereby keeping the execution sequences of the master variant and the slave variant consistent.
It should be noted that, in the implementation of the present application, the execution sequences of the master and slave variants are consistent, specifically, the execution sequences of the master and slave variants are consistent for the screened system calls for executing the system call synchronization task.
Wherein, in the executing process of the master variant or the slave variant, the master variant or the slave variant adopts mutual exclusion locks to use shared resources through system calls before and after the master variant or the slave variant; and for the system call needing synchronization, one variant can only have one thread to execute the system call at the same time.
And 105, if not, stopping intercepting the thread level system call of the currently intercepted main transformer so as to enable the program of the main transformer to continue running.
After the monitoring agent intercepts the system call of the main variant, the interruption interception is stopped through the judgment of the judgment module if the slave variant synchronous processing is not needed, and the application program of the main variant is allowed to continue to run.
Subsequently, the monitor monitors the output behaviors of the master variant and each variant of the slave variant and detects the divergence between the master variant and the slave variant, and finally votes whether the output results of different variants are consistent. Optionally, voting execution of generating variants by multiple virtualization technologies such as VMware, KVM, Docker and the like is supported.
According to the above scheme, the method of the embodiment of the present application, by monitoring the thread-level system call of the main variant, and the monitored main system call which needs to be synchronized from the variant is recorded and processed in a targeted manner, and record and replay the system call of the master variant to the slave variant end, so that each thread of the slave variant executes the system call sequence consistent with the master variant, thereby avoiding the problem of multi-thread out-of-order execution of different variants in the mimicry software process, correspondingly avoiding false positive errors generated during voting, in addition, because only partial system calls (namely system calls required to be synchronized from variants) are purposefully recorded and replayed, such as file reading and writing, file replacement and other calls, therefore, only a part of system calls are voted finally, and the monitor does not need to intervene in each system call executed by the variant, so that the safety of the mimicry software kernel is further improved.
Corresponding to the above method, an embodiment of the present application further discloses an apparatus for controlling redundant execution of a multi-thread program, as shown in fig. 4, the apparatus includes:
a monitoring unit 401, configured to monitor a thread-level system call of the main variant;
a determining unit 402, configured to determine whether the monitored thread-level system call is a system call that needs to be synchronized from a variant; wherein the master variant and the slave variant each comprise a same number of multiple threads;
a recording unit 403, configured to perform recording processing on the thread-level system call to update a system call record of the main variant if the determining unit is yes; the system call record includes: each thread of the main variant corresponds to a system calling sequence which is generated according to a time line and needs to be synchronized to each system call of the slave variant;
and a replay unit 404, configured to replay the system call record to the slave variant end, so that each thread of the slave variant executes a system call sequence consistent with a corresponding thread of the master variant.
In an embodiment, the monitoring unit 401 is specifically configured to:
and monitoring the thread-level system call of the main variant by intercepting the thread-level system call instruction of the main variant.
In an embodiment, the monitoring unit 401 is further configured to: and if the monitored thread-level system call is determined to be a system call which does not need to be synchronized in the slave variant, stopping intercepting the thread-level system call so as to enable the program of the master variant to continue running.
In an embodiment, the determining unit 402 is specifically configured to:
determining whether the thread-level system call is a system call which influences the multithreading redundant execution result and causes the execution result to change;
if yes, determining the thread-level system call as a system call needing synchronization from the variant;
if not, determining the thread-level system call to be a system call that does not need to be synchronized from the variant.
In one embodiment, during the execution process of the master variant or the slave variant, the master variant or the slave variant uses a mutual exclusion lock to use a shared resource; and for the system call needing synchronization, one variant can only have one thread to execute the system call at the same time.
In an embodiment, the apparatus employs a decision module to intercept the thread-level system call of the master variant, and determines whether the intercepted thread-level system call is a system call to be synchronized in the slave variant.
In one embodiment, the decision module supports instruction interception and decision of the Linux multi-variant execution environment of the x86 framework, and can be deployed in a cross-platform execution variant.
In one embodiment, the apparatus employs a buffer synchronization module to perform record processing on the thread-level system call;
the buffer area synchronization module opens up a buffer area, records thread level system call of the main variant and the thread level system call of the main variant to the opened buffer area, maintains execution sequence of different system calls of different threads of the main variant, and synchronizes the recorded system call sequence to the slave variant, so that each thread of the slave variant executes each system call of the thread corresponding to the main variant according to the same sequence.
In one embodiment, the master variant and the slave variant are independent of each other and functionally equivalent, structurally different.
The device for controlling the redundant execution of the multithreading program disclosed in the embodiment of the present application corresponds to the method for controlling the redundant execution of the multithreading program in the offline mode disclosed in the method embodiment above, so the description is relatively simple, and for the relevant similarities, please refer to the description of the method embodiment above, and details are not described here.
It should be noted that, in the present specification, the embodiments are all described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments may be referred to each other.
For convenience of description, the above system or apparatus is described as being divided into various modules or units by function, respectively. Of course, the functionality of the units may be implemented in one or more software and/or hardware when implementing the present application.
From the above description of the embodiments, it is clear to those skilled in the art that the present application can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present application may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments of the present application.
Finally, it is further noted that, herein, relational terms such as first, second, third, fourth, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
The foregoing is only a preferred embodiment of the present application and it should be noted that those skilled in the art can make several improvements and modifications without departing from the principle of the present application, and these improvements and modifications should also be considered as the protection scope of the present application.

Claims (10)

1. A method of controlling redundant execution of a multi-threaded program, comprising:
monitoring thread-level system calls of the master variant;
determining whether the monitored thread-level system call is a system call which needs to be synchronized from a variant; wherein the master variant and the slave variant each comprise a same number of multiple threads;
if so, recording the thread-level system call to update the system call record of the main variant; the system call record includes: each thread of the main variant corresponds to a system calling sequence which is generated according to a time line and needs to be synchronized to each system call of the slave variant;
and recording and replaying the system call to the slave variant end so that each thread of the slave variant executes a system call sequence consistent with the corresponding thread of the master variant.
2. The method of claim 1, wherein monitoring the main variant for thread-level system calls comprises:
and monitoring the thread-level system call of the main variant by intercepting the thread-level system call instruction of the main variant.
3. The method of claim 2, further comprising, after determining whether the monitored thread-level system call is a system call to be synchronized from a variant:
if not, stopping intercepting the thread-level system call so as to enable the program of the main variant to continue running.
4. The method of claim 1, wherein determining whether the monitored thread-level system call is a system call that needs to be synchronized from a variant comprises:
determining whether the thread-level system call is a system call which influences the multithreading redundant execution result and causes the execution result to change;
if yes, determining the thread-level system call as a system call needing synchronization from the variant;
if not, determining the thread-level system call to be a system call that does not need to be synchronized from the variant.
5. The method according to claim 1, characterized in that during the execution of the master variant or the slave variant, the master variant or the slave variant uses the shared resource with mutual exclusion lock by the system call before and after the master variant or the slave variant; and for the system call needing synchronization, one variant can only have one thread to execute the system call at the same time.
6. The method of claim 2, wherein a decision module is employed to intercept the thread-level system call of the master variant and determine whether the intercepted thread-level system call is a system call to be synchronized in the slave variant.
7. The method according to claim 6, wherein the decision module supports instruction interception and decision of x86 framework Linux multi-variant execution environment, and can be deployed in cross-platform execution variants.
8. The method of claim 1, wherein a buffer synchronization module is employed to log the thread-level system call;
the buffer area synchronization module opens up a buffer area, records thread level system call of the main variant and the thread level system call of the main variant to the opened buffer area, maintains execution sequence of different system calls of different threads of the main variant, and synchronizes the recorded system call sequence to the slave variant, so that each thread of the slave variant executes each system call of the thread corresponding to the main variant according to the same sequence.
9. The method of claim 1, wherein the master variant and the slave variant are independent of each other and functionally equivalent, structurally distinct.
10. An apparatus for controlling redundant execution of a multi-threaded program, comprising:
a monitoring unit for monitoring thread-level system calls of the master variant;
the determining unit is used for determining whether the monitored thread-level system call is a system call which needs to be synchronized from a variant; wherein the master variant and the slave variant each comprise a same number of multiple threads;
a recording unit, configured to perform recording processing on the thread-level system call to update a system call record of the main variant if the determining unit is yes; the system call record includes: each thread of the main variant corresponds to a system calling sequence which is generated according to a time line and needs to be synchronized to each system call of the slave variant;
and the replay unit is used for replaying the system call record to the slave variant end so that each thread of the slave variant executes a system call sequence consistent with the corresponding thread of the main variant.
CN202111564357.9A 2021-12-20 2021-12-20 Method and device for controlling multi-thread program redundant execution Pending CN114238023A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111564357.9A CN114238023A (en) 2021-12-20 2021-12-20 Method and device for controlling multi-thread program redundant execution

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111564357.9A CN114238023A (en) 2021-12-20 2021-12-20 Method and device for controlling multi-thread program redundant execution

Publications (1)

Publication Number Publication Date
CN114238023A true CN114238023A (en) 2022-03-25

Family

ID=80759498

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111564357.9A Pending CN114238023A (en) 2021-12-20 2021-12-20 Method and device for controlling multi-thread program redundant execution

Country Status (1)

Country Link
CN (1) CN114238023A (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200193013A1 (en) * 2018-12-12 2020-06-18 Raytheon Company Resilient multi-variant execution verification
CN111666562A (en) * 2020-06-04 2020-09-15 郑州昂视信息科技有限公司 Active defense method and system for software security

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200193013A1 (en) * 2018-12-12 2020-06-18 Raytheon Company Resilient multi-variant execution verification
CN111666562A (en) * 2020-06-04 2020-09-15 郑州昂视信息科技有限公司 Active defense method and system for software security

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
员天佑;刘金;周小伟;安宝冉;: "基于多变体的控制软件异构冗余与动态重构技术研究", 计算机测量与控制, no. 01, 25 January 2017 (2017-01-25) *
比约恩等: "Secure and Efficient Application Monitoring and Replication", USENIX年度技术会议, 31 December 2016 (2016-12-31), pages 1 - 14 *
科恩等: "Taming Parallelism in a multi-variant Execution Environment", ACM, 31 December 2017 (2017-12-31), pages 1 - 16 *

Similar Documents

Publication Publication Date Title
US8949671B2 (en) Fault detection, diagnosis, and prevention for complex computing systems
US8117600B1 (en) System and method for detecting in-line synchronization primitives in binary applications
JP4882845B2 (en) Virtual computer system
US9632860B2 (en) Multicore processor fault detection for safety critical software applications
Prathiba et al. Survey of failures and fault tolerance in cloud
US8656217B2 (en) Method for error detection during execution of a real-time operating system
Ronsse et al. Record/replay for nondeterministic program executions
JP5137966B2 (en) Method, computer program and system for controlling access to memory by threads generated by processes executing on a multiprocessor computer
Costa et al. A system software approach to proactive memory-error avoidance
CN105511941A (en) System and method for facilitating joint operation of multiple hypervisors in computer system
CN103793288A (en) Software watchdog system and method
US8635501B2 (en) Detecting memory hazards in parallel computing
CN114238023A (en) Method and device for controlling multi-thread program redundant execution
KR102141620B1 (en) Method and Apparatus for detecting atomicity violation for shared memory used in multi-process/multi-thread
CN106033368B (en) A kind of method of multi-core virtual machine Deterministic Replay
Tarrillo et al. A hardware-scheduler for fault detection in RTOS-based embedded systems
Chen et al. Fault-Tolerance Implementation in Typical Distributed Stream Processing Systems.
Chen et al. Asymmetric virtual machine replication for low latency and high available service
Qin System Support for Improving Software Dependability During Production Runs
Chakraborty et al. A Good Anvil Fears No Hammer: Automated Rowhammer Detection Using Unsupervised Deep Learning
Zhang et al. Multi-variant execution: State-of-the-art and research challenges
Xu et al. Xentry: Hypervisor-level soft error detection
Utomo et al. Towards a Resilient Server with an external VMI in the Virtualization Environment
Martens et al. CrossCheck: A holistic approach for tolerating crash-faults and arbitrary failures
Hung et al. CSM-DBEN: Container Storage Manager for Data Backup on Edge Nodes

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination