Dos attack detection method and defense device for heterogeneous multi-core consistency master node

Abstract

The application provides a DoS attack detection method and defense device of a heterogeneous multi-core consistency master node, relates to the technical field of on-chip interconnection system security, and extracts the behavior characteristics of each type of request node according to the application scenarios of each heterogeneous request node in the heterogeneous multi-core system; the differentiated detection indexes are configured for each type of request node according to the behavior characteristics of each type of request node; the detection index data of each type of request node is collected, and it is judged whether there is an attack node initiating a denial of service attack according to the detection index data; when it is determined that there is an attack node, the corresponding protection measures are executed, the application analyzes the behavior characteristics of the heterogeneous nodes, and the differentiated protection is carried out, the monitoring and protection functions of the DoS attack are added on the premise that the core business functions of the master node are not affected, and the safety and stability of the heterogeneous multi-core system are improved.

Description

Technical Field

[0001] This invention relates to the field of on-chip interconnect system security technology, and in particular to a DoS attack detection method and defense device for heterogeneous multi-core consistent master nodes. Background Technology

[0002] With the rapid development of high-performance computing and artificial intelligence technologies, System-on-Chip (SoC) has widely adopted a heterogeneous multi-core architecture, integrating various types of computing cores such as CPUs, GPUs, and NPUs. In this type of heterogeneous multi-core system, each heterogeneous request node (RN) connects to a unified consistency master node (HN) through a consistency bus (such as the CHI consistency bus interface). The master node undertakes core responsibilities such as cache directory management, cross-node transaction forwarding, and cache consistency maintenance. Therefore, the consistency master node is a critical hardware unit for the operation of the entire heterogeneous multi-core system. Malicious attackers can selectively hijack heterogeneous nodes such as CPUs, GPUs, and NPUs, exploiting the behavioral characteristics of each node to launch denial-of-service (DoS) attacks. Specifically, attack methods include, but are not limited to: excessive generation of request transactions, exhaustion of credit resources, transaction ID (TxnID) hoarding, eavesdropping storms, and transaction suspension blocking. The aforementioned attacks maliciously preempt the core operating hardware resources of the consistency master node, leading to system slowdowns and potentially causing a significant increase in the instantaneous power consumption of some master node hardware, which can easily result in permanent hardware damage. To address these security threats, traditional DoS protection methods use hardware counters to monitor the number of request packets and data traffic per unit time in real time, setting a fixed traffic threshold. When a node's request traffic exceeds the threshold, protective operations such as packet loss, global rate limiting, and temporary port closure are triggered. Other protection schemes rely on QoS scheduling mechanisms, first identifying abnormal nodes through simple status monitoring, adding the attack source node ID to a hardware blacklist, and then directly rejecting all requests from blacklisted nodes.

[0003] However, traditional DoS protection solutions cannot distinguish the differences in business characteristics between heterogeneous nodes such as CPU, GPU, and NPU, cannot protect on-chip system-specific resources such as transaction ID, flow control credit, and cache directory, and have problems such as high false positive rate, inability to resist fine-grained resource exhaustion attacks, and inability to adapt to heterogeneous multi-core consistency systems. Summary of the Invention

[0004] This invention provides a DoS attack detection method and defense device for heterogeneous multi-core consistent master nodes, which solves the problems of existing technologies being unable to distinguish the differences in business characteristics of heterogeneous nodes, unable to protect on-chip system-specific resources, having a high false positive rate, being unable to resist refined resource exhaustion attacks, and being unable to adapt to heterogeneous multi-core consistent systems.

[0005] This invention provides a DoS attack detection method for heterogeneous multi-core consistent master nodes, including: Based on the application scenarios of each heterogeneous request node in a heterogeneous multi-core system, extract the behavioral characteristics of each type of request node. Based on the behavioral characteristics of each type of request node, configure differentiated detection indicators for each type of request node; Collect detection index data of each type of request node, and determine whether there are attack nodes that launch denial-of-service attacks based on the detection index data; When an attack node is detected, corresponding protective measures are implemented.

[0006] According to the DoS attack detection method for heterogeneous multi-core consistent master nodes provided by the present invention, the step of extracting behavioral features of various types of request nodes based on the application scenarios of each heterogeneous request node in the heterogeneous multi-core system includes: In application scenarios where CPU-type nodes serve as the core scheduling unit of the system, the extracted behavioral characteristics include: stable business requests, rapid response, and no long-term resource occupation. In application scenarios where GPU-type nodes are used as computing units, the extracted behavioral features include: short-term high bursts, large-bandwidth batch requests, and large-block contiguous memory access. In application scenarios where NPU-type nodes are used as acceleration units, the extracted behavioral characteristics include: batch continuous address access to memory, long-term transaction persistence, and periodic batch requests.

[0007] According to the DoS attack detection method for heterogeneous multi-core consistent master nodes provided by the present invention, the step of configuring differentiated detection indicators for each type of request node based on the behavioral characteristics of each type of request node includes: Configure common detection metrics for all types of request nodes. The common detection metrics include: the number of request packets within a unit collection period, the number of times the transaction identifier is reused, and the number of times the transaction times out. as well as, Based on the behavioral characteristics of CPU-type nodes, configure CPU-specific detection metrics, including: the average completion time of transactions in the master node; Based on the behavioral characteristics of GPU type nodes, configure GPU-specific detection indicators, including: the length of the continuous address access segment of memory access requests; Based on the behavioral characteristics of NPU type nodes, configure NPU-specific detection indicators, including: long transaction ratio, where long transactions refer to request transactions whose processing cycle exceeds a preset long transaction threshold.

[0008] According to the DoS attack detection method for heterogeneous multi-core consistent master nodes provided by the present invention, the method for collecting the general detection indicators includes: The number of request messages within the unit collection period is collected in the following way: Set a clock counter register and a sampling period threshold register. When the value of the clock counter register is an integer multiple of the sampling period threshold register, the sampling period is determined to have arrived. Set a request counter for each requesting node and count the number of times the requesting node's request enters the master node within the sampling period. After each sampling period is satisfied, output the count values ​​of all non-zero request counters and reset the request counters to zero. The number of times the transaction identifier is reused is collected in the following way: Maintain a transaction identifier status table to record the transaction identifiers that each request node is currently processing; when a new request enters the master node, check if there is a record in the transaction identifier status table that has the same request node identifier and the same transaction identifier and is currently being processed; if it exists, it is determined that a transaction identifier reuse has occurred, and the reuse counter of the corresponding request node is incremented by 1; The number of transaction timeouts is collected in the following way: Set a timeout threshold register to configure the maximum allowed number of transaction processing cycles; record the actual number of processing cycles of each transaction initiated by the requesting node in the master node; when the actual number of processing cycles is greater than or equal to the timeout threshold, the transaction is determined to have timed out, and the timeout counter of the corresponding requesting node is incremented by 1.

[0009] The DoS attack detection method for heterogeneous multi-core consistent master nodes provided by the present invention includes the following methods for collecting the average completion cycle of transactions in the master node for the CPU type node: Configure the node type register to set the type information for each requesting node; Set the CPU acquisition cycle threshold register to configure the acquisition cycle length of CPU type nodes; Set up a transaction completion statistics register and a total transaction completion time register for each CPU type node; When a transaction completion information packet is received, the node type register is used to determine whether the requesting node to which the transaction belongs is a CPU type node. If so, increment the corresponding transaction completion statistics register by 1, and accumulate the transaction processing cycle count into the corresponding total transaction completion time register; When the CPU acquisition cycle is met, the average completion cycle is calculated. The average completion cycle is equal to the value of the total time taken to complete the transaction register divided by the value of the transaction completion statistics register, and the calculation result is output.

[0010] The DoS attack detection method for heterogeneous multi-core consistent master nodes provided by the present invention includes the following method for collecting the length of the continuous address access segment of the GPU type node: Set the GPU acquisition cycle threshold register to configure the acquisition cycle length of GPU type nodes; The step size range register is configured to set the allowed address offset range when determining address contiguousness. Set the current contiguous segment length register and the maximum contiguous segment length register for each GPU type node; When a request is received from a GPU-type node, the memory access address of the request is extracted; Determine whether the memory access address is within the range of the previous GPU access address plus or minus the step size; If so, increment the current segment length register by 1 and update the previous GPU access address with the current memory access address; If not, enter the new address segment, compare the value of the current contiguous segment length register with the maximum contiguous segment length register. If the current contiguous segment length is greater than the maximum contiguous segment length, update the maximum contiguous segment length register, and then reset the current contiguous segment length register to zero to start counting the new address segment. When the GPU acquisition cycle is met, the value of the maximum continuous segment length register is output as the address continuous access segment length.

[0011] The DoS attack detection method for heterogeneous multi-core consistent master nodes provided by the present invention includes the following methods for collecting the proportion of long transactions for the NPU type nodes: Configure the NPU acquisition cycle threshold register to configure the acquisition cycle length of NPU type nodes; Set the long transaction threshold register to configure the processing cycle threshold for determining long transactions; Set up a complete transaction statistics register and a long transaction statistics register for each NPU type node; When a transaction completion information packet is received, the request node to which the transaction belongs is determined based on the request node identifier information in the transaction completion information packet. If so, increment the corresponding completed transaction statistics register by 1 and obtain the actual number of processing cycles for that transaction; Determine whether the actual number of processing cycles is greater than or equal to the long transaction threshold; If so, increment the corresponding long transaction statistics register by 1; When the NPU acquisition cycle is met, the long transaction ratio is calculated. The long transaction ratio is equal to the value of the long transaction statistics register divided by the value of the completed transaction statistics register, and the calculation result is output.

[0012] According to the DoS attack detection method for heterogeneous multi-core consistent master nodes provided by the present invention, the step of determining whether there is an attacking node initiating a denial-of-service attack based on the detection index data includes: Compare the detection metrics data of each request node with their respective attack thresholds; When any detection index data is greater than or equal to its corresponding attack threshold, it is identified as a valid attack, and the attack node and attack type are determined. The priority configuration for attack types is as follows: the attack types corresponding to the dedicated detection indicators have higher priority than the attack types corresponding to the general detection indicators.

[0013] According to the DoS attack detection method for heterogeneous multi-core consistent master nodes provided by the present invention, when an attack node is determined to exist, the corresponding protective measures are executed, including: When the attack type is a request overload attack or an NPU type attack, rate limiting measures will be implemented. When the attack type is a transaction identifier reuse attack or a GPU-type attack, determine to implement control monitoring measures; When the attack type is a transaction timeout attack or a CPU-type attack, determine to implement measures to restrict memory access; Record the amount of various resources occupied by the attacking node in the master node in real time; When the amount of resources actually occupied by the attacking node reaches the threshold preset by the corresponding protection measures, a retry operation is performed on the request of the attacking node at the request entry point of the master node. The priority configuration of the protection measures is as follows: rate limiting measures take precedence over control and monitoring measures, and control and monitoring measures take precedence over memory access restriction measures; once a high-priority protection measure has been implemented on an attacking node, a low-priority protection measure will no longer be implemented.

[0014] This invention also provides a DoS attack defense device for heterogeneous multi-core consistent master nodes, comprising: The extraction module is used to extract the behavioral characteristics of each type of request node based on the application scenario of each heterogeneous request node in a heterogeneous multi-core system. The configuration module is used to configure differentiated detection indicators for each type of request node based on the behavioral characteristics of each type of request node; The judgment module is used to collect detection index data of the various types of request nodes and determine whether there are attack nodes that have launched denial-of-service attacks based on the detection index data. The execution module is used to implement corresponding protective measures when an attack node is detected.

[0015] The present invention provides a DoS attack detection method and defense device for heterogeneous multi-core consistent master nodes. This method extracts behavioral characteristics of various types of request nodes based on their application scenarios within the heterogeneous multi-core system. Based on these behavioral characteristics, it configures differentiated detection indicators for each type of request node. It collects the detection indicator data of each type of request node and determines whether an attacking node initiating a denial-of-service attack exists based on the data. When an attacking node is identified, corresponding protective measures are implemented. By analyzing the behavioral characteristics of heterogeneous nodes and providing targeted differentiated protection, this invention adds DoS attack monitoring and protection functions without affecting the core business functions of the master node, thereby improving the security and stability of the heterogeneous multi-core system. Attached Figure Description

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

[0017] Figure 1 This is a flowchart of the DoS attack detection method for heterogeneous multi-core consistent master nodes provided in this embodiment of the invention; Figure 2 This is a functional structure diagram of the DoS attack defense device for heterogeneous multi-core consistent master nodes provided in an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0019] Figure 1 The flowchart of the DoS attack detection method for heterogeneous multi-core consistent master nodes provided in the embodiments of the present invention is as follows: Figure 1As shown in the embodiment of the present invention, the DoS attack detection method for heterogeneous multi-core consistent master nodes includes: Step 101: Extract the behavioral characteristics of each type of request node based on the application scenarios of each heterogeneous request node in the heterogeneous multi-core system; Step 102: Configure differentiated detection indicators for each type of request node based on the behavioral characteristics of each type of request node; Step 103: Collect detection index data of each type of request node, and determine whether there are attack nodes that launch denial-of-service attacks based on the detection index data; Step 104: When an attack node is detected, execute the corresponding protective measures.

[0020] Traditional DoS protection solutions cannot distinguish the differences in business characteristics between heterogeneous nodes such as CPU, GPU, and NPU. They cannot protect on-chip system-specific resources such as transaction ID, flow control credit, and cache directory. Furthermore, they suffer from high false positive rates, inability to resist sophisticated resource exhaustion attacks, and inability to adapt to heterogeneous multi-core consistency systems.

[0021] The DoS attack detection method for heterogeneous multi-core consistent master nodes provided in this invention extracts behavioral characteristics of various types of request nodes based on their application scenarios in a heterogeneous multi-core system; configures differentiated detection indicators for each type of request node based on these behavioral characteristics; collects the detection indicator data of each type of request node; and determines whether an attacking node initiating a denial-of-service attack exists based on the detection indicator data. When an attacking node is determined to exist, corresponding protective measures are implemented. This invention analyzes the behavioral characteristics of heterogeneous nodes and provides targeted differentiated protection, adding DoS attack monitoring and protection functions without affecting the core business functions of the master node, thereby improving the security and stability of the heterogeneous multi-core system.

[0022] Based on any of the above embodiments, the step of extracting behavioral features of each type of request node according to the application scenario of each heterogeneous request node in the heterogeneous multi-core system includes: In application scenarios where CPU-type nodes serve as the core scheduling unit of the system, the extracted behavioral characteristics include: stable business requests, rapid response, and no long-term resource occupation. In application scenarios where GPU-type nodes are used as computing units, the extracted behavioral features include: short-term high bursts, large-bandwidth batch requests, and large-block contiguous memory access. In application scenarios where NPU-type nodes are used as acceleration units, the extracted behavioral characteristics include: batch continuous address access to memory, long-term transaction persistence, and periodic batch requests.

[0023] In this embodiment of the invention, the CPU node serves as the core scheduling unit of the system, responsible for system scheduling, interrupt handling, operating system, control flow intensive tasks, and other services. Its behavioral characteristics can be summarized as follows: business requests are relatively stable with no drastic traffic fluctuations, transaction interactions have a complete closed loop, responses are rapid, and there is no behavior that occupies resources for a long time.

[0024] GPU nodes, as the computing units of the system, are responsible for tasks such as graphics rendering and parallel computing. Their behavioral characteristics can be summarized as follows: they exhibit short-term high bursts, large-bandwidth batch requests, and large-block contiguous memory access; they have high transaction concurrency and prominent traffic peaks; and they are all compliant business behaviors.

[0025] As the acceleration unit of the system, the NPU node is responsible for AI computation tasks such as convolution, matrix multiplication, activation, and pooling. Its behavioral characteristics can be summarized as follows: batch continuous memory access, long-term transaction persistence, and periodic batch requests are the core characteristics. The transaction persistence time is long, the request pattern is fixed, and the resource consumption is continuous.

[0026] It should be noted that those skilled in the art should know that the behavioral characteristics of each request node described above are related to the system architecture design and actual application scenarios. The above description is only for illustrative purposes and should not be taken as limiting behavioral characteristics.

[0027] Based on any of the above embodiments, configuring differentiated detection indicators for each type of request node according to the behavioral characteristics of each type of request node includes: Configure common detection metrics for all types of request nodes. The common detection metrics include: the number of request packets within a unit collection period, the number of times the transaction identifier is reused, and the number of times the transaction times out. as well as, Based on the behavioral characteristics of CPU-type nodes, configure CPU-specific detection metrics, including: the average completion time of transactions in the master node; Based on the behavioral characteristics of GPU type nodes, configure GPU-specific detection indicators, including: the length of the continuous address access segment of memory access requests; Based on the behavioral characteristics of NPU type nodes, configure NPU-specific detection indicators, including: long transaction ratio, where long transactions refer to request transactions whose processing cycle exceeds a preset long transaction threshold.

[0028] Based on the behavioral characteristics of different node types, this invention constructs a categorized information collection system and establishes general collection indicators and specific collection indicators for each type of node.

[0029] General data collection metrics refer to the unified information collected from all requesting nodes, primarily used for basic anomaly detection. These general data collection metrics include the following: The unit collection cycle request message count metric; specifically, it is the total number of request messages for each node within a single collection cycle.

[0030] The single-node request transaction ID (TxnID) reuse count is collected as an indicator; specifically, it counts whether the transaction ID used by each node is reused and records the reuse count.

[0031] The transaction timeout count metric is specifically the number of times a transaction initiated by each node exceeds the preset completion time period during the clock cycle processed by the master node.

[0032] In this embodiment of the invention, the method for collecting the general detection index includes: The number of request messages within the unit collection period is collected in the following way: Set a clock counter register and a sampling period threshold register. When the value of the clock counter register is an integer multiple of the sampling period threshold register, the sampling period is determined to have arrived. Set a request counter for each requesting node and count the number of times the requesting node's request enters the master node within the sampling period. After each sampling period is satisfied, output the count values ​​of all non-zero request counters and reset the request counters to zero. For example, a 64-bit clock counter register, `time_cycle_cnt`, is set with a reset value of 0 and incremented by 1 on each rising edge of the clock. A sampling cycle threshold register, `cycle_ts`, is set and assigned a corresponding physical address; this can be modified by the software. The reset value of the sampling cycle threshold register is 1024. In this embodiment, a sampling cycle is considered complete when `time_cycle_cnt` is an integer multiple of 1024. A request counter, such as `req_cnt[SrcID]`, is set for each node, where `SrcID` is the ID of the requesting node. When a request from a node is detected entering the master node, the corresponding `req_cnt[SrcID]` is incremented by 1. At the end of each sampling cycle, all non-zero values ​​of `req_cnt[SrcID]` are transmitted to the judgment module. Upon entering the next sampling cycle, all `req_cnt[SrcID]` values ​​are reset to zero, and the counting restarts.

[0033] The number of times the transaction identifier is reused is collected in the following way: Maintain a transaction identifier status table to record the transaction identifiers that each request node is currently processing; when a new request enters the master node, check if there is a record in the transaction identifier status table that has the same request node identifier and the same transaction identifier and is currently being processed; if it exists, it is determined that a transaction identifier reuse has occurred, and the reuse counter of the corresponding request node is incremented by 1; For example, the ID reuse threshold register id_repeat_ts is set and a corresponding physical address is allocated; this can be modified by software. The reset value of id_reuse_ts is 5. An ID reuse counter is set for each node, such as id_reuse_cnt[SrcID], where SrcID is the ID identifier of the requesting node.

[0034] A TxnID status table is set up, with a capacity equal to the maximum number of requests the master node can handle. The status table contains: the request node ID (SrcID), the request transaction ID (TxnID), and a transaction processing status (valid). For each transaction request entering the master node, a copy of the SrcID, TxnID, and valid is saved, with valid marked as 1. When the master node finishes processing the transaction corresponding to the current SrcID and TxnID and is about to release internal processing resources, the valid flag for the corresponding SrcID and TxnID is set to 0.

[0035] When a transaction request enters the master node, it checks the TxnID status table. For cases with the same SrcID and TxnID, it checks if the "valid" flag is set to 1. If it is 1, id_reuse_cnt[SrcID] is incremented by 1. When id_reuse_cnt[SrcID] equals id_reuse_ts, the corresponding id_reuse_cnt[SrcID] is transmitted to the judgment module. The current id_reuse_cnt[SrcID] is then reset to zero, and the counting begins again.

[0036] The scenario where a request transaction ID is reused on the master node typically occurs when the master node returns data or a status response to the requesting node, waits for the requesting node's completion response, and then, while the master node is releasing resources or performing internal processing, it receives an access request with the same TxnID from the requesting node, resulting in the same request transaction ID appearing on the master node. This scenario may lead to abnormal transaction status processing on the master node or cause system blockage.

[0037] The number of transaction timeouts is collected in the following way: Set a timeout threshold register to configure the maximum allowed number of transaction processing cycles; record the actual number of processing cycles of each transaction initiated by the requesting node in the master node; when the actual number of processing cycles is greater than or equal to the timeout threshold, the transaction is determined to have timed out, and the timeout counter of the corresponding requesting node is incremented by 1.

[0038] This metric can be implemented in conjunction with the microarchitecture design of the master node. In the master node, when a request enters, the `queue_valid` (queue valid signal) corresponding to that request goes high, and `queue_cnt` (request processing count) starts counting. When `queue_valid` goes low, indicating that the current transaction has been completed, `queue_cnt` stops counting. Simultaneously, the queue transmits a completion message to the judgment module. After transmission, the corresponding `queue_cnt` is reset to 0. The transaction completion message includes: the request node's `SrcID`, the request transaction ID `TxnID`, and the request processing count value `queue_cnt`.

[0039] For example, a request timeout threshold register, `timeout_ts`, can be set and a corresponding physical address can be allocated; the software can modify this register. The reset value of the request timeout threshold register is 1024. A request timeout counter can be set for each node, such as `req_timeout_cnt[SrcID]`, where `SrcID` is the ID identifier of the requesting node.

[0040] Upon receiving the request node's SrcID and the request processing count value queue_cnt, the queue_cnt is compared with timeout_ts. If queue_cnt is greater than or equal to timeout_ts, the corresponding req_timeout_cnt[SrcID] is incremented by 1. At the end of each data collection cycle, all non-zero req_timeout_cnt[SrcID] values ​​are transmitted to the judgment module. At the start of the next data collection cycle, all req_timeout_cnt[SrcID] values ​​are reset to zero, and the counting begins again.

[0041] It should be noted that the current metric design can be implemented without considering the master node's microarchitecture. Specifically, it involves monitoring and recording request channel information, initiating transaction processing counting when a request enters the master node, continuously monitoring request-response channel information, and considering the transaction processing complete when a transaction response with the same SrcID and TxnID as recorded on the request channel is found. This response is then compared with timeout_ts. The above methods can be used to collect the current metric.

[0042] Dedicated data collection metrics refer to targeted information collection based on request node type, primarily used for detecting abnormal behavior of specified request node types. Specifically, based on the behavioral characteristics of each node type, corresponding dedicated data collection metrics are planned as follows: CPU-specific metrics: Average transaction completion time. Specifically, it measures the average processing time consumed by transactions on CPU nodes during processing on the master node.

[0043] GPU-specific data collection metric: Length of contiguous address access segment. Specifically, it measures the length of a contiguous address range in a single GPU memory access request, characterizing the continuity of memory access addresses.

[0044] NPU-specific data collection metric: Long transaction percentage. Specifically, it measures the proportion of long transactions in the NPU pool to the total number of transactions, representing the proportion of long-transaction business.

[0045] The planned data collection indicators are implemented in hardware, and the collection results are transmitted to the judgment module.

[0046] In this embodiment of the invention, the method for collecting the average completion cycle of transactions in the master node for the CPU type node includes: Step 201: Set the node type register to configure the type information of each requesting node; Step 202: Set the CPU acquisition cycle threshold register to configure the acquisition cycle length of CPU type nodes; Step 203: Set up a transaction completion statistics register and a total transaction completion time register for each CPU type node; Step 204: When a transaction completion information packet is received, determine whether the requesting node to which the transaction belongs is a CPU type node based on the node type register; Step 205: If yes, increment the corresponding transaction completion statistics register by 1 and accumulate the transaction processing cycle count into the corresponding transaction completion total time register. Step 206: When the CPU acquisition cycle is met, calculate the average completion cycle. The average completion cycle is equal to the value of the total transaction completion time register divided by the value of the transaction completion statistics register, and output the calculation result.

[0047] For example, a node type register src_type can be set and a corresponding physical address can be assigned, which can be modified by software. In this embodiment, there are three types of node types, so at least 2 bits are needed to identify the type of a node, where 0 represents the requested node is of CPU type, 1 represents the requested node is of GPU type, and 2 represents the requested node is of NPU type.

[0048] In the heterogeneous multi-core system of the current embodiment, four cores are used. The source ID encoding (SrcID) of the requesting node is encoded sequentially. The bit width of src_type is 8 bits, and the default value of src_type is 'b10010000'. Specifically, src_type[1:0]='b00' represents that requesting node 0 is of CPU type, and SrcID equals 0; src_type[3:2]='b00' represents that requesting node 1 is of CPU type, and SrcID equals 1; src_type[5:4]='b01' represents that requesting node 2 is of GPU type, and SrcID equals 2; src_type[7:6]='b10' represents that requesting node 3 is of NPU type, and SrcID equals 3. It should be noted that if the system uses a random node ID encoding method, a node type register needs to be allocated to each node, along with multiple physical addresses, for software modification.

[0049] The CPU sampling cycle threshold register cpu_cycle_ts is set and assigned a corresponding physical address; this can be modified by the software. The CPU sampling cycle threshold register is reset to 2048. When time_cycle_cnt is an integer multiple of 2048, it is considered one CPU sampling cycle.

[0050] Configure the CPU transaction completion statistics register cpu_done_num[SrcID], the CPU transaction completion total time register cpu_done_cycle[SrcID], and the average completion cycle register cpu_avg_cycle[SrcID].

[0051] The transaction completion information packet content described in the transaction timeout count collection metric is reused. Here, `queue_cnt` represents the processing cycle count of a transaction on the master node, specifically as follows: When a transaction completion information packet is received, the value of `SrcID` in the packet is first determined. Then, the corresponding `src_type[*:*]` is indexed based on the `SrcID` value. For example, if the current `SrcID` value is 1, it is indexed to `src_type[3:2]`, whose value is 'b00, indicating that this is a CPU-type transaction completion information packet. `cpu_done_num[SrcID]` is then incremented by 1, and `cpu_done_cycle[SrcID]` equals `cpu_done_cycle[SrcID]` plus `queue_cnt`, continuously accumulating. Whenever a CPU collection cycle is satisfied, the average completion cycle `cpu_avg_cycle[SrcID]` is calculated, which is equal to `cpu_done_cycle[SrcID]` divided by `cpu_done_num[SrcID]`.

[0052] In this embodiment of the invention, the method for collecting the length of the continuous address access segment of the GPU type node includes: Step 301: Set the GPU acquisition cycle threshold register to configure the acquisition cycle length of GPU type nodes; Step 302: Set the step range register to configure the allowed address offset range when determining address contiguousness; Step 303: Set the current contiguous segment length register and the maximum contiguous segment length register for each GPU type node; Step 304: When a request is received from a GPU-type node, extract the memory access address of the request; Step 305: Determine whether the memory access address is within the range of the previous GPU access address plus or minus the step size; Step 306: If yes, increment the current continuous segment length register by 1 and update the previous GPU access address with the current memory access address; Step 307: If not, enter the new address segment, compare the value of the current continuous segment length register with the maximum continuous segment length register. If the current continuous segment length is greater than the maximum continuous segment length, update the maximum continuous segment length register, and then reset the current continuous segment length register to zero to start counting the new address segment. Step 308: When the GPU acquisition cycle is met, output the value of the maximum continuous segment length register as the address continuous access segment length.

[0053] For example, the GPU acquisition cycle threshold register gpu_cycle_ts can be set and a corresponding physical address can be allocated; this can be modified by software. The GPU acquisition cycle threshold register is reset to 4096. When time_cycle_cnt is an integer multiple of 4096, it is considered one GPU acquisition cycle.

[0054] Configure the following registers: the address register curr_addr for cached transaction requests; the address register last_gpu_addr[SrcID] for the previous GPU access; the register curr_cnt_len[SrcID] for the current cumulative consecutive address segment length; and the register max_cnt_len[SrcID] for the current GPU acquisition cycle maximum consecutive address segment length. All of these registers should be reset to 0.

[0055] In the system of the current embodiment, if the physical address is 50 bits and the address is aligned according to the cache line, then only the address addr[49:6] needs to be considered. In a multi-core heterogeneous system, even if the requesting node sends request packets in an incrementing or decrementing manner according to the cache line, the order of the request packets arriving at the master node may still be out of order, and it is necessary to reduce the impact of out-of-order on the accuracy of statistics. Therefore, step_range is set and a corresponding physical address is assigned, which can be modified by the software. step_range can be related to the maximum number of requests that the GPU can send. For example, if the maximum request queue of the GPU is 64, then step_range can be set to 64. Then, the address addr[49:6] within the range of plus or minus 64 can be considered to be in a continuous segment.

[0056] When a request enters the master node, the value of SrcID in the request packet is first determined, and the corresponding src_type[*:*] is indexed to confirm that it is a GPU request transaction. The method for confirming the node type is as described in 3.4 and will not be repeated here. In the initial state, when the determination result is a GPU request transaction packet, [49:6] in the address field of the request transaction packet is cached in curr_addr. Then, it is determined whether curr_addr is within the range of last_gpu_addr[SrcID] plus step_range and last_gpu_addr[SrcID] minus step_range, as follows: If curr_addr is within a continuous range, then curr_cnt_len[SrcID] is incremented by 1, and then curr_addr is saved to last_gpu_addr[SrcID].

[0057] If curr_addr is not within a contiguous segment, it may enter a new contiguous space. First, curr_addr is saved to last_gpu_addr[SrcID]. Then, the values ​​of curr_cnt_len[SrcID] and max_cnt_len[SrcID] are compared. If curr_cnt_len[SrcID] is less than or equal to max_cnt_len[SrcID], curr_cnt_len[SrcID] is reset to zero, and counting restarts. If curr_cnt_len[SrcID] is greater than max_cnt_len[SrcID], curr_cnt_len[SrcID] is stored in max_cnt_len[SrcID]. Then, curr_cnt_len[SrcID] is reset to zero, and counting restarts from the new address segment.

[0058] When a GPU acquisition cycle is completed, max_cnt_len[SrcID] is transmitted to the judgment module.

[0059] In this embodiment of the invention, the method for collecting the proportion of long transactions for the NPU type node includes: Step 401: Set the NPU acquisition cycle threshold register to configure the acquisition cycle length of NPU type nodes; Step 402: Set the long transaction threshold register to configure the processing cycle threshold for determining long transactions; Step 403: Set up the complete transaction statistics register and long transaction statistics register for each NPU type node; Step 404: When a transaction completion information packet is received, determine whether the request node to which the transaction belongs is an NPU type node based on the request node identifier information in the transaction completion information packet. Step 405: If yes, increment the corresponding completed transaction statistics register by 1 and obtain the actual number of processing cycles for the transaction; Step 406: Determine whether the actual number of processing cycles is greater than or equal to the long transaction threshold; Step 407: If yes, increment the corresponding long transaction statistics register by 1; Step 408: When the NPU acquisition cycle is met, calculate the long transaction ratio. The long transaction ratio is equal to the value of the long transaction statistics register divided by the value of the completed transaction statistics register, and output the calculation result.

[0060] In this embodiment of the invention, an NPU acquisition cycle threshold register, npu_cycle_ts, is set and a corresponding physical address is allocated. The software can modify this register. The reset value of the NPU acquisition cycle threshold register is 4096. Similarly, when time_cycle_cnt is an integer multiple of 4096, it is considered one NPU acquisition cycle.

[0061] For example, configure the NPU transaction completion statistics register npu_done_cnt[SrcID], the NPU transaction completion time statistics register npu_long_done_cnt[SrcID], and the long transaction threshold register long_cycle. A physical address is allocated to long_cycle, which can be modified by software. The reset value of the long_cycle register is 512.

[0062] The transaction completion information packet content described in the transaction timeout count collection metric is reused. Specifically: When a transaction completion information packet is received, the completed transaction is determined to be an NPU type transaction based on the SrcID information in the packet. Then, npu_done_cnt[SrcID] is incremented by 1. The size of queue_cnt and long_cycle is compared; if queue_cnt is greater than or equal to long_cycle, npu_long_done_cnt[SrcID] is incremented by 1. Whenever an NPU collection cycle is satisfied, the long transaction rate npu_long_rate[SrcID] is calculated, and npu_long_rate[SrcID] is equal to npu_done_cnt[SrcID] divided by npu_long_done_cnt[SrcID].

[0063] Based on any of the above embodiments, the step of determining whether an attack node initiating a denial-of-service attack exists based on the detection index data includes: Step 501: Compare the detection index data of each request node with its corresponding attack threshold; Step 502: When any detection index data is greater than or equal to its corresponding attack threshold, it is identified as a valid attack, and the attack node and attack type are determined. The priority configuration for attack types is as follows: attack types corresponding to specific detection indicators have higher priority than attack types corresponding to general detection indicators. When multiple types of attacks are active simultaneously, the judgment result of the specific attack type is processed first, according to the rule that the specific attack type has higher priority than the general attack type.

[0064] This invention sets up an attack identification enable register and a corresponding attack threshold register for each indicator type, and assigns physical addresses to them, which can be modified by the software. The initial reset value of the attack identification enable register is 1, representing that the attack identification function is enabled by default. The attack threshold register is initially set according to the specific architecture and indicator type, and can be modified and adapted by the software later according to the application scenario. At the same time, a corresponding attack record register is set and assigned a physical address for the software to read. Each source ID only records the latest attack type. The priority of attack types is that specific collection indicators are higher than general collection indicators. Specifically: Based on the number of requesting nodes, four attack type record registers (rec_reg 0, 1, 2, 3) are set up. Their contents include the attack type (attack_type) and the source ID value (SrcID), indicating what type of attack the current SrcID is determined to be. There are six attack types, each corresponding to one of six attack indicators. An attack_type of 0 indicates that no attack behavior was detected from the current request source.

[0065] 1. attack_type=1, excessive request attack, corresponding to the collection of the number of request packets per unit period; The system configures the request overload attack enable register `req_attack_en` and the request overload attack threshold register `req_attack_ts`. When `req_cnt[SrcID]` is received, if `req_cnt[SrcID]` is greater than or equal to `req_attack_ts`, and the corresponding attack enable register `req_attack_en` is 1, it is identified as a valid attack. The system indexes the corresponding `rec_reg` (0, 1, 2, 3) based on the `SrcID` value, and then checks if the current `attack_type` is greater than 3. If it is greater than 3, `rec_reg` is not updated; if it is not greater than 3, following the principle of the latest attack type overwriting the old attack type, `SrcID` and `attack_type` are saved to the corresponding `rec_reg`. Simultaneously, when a valid attack is identified, an attack validity signal (`attack_valid`) is generated, and `attack_valid`, `SrcID`, and `attack_type` are transmitted to the execution module.

[0066] 2. attack_type=2, transaction ID reuse attack, corresponding to the single node request transaction ID reuse collection index; Set the transaction ID reuse attack enable register `id_attack_en` and the transaction ID reuse attack threshold register `id_attack_ts`. When receiving and analyzing `id_reuse_cnt[SrcID]`, if `id_reuse_cnt[SrcID]` is greater than or equal to `id_attack_ts`, and the corresponding attack enable register `id_attack_en` is 1, then it is identified as a valid attack. The update method of `rec_reg` is the same as described above and will not be repeated. At the same time, `attack_valid`, `SrcID`, and `attack_type` are transmitted to the execution module.

[0067] 3. attack_type=3, transaction timeout attack, corresponding to the number of transaction timeouts collected as an indicator; Configure the transaction timeout attack enable (timeout_attack_en) and the transaction timeout attack threshold register (timeout_attack_ts). Receive and analyze req_timeout_cnt[SrcID] to determine the timeout attack threshold.

[0068] 4. attack_type=4, CPU attack, corresponding to the average transaction completion time index for the CPU type. Set CPU attack enable (cpu_attack_en) and CPU attack threshold register (cpu_attack_ts). Receive and analyze cpu_avg_cycle[SrcID] to determine the threshold.

[0069] 5. attack_type=5, GPU attack, the length of the contiguous access segment of the address corresponding to the GPU type; Set GPU attack enable (gpu_attack_en) and GPU attack threshold register (gpu_attack_ts). Receive and analyze max_cnt_len[SrcID] to determine the threshold.

[0070] 6. attack_type=6, NPU attack, corresponding to the percentage of long transactions of the NPU type; Configure NPU attack enable (npu_attack_en) and NPU attack threshold register (npu_attack_ts). Receive and analyze npu_long_rate[SrcID] to determine the threshold.

[0071] When multiple types of attacks occur simultaneously, the attack information of the specific type is transmitted first, and then the attack information of the general type is transmitted to ensure that all attack information can be notified to the execution module.

[0072] Based on any of the above embodiments, the step of executing corresponding protective measures when an attack node is determined to exist includes: When the attack type is a request overload attack or an NPU type attack, rate limiting measures will be implemented. When the attack type is a transaction identifier reuse attack or a GPU-type attack, determine to implement control monitoring measures; When the attack type is a transaction timeout attack or a CPU-type attack, determine to implement measures to restrict memory access; Record the amount of various resources occupied by the attacking node in the master node in real time; When the amount of resources actually occupied by the attacking node reaches the threshold preset by the corresponding protection measures, a retry operation is performed on the request of the attacking node at the request entry point of the master node. The priority configuration of the protection measures is as follows: rate limiting measures take precedence over control and monitoring measures, and control and monitoring measures take precedence over memory access restriction measures; once a high-priority protection measure has been implemented on an attacking node, a low-priority protection measure will no longer be implemented.

[0073] In this embodiment of the invention, the protective measures are divided into three categories: Rate limiting (P0): Specifically, it limits the number of transaction requests for a given SrcID that can be executed on the master node. Once a certain number of transaction requests for a SrcID are being dequeued on the master node, subsequent requests for that SrcID will be retried.

[0074] Control listening measures (P1): Specifically, when the resources in the master node that handle the listening function are occupied by a transaction request for a certain SrcID for a period of time exceeding the specified threshold, the transaction request for this SrcID will no longer be processed, and subsequent requests for this SrcID will be retried.

[0075] Memory access restriction measure (P2): Specifically, when the memory access resources in the master node are occupied by a transaction request for a certain SrcID for a period of time exceeding the specified threshold, the transaction request for this SrcID will no longer be processed, and subsequent requests for this SrcID will be retried.

[0076] Of the above measures, rate limiting offers the greatest protection to the system, followed by monitoring and control measures, and lastly, memory access restriction measures. The protection measures are categorized as follows: rate limiting is stronger than monitoring and control measures, which in turn are stronger than memory access restriction measures. When a SrcID is protected by a higher-level protection measure, lower-level protection measures will not be implemented. A separate threshold register is set for each protection measure and assigned a corresponding physical address; these registers can be modified by the software. The threshold registers are as follows: rate limiting register `req_limit`, reset value 20; monitoring and control register `snp_limit`, reset value 30; memory access restriction register `mem_limit`, reset value 40.

[0077] In the master node, some notification logic is added to enable the execution module to obtain the corresponding key signal values. The key signal values ​​are as follows: real_running_num[SrcID]: Records the total number of requests processed by a given SrcID on the master node.

[0078] real_snp_num[SrcID]: Records the total number of requests made by a specific SrcID to access listening resources during the master node's processing.

[0079] real_mem_num[SrcID]: Records the total number of requests made by a given SrcID to access memory resources during the master node's processing.

[0080] Note that if a transaction request calls the listening function and accesses memory resources simultaneously during its processing lifecycle, the recording function mentioned above will not be affected.

[0081] In the master node, when a transaction request enters the master node and begins processing, the master node generates a single-cycle `req_add_valid` and `SrcID` notification to the execution module. The execution module then increments the corresponding `real_running_num[SrcID]` by 1. When a transaction request enters the final response process in the master node, the master node generates a single-cycle `req_dec_valid` and `SrcID` notification to the execution module. The execution module then decrements the corresponding `real_running_num[SrcID]` by 1.

[0082] Within the master node, when a transaction request needs to access resources for the listening function, the master node generates a single-cycle `snp_add_valid` and `SrcID` notification to the execution module. The execution module then increments the corresponding `real_snp_num[SrcID]` by 1. When a transaction request within the master node receives a listening response, the master node generates a single-cycle `snp_dec_valid` and `SrcID` notification to the execution module, which then decrements the corresponding `real_snp_num[SrcID]` by 1.

[0083] Within the master node, when a transaction request needs to access memory resources, the master node generates a single-cycle `mem_add_valid` and `SrcID` notification to the execution module. The execution module then increments the corresponding `real_mem_num[SrcID]` by 1. When a transaction request within the master node receives a memory access response, the master node generates a single-cycle `mem_dec_valid` and `SrcID` notification to the execution module, which then decrements the corresponding `real_mem_num[SrcID]` by 1.

[0084] The correspondence between attack types and protective measures is shown in the table below: When attack_type=1, rate limiting measure (P0) is selected. When attack_type=2, select the control listening measure (P1); When attack_type=3, select the memory access restriction measure (P2); When attack_type=4, select the memory access restriction measure (P2). When attack_type=5, select the control listening measure (P1); When attack_type=6, rate limiting measure (P0) is selected.

[0085] It should be noted that the above-mentioned protective measures are only for illustrative purposes and should not be considered as limiting protective measures.

[0086] In the execution module, a corresponding protection status record register `protect_status[SrcID]` and a protection validity register `protect_valid[SrcID]` are set for each node, and physical addresses are assigned for the software to read and write. The contents of the `protect_status[SrcID]` register include: the request source ID value `SrcID`, the attack type `attack_type`, and the corresponding activated protection measures. When `attack_type` is 0, it indicates that no attack has occurred at the current request source. `protect_valid[SrcID]` is used to start and stop protection measures. Regardless of the value written to `protect_valid[SrcID]` by the software, the corresponding `protect_valid[SrcID]` will be assigned a value of 0. A specific example is as follows: When the execution module receives attack_valid, SrcID and attack_type, it first checks the corresponding protect_status[SrcID] to see if a protection measure has been implemented and the current protection measure type.

[0087] If no protection measures are currently in place for the current SrcID, the corresponding protection measure is activated according to the attack type and protection measure mapping table. For example, if the current attack_type is 1, rate limiting is selected. Then, the relationship between req_limit and real_running_num[SrcID] is determined. When real_running_num[SrcID] is less than req_limit, protect_valid[SrcID] is 0; when real_running_num[SrcID] is greater than or equal to req_limit, the execution module sets the corresponding protect_valid[SrcID] to 1 and transmits it along with the current protection source ID to the request entry point of the master node. After receiving this signal, the master node determines at the request entry module whether the source ID of each transaction request is the same as the protection source ID. If they are the same, the transaction request is retried.

[0088] Similarly, if the monitoring control measure is selected, then snp_limit and real_snp_num[SrcID] are checked; Similarly, if memory access restriction measures are selected, then mem_limit and real_mem_num[SrcID] are checked; If the current SrcID has already been subject to the highest level of rate limiting (P0), the current protection measures will not be changed, but the current attack_type needs to be saved to the corresponding protect_status[SrcID]. The attack_type saving rule follows the principle of prioritizing the recording of specific attack types. When a specific type of attack occurs from a certain request source, subsequent general attack types will not be recorded.

[0089] In the execution module, once the restrictions are activated, there is no automatic removal mechanism. Instead, the software periodically queries the restriction status of the current source ID in the execution module and removes the restrictions by manipulating the protection's effective register. This is to prevent some programs from finding vulnerabilities that allow automatic removal, thus causing the system to repeatedly loop between activating and deactivating the protection measures. This approach is more effective in resolving DoS attacks.

[0090] This invention provides a DoS attack detection method for heterogeneous multi-core consistency master nodes. Using the master node as the core of protection, it combines the behavioral characteristics of heterogeneous request nodes such as CPU, GPU, and NPU. By designing extraction, configuration, judgment, and execution modules within the master node, it achieves accurate identification and efficient defense against DoS attacks. By analyzing the behavioral characteristics of heterogeneous nodes, it implements targeted differentiated protection, adding DoS attack monitoring and protection functions without affecting the core business functions of the master node, thus improving the security and stability of heterogeneous multi-core systems. It addresses the technical pain points of consistency master nodes being vulnerable to DoS attacks in heterogeneous multi-core scenarios, the high false positive rate of traditional protection schemes, and their inability to adapt to heterogeneous multi-core consistency systems. It provides a DoS attack detection method and defense device for heterogeneous multi-core consistency master nodes, enabling DoS attack detection and customized defense based on request node types, ensuring the safe and stable operation of normal business functions in heterogeneous multi-core consistency systems.

[0091] Figure 2 This is a schematic diagram of the DoS attack defense device for heterogeneous multi-core consistent master nodes provided in an embodiment of the present invention, as shown below. Figure 2 As shown, the DoS attack defense device for heterogeneous multi-core consistent master nodes provided in this embodiment of the invention includes: Extraction module 201 is used to extract behavioral features of various types of request nodes based on the application scenarios of each heterogeneous request node in a heterogeneous multi-core system. Configuration module 202 is used to configure differentiated detection indicators for each type of request node based on the behavioral characteristics of each type of request node; The judgment module 203 is used to collect detection index data of the various types of request nodes and determine whether there are attack nodes that launch denial-of-service attacks based on the detection index data. The execution module 204 is used to execute corresponding protective measures when an attack node is determined to exist.

[0092] The DoS attack defense device for heterogeneous multi-core consistent master nodes provided in this invention extracts behavioral characteristics of various types of request nodes based on the application scenarios of each heterogeneous request node in the heterogeneous multi-core system; configures differentiated detection indicators for each type of request node based on the behavioral characteristics of each type of request node; collects the detection indicator data of each type of request node; determines whether there is an attack node initiating a denial-of-service attack based on the detection indicator data; and executes corresponding protection measures when an attack node is determined to exist. This invention analyzes the behavioral characteristics of heterogeneous nodes and performs targeted differentiated protection, adding the function of monitoring and protecting against DoS attacks without affecting the core business functions of the master node, thereby improving the security and stability of the heterogeneous multi-core system.

[0093] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0094] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of software products. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0095] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A DoS attack detection method for heterogeneous multi-core consistent master nodes, characterized in that, include: Based on the application scenarios of each heterogeneous request node in a heterogeneous multi-core system, extract the behavioral characteristics of each type of request node. Based on the behavioral characteristics of each type of request node, configure differentiated detection indicators for each type of request node; Collect detection index data of each type of request node, and determine whether there are attack nodes that launch denial-of-service attacks based on the detection index data; When an attack node is detected, corresponding protective measures are implemented.

2. The DoS attack detection method for heterogeneous multi-core consistent master nodes according to claim 1, characterized in that, The behavioral characteristics of each type of request node are extracted based on the application scenarios of each heterogeneous request node in the heterogeneous multi-core system, including: In application scenarios where CPU-type nodes serve as the core scheduling unit of the system, the extracted behavioral characteristics include: stable business requests, rapid response, and no long-term resource occupation. In application scenarios where GPU-type nodes are used as computing units, the extracted behavioral features include: short-term high bursts, large-bandwidth batch requests, and large-block contiguous memory access. In application scenarios where NPU-type nodes are used as acceleration units, the extracted behavioral characteristics include: batch continuous address access to memory, long-term transaction persistence, and periodic batch requests.

3. The DoS attack detection method for heterogeneous multi-core consistent master nodes according to claim 2, characterized in that, The step of configuring differentiated detection metrics for each type of request node based on their behavioral characteristics includes: Configure common detection metrics for all types of request nodes. These common detection metrics include: the number of request packets per unit collection period, the number of times the transaction identifier is reused, and the number of transaction timeouts; and, Based on the behavioral characteristics of CPU-type nodes, configure CPU-specific detection metrics, including: the average completion time of transactions in the master node; Based on the behavioral characteristics of GPU type nodes, configure GPU-specific detection indicators, including: the length of the continuous address access segment of memory access requests; Based on the behavioral characteristics of NPU type nodes, configure NPU-specific detection indicators, including: long transaction ratio, where long transactions refer to request transactions whose processing cycle exceeds a preset long transaction threshold.

4. The DoS attack detection method for heterogeneous multi-core consistent master nodes according to claim 3, characterized in that, The methods for collecting the general detection indicators include: The number of request messages within the unit collection period is collected in the following way: Set a clock counter register and a sampling period threshold register. When the value of the clock counter register is an integer multiple of the sampling period threshold register, the sampling period is determined to have arrived. Set a request counter for each requesting node and count the number of times the requesting node's request enters the master node within the sampling period. After each sampling period is satisfied, output the count values ​​of all non-zero request counters and reset the request counters to zero. The number of times the transaction identifier is reused is collected in the following way: Maintain a transaction identifier status table to record the transaction identifiers that each request node is currently processing; when a new request enters the master node, check if there is a record in the transaction identifier status table that has the same request node identifier and the same transaction identifier and is currently being processed; if it exists, it is determined that a transaction identifier reuse has occurred, and the reuse counter of the corresponding request node is incremented by 1; The number of transaction timeouts is collected in the following way: Set a timeout threshold register to configure the maximum allowed number of transaction processing cycles; record the actual number of processing cycles of each transaction initiated by the requesting node in the master node; when the actual number of processing cycles is greater than or equal to the timeout threshold, the transaction is determined to have timed out, and the timeout counter of the corresponding requesting node is incremented by 1.

5. The DoS attack detection method for heterogeneous multi-core consistent master nodes according to claim 3, characterized in that, The methods for collecting the average completion time of transactions on the master node for the aforementioned CPU type nodes include: Configure the node type register to set the type information for each requesting node; Set the CPU acquisition cycle threshold register to configure the acquisition cycle length of CPU type nodes; Set up a transaction completion statistics register and a total transaction completion time register for each CPU type node; When a transaction completion information packet is received, the node type register is used to determine whether the requesting node to which the transaction belongs is a CPU type node. If so, increment the corresponding transaction completion statistics register by 1, and accumulate the transaction processing cycle count into the corresponding total transaction completion time register; When the CPU acquisition cycle is met, the average completion cycle is calculated. The average completion cycle is equal to the value of the total time taken to complete the transaction register divided by the value of the transaction completion statistics register, and the calculation result is output.

6. The DoS attack detection method for heterogeneous multi-core consistent master nodes according to claim 3, characterized in that, The methods for collecting the length of contiguous address access segments for the aforementioned GPU type nodes include: Set the GPU acquisition cycle threshold register to configure the acquisition cycle length of GPU type nodes; The step size range register is configured to set the allowed address offset range when determining address contiguousness. Set the current contiguous segment length register and the maximum contiguous segment length register for each GPU type node; When a request is received from a GPU-type node, the memory access address of the request is extracted; Determine whether the memory access address is within the range of the previous GPU access address plus or minus the step size; If so, increment the current segment length register by 1 and update the previous GPU access address with the current memory access address; If not, enter the new address segment, compare the value of the current contiguous segment length register with the maximum contiguous segment length register. If the current contiguous segment length is greater than the maximum contiguous segment length, update the maximum contiguous segment length register, and then reset the current contiguous segment length register to zero to start counting the new address segment. When the GPU acquisition cycle is met, the value of the maximum continuous segment length register is output as the address continuous access segment length.

7. The DoS attack detection method for heterogeneous multi-core consistent master nodes according to claim 3, characterized in that, The methods for collecting the proportion of long transactions for the aforementioned NPU type nodes include: Configure the NPU acquisition cycle threshold register to configure the acquisition cycle length of NPU type nodes; Set the long transaction threshold register to configure the processing cycle threshold for determining long transactions; Set up a complete transaction statistics register and a long transaction statistics register for each NPU type node; When a transaction completion information packet is received, the request node to which the transaction belongs is determined based on the request node identifier information in the transaction completion information packet. If so, increment the corresponding completed transaction statistics register by 1 and obtain the actual number of processing cycles for that transaction; Determine whether the actual number of processing cycles is greater than or equal to the long transaction threshold; If so, increment the corresponding long transaction statistics register by 1; When the NPU acquisition cycle is met, the long transaction ratio is calculated. The long transaction ratio is equal to the value of the long transaction statistics register divided by the value of the completed transaction statistics register, and the calculation result is output.

8. The DoS attack detection method for heterogeneous multi-core consistent master nodes according to claim 1, characterized in that, The step of determining whether an attack node is launching a denial-of-service attack based on the detection index data includes: Compare the detection metrics data of each request node with their respective attack thresholds; When any detection index data is greater than or equal to its corresponding attack threshold, it is identified as a valid attack, and the attack node and attack type are determined. The priority configuration for attack types is as follows: the attack types corresponding to the dedicated detection indicators have higher priority than the attack types corresponding to the general detection indicators.

9. The DoS attack detection method for heterogeneous multi-core consistent master nodes according to claim 1, characterized in that, When an attack node is detected, the corresponding protective measures are executed, including: When the attack type is a request overload attack or an NPU type attack, rate limiting measures will be implemented. When the attack type is a transaction identifier reuse attack or a GPU-type attack, determine to implement control monitoring measures; When the attack type is a transaction timeout attack or a CPU-type attack, determine to implement measures to restrict memory access; Record the amount of various resources occupied by the attacking node in the master node in real time; When the amount of resources actually occupied by the attacking node reaches the threshold preset by the corresponding protection measures, a retry operation is performed on the request of the attacking node at the request entry point of the master node. The priority configuration of the protection measures is as follows: rate limiting measures take precedence over control and monitoring measures, and control and monitoring measures take precedence over memory access restriction measures; once a high-priority protection measure has been implemented on an attacking node, a low-priority protection measure will no longer be implemented.

10. A DoS attack defense device for heterogeneous multi-core consistent master nodes, characterized in that, include: The extraction module is used to extract the behavioral characteristics of each type of request node based on the application scenario of each heterogeneous request node in a heterogeneous multi-core system. The configuration module is used to configure differentiated detection indicators for each type of request node based on the behavioral characteristics of each type of request node; The judgment module is used to collect detection index data of the various types of request nodes and determine whether there are attack nodes that have launched denial-of-service attacks based on the detection index data. The execution module is used to implement corresponding protective measures when an attack node is detected.

Images