Distributed system fuzz testing method based on event awareness
By introducing event-aware fuzz testing methods, using event chain model and event coverage, the problem of poor fuzz testing of distributed systems in the existing technology is solved, more efficient vulnerability exploration and testing coverage is achieved, and the security and reliability of distributed systems are improved.
Patent Information
- Application Number
- CN202510367340.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-26
- Publication Date
- 2025-07-08
AI Technical Summary
The existing distributed system fuzz testing technology has insufficient internal details and code coverage during the control system operation process, resulting in poor fuzz testing.
The event-aware fuzz testing method is adopted to improve fuzz testing through event chain model and event coverage, and event coverage is introduced as a test indicator. The original input of the fuzz tester is processed using a parser, and a scheduling sequence with partial order relationships is generated through selectors, chain buffers and scheduling buffers.
The vulnerability mining capabilities of fuzzy testing on distributed systems have been improved, the test coverage has been enhanced, and the security and reliability of distributed systems have been improved.
Smart Images
Figure CN120276989A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a fuzz testing method for distributed systems based on event perception, belonging to the technical field of electronic digital data processing. Background Art
[0002] Distributed systems play a key role in modern society. It can coordinate multiple independent computer nodes to work together and work in the form of a unified system. This characteristic endows distributed systems with powerful dynamic expansion capabilities, fault tolerance capabilities, and high availability, making them widely used in key fields such as cloud computing platforms, cloud databases, distributed storage, and large-scale online services. However, potential vulnerabilities in distributed systems may lead to serious problems, such as data loss and service interruption. These problems not only affect the stability of cloud services but may also cause huge economic losses to users and enterprises. With the continuous expansion of the application of distributed systems in the social and economic fields, the importance of verifying them has become increasingly prominent. Research and development of advanced verification tools and methods can not only improve the reliability of the system but also provide scientific support for building a more robust distributed architecture.
[0003] Fuzz testing of distributed systems is one of the important technologies to improve the reliability of distributed systems. Common distributed system fuzz testing technologies explore by randomly injecting external faults and monitoring the code coverage of the distributed system. On the one hand, the control ability over the system under test is limited and cannot control the internal detailed actions during the system operation process. On the other hand, the code coverage cannot obtain the degree of exploration of the distributed system, resulting in poor fuzz testing effects. Summary of the Invention
[0004] Object of the Invention: Aiming at the problems and deficiencies in the prior art, the present invention provides a fuzz testing method for distributed systems based on event perception, regarding the event execution sequence of the entire distributed system as the input, rather than simply randomly injecting faults. This fine control enables the fuzz testing technology to more comprehensively explore the state space of the system, thereby reaching complex states that other frameworks may ignore. The present invention introduces event coverage instead of code coverage as the test index for fuzz testing. This is a general attribute of a distributed system as a state machine system and can more accurately reflect the degree of system verification from the perspective of events compared to code coverage. Through event perception, the present invention can better enhance the heuristic vulnerability mining ability of fuzz testing for distributed systems.
[0005] Technical Solution: A fuzz testing method for distributed systems based on event perception improves the heuristic input mutation ability of fuzz testing for distributed systems through event perception and improves the exploration performance of fuzz testing technology in the scenario where the system under test is a distributed system; mainly including:
[0006] 1) Fuzzing input parsing process based on the event chain model;
[0007] 2) Fuzzing feedback process based on event coverage.
[0008] Fuzzing input parsing process based on the event chain model: The processing methods included are using the event chain to introduce a partial order relationship and using a parser to process and parse the original input of the fuzzer.
[0009] An event chain is a sequence of temporal events, originating from the execution temporal relationship of events in a distributed system. A string of events containing a temporal relationship can form an event chain, which can better represent the context of system event execution. The present invention uses a "chain pattern" to support developers in customizing the event chain model; the chain pattern is loaded from a configuration file in JSON format, and developers define the partial order relationship of events in each chain pattern; the chain pattern is divided into two parts: one part contains metadata, including constraints such as occurrence probability and occurrence limit, and the other part defines the specific event partial order relationship.
[0010] a) Probability (prob): The occurrence probability of the event chain, indicating the possibility of the event chain corresponding to this chain pattern appearing in the scheduling, increasing from 0 to 1.
[0011] b) Limit: The occurrence limit of the event chain, indicating the maximum number of times the event chain corresponding to this chain pattern can appear in a scheduling, which can limit the occurrence of some accidental external events.
[0012] c) Happen-before: The partial order relationship of the event chain, which contains the definition of the specific event partial order relationship in this chain pattern. In this definition, developers need to list the events in this partial order relationship in sequence and specify the category (type) of each event according to the nature of the event.
[0013] Developers can easily analyze and extract the partial order relationship based on the event attributes of different distributed systems and convert it into a chain pattern to provide to the method of the present invention. During the scheduling generation process, the parser can read these chain patterns and apply them to scheduling generation, enabling the present invention to be easily generalized to multiple distributed systems.
[0014] The input directly generated by the fuzzer is called the original input, and then each original input containing random information is escaped into different event scheduling sequences through the parser. To limit the state space, the parser reads the chain pattern provided by the user and uses the event chain model to maintain the partial order relationship between events.
[0015] The parser designed by the present invention has three interaction modules: a selector, a chain buffer, and a scheduling buffer. Through the escape of the parser, the present invention can obtain a scheduling sequence with a partial order relationship constraint.
[0016] The selector processes the original input as a binary data stream, reads several bits each time and converts them into an operand. Through this operand, the selector determines its selection in the current enumeration space and takes actions. Since the mutation algorithm of the fuzzer is implemented based on various bit operations, flipping a single bit of the input can make the operand find a completely different selection in the enumeration space and generate a scheduling with completely different events. This method can maximize the effectiveness of mutation.
[0017] The enumeration space contains three categories. One is operation enumeration, including two operations: addition and extraction. One is addition strategy, including the attributes of generating events in each addition operation. The last one is extraction strategy, including the specific behavior attributes in each extraction operation.
[0018] The selector contains two operation actions:
[0019] a) Add: The add operation selects a chain pattern based on the operand and generates a new empty chain. Subsequently, it continues to fill in the specific details of the chain, such as the initiating node and receiving node of the event. During the generation of each event chain, the selector will automatically fill in the known event attributes in the chain according to the event type (local, global, external). Specifically, for the global events in the chain (corresponding to the interaction between nodes, such as message sending and receiving), the initiating node and receiving node need to be exchanged, while other types of events do not.
[0020] b) Poll: The poll operation selects an event chain from the chain buffer based on the operand and extracts some events from it and adds them to the scheduling buffer. Since the events in the chain usually execute continuously during the system execution, the poll operation does not just extract one event from the head of the chain, but extracts multiple events. The number of these events is also determined by the operand.
[0021] The chain buffer is a storage area with a dynamically variable capacity. Any chain in the buffer can be obtained and processed through the subscript. The design goal is to decouple the event chain from the specific execution of the scheduling process so that the selector can make a fair decision on the selection of the event chain and the consumption of each event.
[0022] When the selector decides to add a new event chain, the parser adds and stores the chain in the chain buffer for maintenance instead of directly appending it to the schedule. When some events in the event chain are consumed by the selector through extraction actions, the remaining events will continue to be maintained in the chain buffer, waiting for the next extraction action, thus simulating the switching between chains. The selection of event chains and the number of events to be executed are fairly determined by the selector.
[0023] The schedule buffer plays a crucial role in the parser. It serves as a temporary storage area for receiving and integrating the events extracted from the chain buffer each time. During the parsing process, the selector is responsible for consuming the original input and determining each random escape event, while the chain buffer is responsible for maintaining the chain state in the parser. After these events are extracted, the schedule buffer collects and organizes them into a temporary event schedule sequence, which ultimately forms an executable event schedule.
[0024] The event chains newly added to the chain buffer will not enter the schedule buffer until they are consumed by the selector. After an extraction operation on the chain buffer, the selected part of the events is extracted into the schedule buffer. After entering the schedule buffer, they will constitute the continuous specific actions of the schedule from the perspective of the final global view.
[0025] The existence of the schedule buffer ensures that during event integration, the partial order relationship constraints between events can be effectively processed, thus generating a schedule sequence that meets specific requirements, providing a basis for subsequent execution and verification.
[0026] Fuzz testing feedback process based on event coverage:
[0027] This process aims to make the feedback information accurately reflect the in-depth exploration degree of the fuzzer on the system, and at the same time be able to control the redundant events that are inevitable in the event schedule generation process through runtime feedback in subsequent fuzz testing input generation. The main processing methods include using the event coverage for distributed systems as feedback information and using the execution results of event schedules as feedback information.
[0028] The execution situations of events in the event schedule are collected in the feedback information, including the coverage rate and the situation of system vulnerability triggering after execution, that is, the execution results. The coverage rate represents the exploration degree of the state space of the distributed system under test, while the execution results reflect the quality of each schedule, that is, whether it triggers a violation of the invariant or a runtime exception of the system. By combining these two kinds of feedback, the fuzzer can more effectively detect the inputs that are likely to cause system vulnerabilities, thus guiding the fuzzer to generate mutants of the schedule.
[0029] To more precisely track the execution of a distributed system, the distributed system is regarded as an ordinary program, events are analogized to basic blocks in a program control flow graph, and the execution sequence of events in scheduling simulates the control flow paths traversed during the execution of an ordinary program.
[0030] At each layer of the event state space of a distributed system, all events are potentially reachable. In event coverage, system events are described by two attributes: the index of the system event in the belonging schedule and its unique event ID. In other words, each event is uniquely identified by its index and ID in the state space. A schedule corresponds to selecting one event at each layer in the state space to form a path. Therefore, event coverage is defined as the proportion of states in the state space that are hit by the schedule.
[0031] Provide an event coverage algorithm for effectively tracking and updating the coverage status of events to ensure that all possible event types are covered under a given schedule. The steps of this algorithm are as follows:
[0032] 1) Input data: This algorithm receives the following data: the number N of event types; the schedule schedule to be executed; the global event coverage graph Cov, which is used to represent the coverage status of events during the fuzz testing process.
[0033] 2) Initialization: Initialize the global event coverage graph Cov to the initial state initState.
[0034] 3) Event scheduling processing: For each new schedule schedule, repeat the following steps: First, initialize the local coverage graph Cov t to the initial state initState; then traverse each event in the schedule schedule to obtain the offset and event information <index, event>, calculate the hit position hit of this event in the state space, where hit is calculated by the state space offset calculation function hit = index · N + id event ; then incorporate the hit position hit of the event into the current local coverage graph Cov t ; merge the local coverage graph Cov t into the global coverage graph Cov to update the global coverage status; finally, update the current state according to the coverage change amount ΔCov;
[0035] 4) Output result: Finally, the algorithm outputs a global event coverage graph Cov updated after multiple schedules, which reflects the coverage of all event types during the scheduling process.
[0036] During initialization, a global event coverage map is constructed, which records the cumulative event coverage in all schedules. Calculate the event coverage achieved by the current schedule, which reflects the traversal path of the schedule in the state space. After updating the global coverage rate map, the fuzzer can identify potential schedules, thereby guiding the mutation of subsequent input schedules to explore uncovered behaviors.
[0037] Due to the partial order constraints brought by the event chain model in event scheduling, some events may not be reachable at certain levels. For example, at depth 0, the message reply event is not reachable because no messages have been sent yet. Nevertheless, the calculation of event coverage does not have a negative impact on the feedback of the fuzzer, because as the exploration progresses, the effective event coverage is still increasing.
[0038] Beneficial effects: Compared with the prior art, the event-aware distributed system fuzz testing method provided by the present invention can effectively improve the vulnerability mining effect of fuzz testing on distributed systems, improve the test coverage of the system under test during the fuzz testing process, and has good test performance, providing better technology for ensuring the security and reliability of distributed systems. Description of the Drawings
[0039] Figure 1 It is a schematic diagram of fuzz testing input parsing according to an embodiment of the present invention;
[0040] Figure 2 It is a schematic diagram of the fuzz testing event feedback path architecture according to an embodiment of the present invention. Detailed Embodiments
[0041] The following further clarifies the present invention in conjunction with specific embodiments. It should be understood that these embodiments are only used to illustrate the present invention and not to limit the scope of the present invention. After reading the present invention, various equivalent modifications of the present invention by those skilled in the art fall within the scope defined by the appended claims of this application.
[0042] The event-aware distributed system fuzz testing method mainly includes:
[0043] 1) The fuzz testing input parsing process based on the event chain model;
[0044] 2) The fuzz testing feedback process based on event coverage.
[0045] The fuzz testing input parsing process based on the event chain model:
[0046] This process aims to enable the input provided by the fuzzer to guide the testing of distributed systems with higher quality. The main processing methods include introducing a partial order relationship using the event chain and processing and parsing the original input of the fuzzer using a parser.
[0047] An event chain is a sequence of timed events, which is derived from the execution timing relationship of events in a distributed system. A series of events with a timing relationship can form an event chain, which can better represent the context of system event execution. The present invention uses a "chain mode" to support developers in customizing an event chain model. The chain mode is loaded from a configuration file in JSON format, and developers can define the partial order relationship of events in each chain mode. The chain mode is divided into two parts: one part contains metadata, including constraints such as occurrence probability and number limit, and the other part defines the specific partial order relationship of events.
[0048] a) Probability (prob): The occurrence probability of the event chain, which represents the possibility of the event chain corresponding to this chain mode appearing in the scheduling, increasing from 0 to 1.
[0049] b) Limit: The occurrence limit of the event chain, which represents the maximum number of times the event chain corresponding to this chain mode can appear in a scheduling, and can limit the occurrence of some accidental external events.
[0050] c) Happen-before: The partial order relationship of the event chain, which contains the definition of the specific partial order relationship of events in this chain mode. In this definition, developers need to list the events in this partial order relationship in sequence and specify the category (type) of each event according to the nature of the event.
[0051] Developers can easily analyze and extract the partial order relationship based on the event attributes of different distributed systems and convert it into a chain mode to provide to the present invention. During the scheduling generation process, the parser module can read these modes and apply them to scheduling generation, enabling the present invention to be easily generalized to multiple distributed systems.
[0052] The input directly generated by the fuzzer is called the original input, and then each original input containing random information is escaped into different event scheduling sequences through the parser component. To limit the state space, the parser reads the chain mode provided by the user and uses the event chain model to maintain the partial order relationship between events.
[0053] As Figure 1 shown, the parser designed by the present invention has three interactive modules: a selector, a chain buffer, and a scheduling buffer. Through the escape of the parser, a scheduling sequence with partial order relationship constraints can be obtained.
[0054] The selector processes the original input as a binary data stream, reads a certain number of bits each time and converts them into an operand. Based on this operand, the selector determines its selection in the current enumeration space and takes actions. Since the mutation algorithm of the fuzzer is implemented based on various bit operations, flipping a single bit of the input can make the operand find a completely different selection in the enumeration space, generating a schedule with completely different events. This method can maximize the effectiveness of mutation.
[0055] The enumeration space contains three categories. One is the operation enumeration, which includes two operations: addition and extraction. Another is the addition strategy, which includes the attributes of generating events in each addition operation. The last category is the extraction strategy, which includes the specific behavioral attributes in each extraction operation.
[0056] The selector contains two operation actions:
[0057] a) Add: The add operation selects a chain pattern based on the operand and generates a new empty chain. Subsequently, it continues to fill in the specific details of this chain, such as the initiating node and receiving node of the event. During the generation of each event chain, the selector automatically fills in the known event attributes in the chain according to the event type (local, global, external). Specifically, for global events in the chain (corresponding to interactions between nodes, such as message sending and receiving), the initiating node and receiving node need to be swapped, while other types of events do not require this.
[0058] b) Poll: The poll operation selects an event chain from the chain buffer based on the operand and extracts some events from it and adds them to the schedule buffer. Since events in the chain usually execute continuously during system execution, the poll operation does not just extract one event from the head of the chain, but extracts multiple events. The number of these events is also determined by the operand.
[0059] The chain buffer is a storage area with a dynamically variable capacity. Any chain in the buffer can be obtained and processed through an index. The design goal of this is to decouple the event chain from the specific execution of the scheduling process so that the selector can make fair decisions on the selection of event chains and the consumption of events each time.
[0060] When the selector decides to add a new event chain, the parser adds and stores this chain in the chain buffer instead of directly appending it to the schedule. When some events in the event chain are consumed by the selector through the poll action, the remaining events will continue to be maintained in the chain buffer, waiting for the next poll action, thus simulating the switching between chains. The selection of event chains and the number of events executed are completely fairly determined by the selector.
[0061] The scheduling buffer plays a crucial role in the parser. As a temporary storage area, it receives the events extracted from the chain buffer each time and integrates them. During the parsing process, the selector is responsible for consuming the original input and determining each random escape event, while the chain buffer is responsible for maintaining the chain state in the parser. After these events are extracted, the scheduling buffer collects and organizes them into a temporary event scheduling sequence, which ultimately forms an executable event schedule.
[0062] The event chains newly added to the chain buffer will not enter the scheduling buffer until they are consumed by the selector. After an extraction operation on the chain buffer, the selected partial events are extracted into the scheduling buffer. After entering the scheduling buffer, they will constitute the continuous specific actions of the schedule from the perspective of the final global view.
[0063] The existence of the scheduling buffer ensures that during event integration, the partial order relationship constraints between events can be effectively processed, so as to generate a scheduling sequence that meets specific requirements, providing a basis for subsequent execution and verification.
[0064] Fuzz testing feedback process based on event coverage:
[0065] This process aims to make the feedback information accurately reflect the in-depth exploration degree of the fuzzer on the system, and at the same time be able to control the redundant events that are inevitable in the event scheduling generation process through runtime feedback in the subsequent fuzz testing input generation. The main processing methods include using the event coverage for distributed systems as feedback information and using the execution results of event scheduling as feedback information.
[0066] Such as Figure 2 As shown, the execution situations of the events in the event scheduling are collected in the feedback information, including the coverage rate and the situation of system vulnerability triggering after execution, that is, the execution result. The coverage rate represents the exploration degree of the state space of the distributed system under test, while the execution result reflects the quality of each schedule, that is, whether it triggers a violation of the invariant or a runtime exception of the system. By combining these two kinds of feedback, the fuzzer can more effectively detect the inputs that are likely to cause system vulnerabilities, thereby guiding the fuzzer to generate mutants of the schedule.
[0067] To more carefully trace the execution of the distributed system, the distributed system is regarded as an ordinary program, the events are analogized to the basic blocks in the program control flow graph, and the execution sequence of the events in the schedule simulates the control flow path traversed during the execution of an ordinary program.
[0068] At each layer of the event state space in a distributed system, all events are potentially reachable. In event coverage, system events are described by two attributes: their index in the schedule to which they belong and their unique event ID. In other words, each event is uniquely identified in the state space by its index and ID. A schedule corresponds to selecting one event per layer in the state space, forming a path. Thus, event coverage is defined as the proportion of states in the state space that are hit by the schedule.
[0069] An event coverage algorithm is provided for effectively tracking and updating the coverage status of events, ensuring that all possible event types are covered under a given schedule. The steps of the algorithm are as follows:
[0070] 1) Input data: The algorithm receives the following data: the number N of event types; the schedule schedule to be executed; the global event coverage graph Cov, which is used to represent the coverage status of events during the fuzz testing process.
[0071] 2) Initialization: Initialize the global event coverage graph Cov to the initial state initState.
[0072] Event schedule processing: For each new schedule schedule, repeat the following steps: First, initialize the local coverage graph Cov t to the initial state initState; then traverse each event in the schedule schedule to obtain the offset and event information <index, event>, and calculate the hit position hit of this event in the state space, where hit is calculated by the state space offset calculation function hit = index · N + id event ; then incorporate the hit position hit of the event into the current local coverage graph Cov t ; merge the local coverage graph Cov t into the global coverage graph Cov to update the global coverage status; finally, update the current state according to the coverage change amount ΔCov;
[0073] 3) Output result: Finally, the algorithm outputs a global event coverage graph Cov updated after multiple schedules, which reflects the coverage of all event types during the scheduling process.
[0074] During initialization, a global event coverage mapping is constructed, which records the cumulative coverage of events in all schedules. Calculate the event coverage reached by the current schedule, which reflects the traversal path of the schedule in the state space. After updating the global coverage rate mapping, the fuzzer can identify potential schedules, thereby guiding the mutation of subsequent input schedules to explore uncovered behaviors.
[0075] The usage process of this method is as follows:
[0076] 1) Deploy the fuzz testing technology for event-aware distributed systems. It is required to have a deterministic simulation execution framework for the distributed system under test, which can block and control the operation of the system under test in terms of event units, and then perform fuzz testing on it. Select a fuzzer to access the system, read the feedback information and mutate the input. Extract the event chain of the distributed system under test, write it and related constraint information into the chain pattern file, and store it in the specified directory.
[0077] 2) Run the fuzz testing. In this process, each time a binary random input is generated by mutating the fuzzer, the random manipulation of the distributed system is realized through this method, and dynamic running information including execution events, system metadata, etc. is obtained as feedback during the process to guide subsequent input mutation. Once a vulnerability trigger is found, such as a violation of invariant properties or a runtime fault of the system, the event scheduling report corresponding to the input causing the vulnerability will be reported and stored.
[0078] 3) Aggregate the fuzz testing results with event feedback information and the fuzz testing results without event feedback information, and classify them according to different chain pattern parameter definitions. Compare and statistically analyze data such as the growth of vulnerabilities found in the fuzz testing results in different categories and the types of invariant violations, and analyze the efficiency of the present invention in improving the fuzz testing of distributed systems and the effectiveness of discovering vulnerabilities in distributed systems.
[0079] Next, the technical solution of the present invention will be described in detail through a specific example as follows. We selected Jazzer as the fuzzer and implemented an example of the fuzz testing technology for event-aware distributed systems to test the reliability of the Ratis v1.0.0 system. Jazzer is based on the input mutation technology of libFuzzer and can directly inject input into Java programs and observe their execution behaviors. Through a feedback-driven approach, Jazzer can generate a large number of non-repeating random original inputs for our framework and capture abnormal situations such as crashes, memory leaks, and logical defects.
[0080] 1) Hardware environment:
[0081] Start the fuzz testing technology for event-aware distributed systems of the Ratis system on a local workstation, collect the fuzz testing results, and start an analysis script on the local workstation to perform regular statistics on the result data.
[0082] 2) Running process:
[0083] For the fuzz testing before applying this method, we launched the event-aware distributed system fuzz testing technology on a local workstation, closed the feedback channel, and made it run as a black-box fuzz test, stopping every 1000 minutes. Among them, the maximum length of a single event schedule was restricted to 800, and the maximum number of event executions in a single schedule was 200. We ran a local script to count data such as the invariant violation types and frequencies of vulnerability inputs every unit time (10 minutes). This process was repeated 20 times to eliminate errors.
[0084] For the fuzz testing after applying this method, we launched the event-aware distributed system fuzz testing technology on a local workstation, stopping every 1000 minutes. Among them, the maximum length of a single event schedule was restricted to 800, and the maximum number of event executions in a single schedule was 200. We ran a local script to count data such as the invariant violation types and frequencies of vulnerability inputs every unit time (10 minutes). This process was repeated 20 times to eliminate errors.
[0085] Comparing the results of the two experiments, the experimental results are shown in Table 2. The experimental parameters and default values are shown in Table 1.
[0086] 3) Running results:
[0087] Table 1 Experimental parameters and default values
[0088] Experimental parameters Default value Ratis version v1.0.0 Total number of server cluster nodes 3 Maximum number of downtime event chains 5 Maximum number of other event chains Unlimited Downtime event chain probability 0.15 Other event chain probability 1
[0089] Table 2 Experimental results
[0090] Experimental parameters Experimental results without feedback Experimental results with feedback Number of scheduling executions 2192 2017 Number of schedulings that trigger vulnerabilities 60 205 Number of non-repeated schedulings that trigger vulnerabilities 36 148
Claims
1. A fuzz testing method for an event-aware distributed system, characterized in that Improving the heuristic input mutation ability of fuzz testing for distributed system testing through event perception, and improving the exploration performance of fuzz testing technology in the scenario where the system under test is a distributed system, including: the fuzz testing input parsing process based on the event chain model and the fuzz testing feedback process based on event coverage; The processing method included in the fuzz testing input parsing process based on the event chain model is to introduce a partial order relationship using the event chain and process and parse the original input of the fuzz tester using a parser; The fuzz testing feedback process based on event coverage includes processing methods such as using the event coverage for the distributed system as feedback information and using the execution result of event scheduling as feedback information.
2. The event-aware distributed system fuzz testing method according to claim 1, wherein In the fuzz testing input parsing process based on the event chain model, an event chain model containing the partial order relationship of events is introduced; an event chain is a sequence of temporal events, originating from the execution temporal relationship of events in a distributed system; a string of events containing temporal relationships constitutes an event chain; the "chain pattern" is used to support developers to customize the event chain model; the chain pattern is loaded from a JSON-format configuration file, and the partial order relationship of events is defined in each chain pattern; the chain pattern is divided into two parts: one part contains metadata, including constraints such as occurrence probability and number limit, and the other part defines the specific partial order relationship of events.
3. The event perception-based distributed system fuzz testing method according to claim 1, characterized in that In the fuzz testing input parsing process based on the event chain model, the input directly generated by the fuzz tester is called the original input, and then each original input containing random information is escaped into different event scheduling sequences by the parser; the parser reads the chain pattern provided by the user and uses the event chain model to maintain the partial order relationship between events; The parser has three interactive modules: a selector, a chain buffer, and a scheduling buffer; through the escaping of the parser, a scheduling sequence with partial order relationship constraints can be obtained.
4. The method for fuzz testing of an event-aware distributed system according to claim 1, characterized in that In the fuzz testing input parsing process based on the event chain model, the parser processes the original input as a binary data stream through the selector, reads several bits each time and converts them into an operand; through this operand, the selector determines the selection of the operand in the current enumeration space and performs actions; the mutation algorithm of the fuzz tester is implemented based on various bit operations, and flipping a bit of the input can make the operand find different selections in the enumeration space and generate a scheduling with completely different events; the enumeration space includes three categories, one is operation enumeration, including two operations: addition and extraction; one is addition strategy, including the attributes of generating an event chain in each addition operation; one is extraction strategy, including the specific attributes in each extraction operation; a) Addition: The addition operation selects a chain pattern based on the operand and generates a new empty chain; and fills in the empty chain, including the initiating node and receiving node of the event; During the generation process of each event chain, the selector will automatically fill in the known event attributes in the chain according to the event type; for the global events in the chain, the initiating node and receiving node need to be exchanged, while other types of events do not need to be; b) Extraction: The extraction operation selects an event chain from the chain buffer based on the operand and extracts partial events from it, adding them to the scheduling buffer. Since events within a chain are usually executed consecutively during system execution, the extraction operation does not simply extract one event from the head of the chain, but multiple events. The number of events is determined by the operand.
5. The event perception-based distributed system fuzz testing method according to claim 1, characterized in that During the fuzzing input parsing process based on the event chain model, the parser dynamically maintains the generated event chains through the chain buffer. The chain buffer is a storage area with a dynamically variable capacity, and any chain in the buffer can be obtained and processed through an index. The goal is to decouple the event chain from the specific execution of the scheduling process so that the selector can make a fair decision on the selection of the event chain and the consumption amount of each event. When the selector decides to add a new event chain, the parser adds and stores this chain in the chain buffer instead of directly attaching it to the scheduling. When some events in the event chain are consumed by the selector through the extraction action, the remaining events will continue to be maintained in the chain buffer, waiting for the next extraction action, thus simulating the switching between chains. The selection of the event chain and the number of events executed are completely fairly determined by the selector.
6. The method for fuzz testing of an event-aware distributed system according to claim 1, wherein During the fuzzing input parsing process based on the event chain model, the parser integrates the final event scheduling through the scheduling buffer. The scheduling buffer, as a temporary storage area, receives the events extracted from the chain buffer each time and combines them into a schedule. During the parsing process, for the event chains newly added to the chain buffer, these event chains will not enter the scheduling buffer until they are consumed by the selector. After an extraction operation on the chain buffer, the selected partial events are extracted into the scheduling buffer. After entering the scheduling buffer, they will form consecutive specific actions of the schedule from the final global perspective.
7. The method for fuzz testing an event-aware distributed system according to claim 1, wherein During the fuzzing feedback process based on event coverage, the feedback information collects the execution status of events in the event scheduling, including the coverage rate and the situation of system vulnerability triggering after execution, that is, the execution result. The coverage rate represents the degree of exploration of the state space of the distributed system under test, while the execution result reflects the quality of each schedule, that is, whether it triggers a violation of the invariant or a runtime exception of the system. By combining these two types of feedback, the fuzzer can more effectively detect the inputs that are likely to cause system vulnerabilities, thereby guiding the fuzzer to generate mutations of the schedule.
8. The method for fuzz testing of an event-aware distributed system according to claim 1, characterized in that, During the fuzzing feedback process based on event coverage, the distributed system is regarded as a program, the events are analogized to the basic blocks in the program control flow graph, and the execution sequence of events in the schedule simulates the control flow path traversed during program execution.
9. The method for fuzz testing an event-aware distributed system according to claim 1, wherein During the fuzzing feedback process based on event coverage, the system events in the event coverage are described by two attributes: its index in the schedule to which it belongs and its unique event ID. One schedule corresponds to selecting one event for each layer in the state space to form a path. The event coverage is defined as the proportion of states in the state space that are hit by the schedule.
10. The method for fuzz testing of an event-aware based distributed system according to claim 1, wherein In the fuzzy testing feedback process based on event coverage, an event coverage algorithm is proposed to effectively track and update the coverage status of events, ensuring that all possible event types are covered under a given schedule. The execution steps of the algorithm are as follows: 1) Input data: The algorithm receives the following data: the number N of event types; the schedule schedule to be executed; the global event coverage graph Cov, which is used to represent the coverage status of events during the fuzzy testing process; 2) Initialization: Initialize the global event coverage graph Cov to the initial state initState; 3) Event scheduling and processing: For each new schedule, repeat the following steps: First, initialize the local coverage graph Cov t to the initial state initState; then traverse each event in the schedule, obtain the offset and event information <index, event>, and calculate the hit position hit of the event in the state space, where hit is calculated by the state space offset calculation function hit = index · N + id event ; then incorporate the hit position hit of the event into the current local coverage graph Cov t ; merge the local coverage graph Cov t into the global coverage graph Cov to update the global coverage status; finally, update the current state according to the coverage change amount ΔCov; 4) Output result: The algorithm outputs a global event coverage graph Cov updated after multiple schedules, which reflects the coverage of all event types during the scheduling process.