A computer hardware device identity authentication and anti-counterfeiting method and system

CN123020221APending Publication Date: 2026-10-30TIANJIN BINHAI NEW DISTRICT DAGANG STREET COMMUNITY HEALTH SERVICE CENTER +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611359050.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-09-03
Publication Date
2026-10-30

AI Technical Summary

Technical Problem

[0003]现有身份验证通常读取处理器标识、主板信息、网卡地址、存储设备序列号等硬件信息,或者根据设备运行过程中采集的数据形成设备识别信息,但上述信息主要反映单个硬件部件或者设备在某一运行状态下的特征,在硬件信息被修改、复制或者由虚拟化环境模拟时,难以进一步判断当前处理器核心与内存节点是否仍按照登记设备对应的实际资源组织关系运行

Benefits of technology

1、通过建立登记资源关系变化过程,并获取目标任务迁移前后的第一资源关系、第二资源关系及资源关系变化过程,可核验当前服务器处理器核心与内存节点对应的实际资源组织状态是否与登记设备一致,降低仅依赖静态硬件标识时对硬件资源组织状态变化识别不足造成的误判风险,提高服务器身份核验的可靠性。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123020221A_ABST
    Figure CN123020221A_ABST
Patent Text Reader

Abstract

The application discloses a computer hardware equipment identity authentication and anti-fake method and system, relates to the technical field of computer information authentication, and establishes a registration resource relationship change process in the registration stage of a physical server in a data center, obtains a first resource relationship before and a second resource relationship after a first execution position corresponding to different memory nodes is migrated from a first execution position to a second execution position when the server is subsequently accessed, matches the resource relationship change process with the registration resource relationship change process, verifies whether the actual resource organization state corresponding to the current server processor core and the memory node is consistent with the registered equipment, thereby identifying the equipment whose static hardware information remains consistent but the actual hardware resource organization state is changed, and improving the equipment identity authentication reliability after the server is re-accessed, asset verification and hardware replacement.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of computer information verification technology, specifically to a method and system for authenticating and preventing counterfeiting of computer hardware devices. Background Technology

[0002] Computer hardware devices typically include processors, memory, storage devices, network interface cards (NICs), and related control components on the motherboard. When a device connects to a network, runs software, or accesses a business system, it is necessary to verify the current device's identity by combining the device's own hardware information, and to identify replaced, counterfeited, or abnormally connected devices. Therefore, computer hardware device authentication has become an important part of device management and security protection.

[0003] Existing authentication methods typically read hardware information such as processor identifier, motherboard information, network card address, and storage device serial number, or form device identification information based on data collected during device operation. However, the above information mainly reflects the characteristics of a single hardware component or device in a certain operating state. When the hardware information is modified, copied, or simulated by a virtualization environment, it is difficult to further determine whether the current processor core and memory nodes are still operating according to the actual resource organization relationship corresponding to the registered device.

[0004] Especially when there are many computers of the same model, the devices have undergone system reinstallation, or the hardware information can be read and modified by software, it is difficult to identify devices whose static hardware information is consistent but whose resource organization status corresponding to the processor core and memory nodes has changed, based solely on comparisons of fixed hardware information or a single run. Changes in system load, background program operation, and processor running status may also cause fluctuations in running data, thereby increasing the risk of misidentification of device identity and inconsistencies between device management records and the actual hardware resource organization status. Summary of the Invention

[0005] This invention provides a method and system for computer hardware device authentication and anti-counterfeiting, which solves the problems mentioned in the background art.

[0006] A method for authenticating and preventing counterfeiting of computer hardware devices includes the following steps: S1. Obtain processor core information and memory node information in computer hardware devices, determine the first execution location and the second execution location corresponding to different memory nodes based on the processor core information and the memory node information, and determine the first reference task and the second reference task corresponding to the target task. S2. Run the target task at the first execution position, obtain the first resource relationship between the target task and the first reference task and the second resource relationship between the target task and the second reference task, and obtain an initial resource relationship record; S3. Keeping the execution content of the target task, the first reference task, and the second reference task unchanged, the target task is migrated from the first execution position to the second execution position, and the first resource relationship between the target task and the first reference task and the second resource relationship between the target task and the second reference task are re-acquired to obtain the resource relationship record after migration; S4. Determine the resource relationship change process corresponding to the change in the target task execution location based on the initial resource relationship record and the post-migration resource relationship record, and match the resource relationship change process with the registered resource relationship change process corresponding to the registered device to obtain the device authentication result.

[0007] Preferably, S1 includes: S11. Read the processor core number and the memory node number corresponding to each processor core from the processor core information, and read the memory node number from the memory node information. According to the arrangement order of the memory node numbers, select the first two memory nodes from the memory nodes that each contain at least two online processor cores and determine them as the first memory node and the second memory node in sequence. According to the arrangement order of the processor core numbers, select the first two online processor cores from the processor cores corresponding to the first memory node and determine them as the first processor core and the first reference processor core in sequence. Select the first two online processor cores from the processor cores corresponding to the second memory node and determine them as the second processor core and the second reference processor core in sequence.

[0008] S12. Bind the target task to the first processor core and allocate the data used by the target task to the first memory node, define the first processor core and the first memory node together as the first execution location, define the second processor core and the second memory node together as the second execution location, bind the first reference task to the first reference processor core and allocate the data used by the first reference task to the first memory node, bind the second reference task to the second reference processor core and allocate the data used by the second reference task to the second memory node.

[0009] Preferably, S2 includes: S21. When the target task is located at the first execution position, perform multiple rounds of testing for the first reference task. In each round, run the target task, run the target task and the first reference task together, and run the target task again. Record the independent running time before the first joint running, the first joint running time and the independent running time after the first joint running for the target task respectively.

[0010] S22. Perform the same number of tests as in S21 for the second reference task. In each round, run the target task, run the target task and the second reference task together, and run the target task again. Record the independent running time before the second joint run, the second joint run time and the independent running time after the second joint run for the target task respectively.

[0011] Preferably, S2 further includes: S23. In each round, determine whether the first common running time is simultaneously greater than the independent running time before the first common running and the independent running time after the first common running in the same round. When the number of rounds that satisfy the size relationship is greater than the number of rounds that do not satisfy the size relationship, record the first resource relationship as existing; otherwise, record the first resource relationship as unconfirmed.

[0012] S24. In each round, determine whether the second common running time is simultaneously greater than the independent running time before the second common running and the independent running time after the second common running in the same round. When the number of rounds that satisfy the size relationship is greater than the number of rounds that do not satisfy the size relationship, record the second resource relationship as existing; otherwise, record the second resource relationship as unconfirmed, and write the recording status of the first resource relationship and the second resource relationship into the initial resource relationship record.

[0013] Preferably, S3 includes: S31. Maintain the binding relationship between the first reference task and the first reference processor core, and the memory node where the data used by the first reference task is located, and maintain the binding relationship between the second reference task and the second reference processor core, and the memory node where the data used by the second reference task is located, unchanged.

[0014] S32. Unbind the target task from the first processor core, bind the target task to the second processor core, and migrate the physical page corresponding to the data used by the target task to the second memory node, keeping the task content and resource access operations of the target task unchanged, and migrate the target task from the first execution location to the second execution location.

[0015] Preferably, S3 further includes: S33. When the target task is located at the second execution position, perform multiple rounds of testing for the first reference task and the second reference task in the running order defined by S21 and S22 above, and re-record the first resource relationship and the second resource relationship according to the size relationship defined by S23 and S24 above, and write the recording status of the re-recorded first resource relationship and the second resource relationship into the migrated resource relationship record.

[0016] S34. When the first resource relationship record in the initial resource relationship record exists and the second resource relationship record is unconfirmed, and the first resource relationship record in the migrated resource relationship record is unconfirmed and the second resource relationship record exists, the state transition from the existence of the first resource relationship to the unconfirmed state and the state transition from the unconfirmed state to the existence of the second resource relationship are recorded as the migration stage in the process of resource relationship change.

[0017] Preferably, S3 further includes: S35. Keep the running positions of the first reference task and the second reference task unchanged, move the target task from the second execution position back to the first execution position, re-execute the running process defined by S21 and S22 for the first reference task and the second reference task respectively, and re-record the first resource relationship and the second resource relationship according to the size relationship defined by S23 and S24, and write the recording status of the re-recorded first resource relationship and the second resource relationship into the recovery resource relationship record;

[0018] S36. When the recording status of the first resource relationship and the second resource relationship in the restored resource relationship record are the same as the corresponding recording status in the initial resource relationship record, and the first resource relationship record in the initial resource relationship record is existing and the second resource relationship record is unconfirmed, the state transition of restoring the first resource relationship to existing and the second resource relationship to unconfirmed is recorded as the recovery stage in the resource relationship change process.

[0019] Preferably, S4 includes: S41. Read the initial resource relationship record, the migrated resource relationship record, and the restored resource relationship record in sequence according to the order in which the target task is located at the first execution position, migrates to the second execution position, and returns to the first execution position;

[0020] S42. Write the record status of the first resource relationship and the second resource relationship in the initial resource relationship record, the record status of the first resource relationship and the second resource relationship in the migrated resource relationship record, and the record status of the first resource relationship and the second resource relationship in the restored resource relationship record into the resource relationship change process in the order of change of the corresponding execution position.

[0021] Preferably, S4 further includes: S43. During the equipment registration phase, the target task execution position in the registered equipment is changed in the order of the first execution position, the second execution position, and the first execution position. The recording status of the first resource relationship and the second resource relationship corresponding to each execution position is recorded, and the registration resource relationship change process is formed in the order of execution position change.

[0022] S44. During the authentication phase, the resource relationship change process of the current computer hardware device is obtained in the same execution position change order as the device registration phase. The record status of the first resource relationship and the second resource relationship at the corresponding execution position during the resource relationship change process is compared stage by stage with the record status of the first resource relationship and the second resource relationship at the corresponding execution position during the registered resource relationship change process. When the record status of the first resource relationship and the second resource relationship at each stage is consistent, the device authentication result is recorded as authentication passed; otherwise, the device authentication result is recorded as authentication failed.

[0023] A computer hardware device authentication and anti-counterfeiting system includes a processor and a memory. The memory is used to store program instructions, the process of changes in the registration resource relationship corresponding to the registration device, and registration test configuration records. When the processor executes the program instructions, it runs the following modules: an execution location configuration module, which is used to obtain the processor core information and memory node information of the computer hardware device, determine the first execution location and the second execution location corresponding to different memory nodes according to the processor core information and the memory node information, and determine the first reference task and the second reference task corresponding to the target task. The initial resource relationship acquisition module is used to acquire the first resource relationship between the target task and the first reference task and the second resource relationship between the target task and the second reference task when the target task is running at the first execution position, and form an initial resource relationship record; The migration resource relationship acquisition module is used to keep the running content of the target task, the first reference task and the second reference task unchanged, migrate the target task from the first execution position to the second execution position, reacquire the first resource relationship and the second resource relationship, and form a migration resource relationship record; The authentication module is used to form a resource relationship change process based on the initial resource relationship record and the migrated resource relationship record, read the registered resource relationship change process corresponding to the registered device from the memory, compare the resource relationship change process with the registered resource relationship change process corresponding to the registered device stage by stage, and form a device authentication result based on the comparison result.

[0024] This invention provides a method and system for computer hardware device authentication and anti-counterfeiting, which has the following beneficial effects: 1. By establishing a registration process for changes in resource relationships and obtaining the first resource relationship, the second resource relationship, and the changes in resource relationships before and after the migration of the target task, it is possible to verify whether the actual resource organization status corresponding to the current server processor core and memory node is consistent with the registered device. This reduces the risk of misjudgment caused by insufficient identification of changes in hardware resource organization status when relying solely on static hardware identifiers, and improves the reliability of server identity verification. Attached Figure Description

[0025] Figure 1 A schematic diagram illustrating the steps of a computer hardware device authentication and anti-counterfeiting method; Figure 2 This is a schematic diagram of a computer hardware device authentication and anti-counterfeiting system. Detailed Implementation

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

[0027] Example 1 This embodiment uses a data center physical server identity verification scenario as an example. During the server registration phase, the process of changes in the registered resource relationships corresponding to the registered device is obtained. When the server is subsequently connected, the target task is run sequentially at the first execution position and the second execution position corresponding to different memory nodes. The process of changes in the resource relationships between the target task before and after migration and the first reference task and the second reference task is obtained and matched with the process of changes in the registered resource relationships. Thus, while keeping the static hardware information such as device serial number and processor model consistent, the actual resource organization state corresponding to the processor core and memory node is further verified to be consistent with the registered device.

[0028] This invention provides a method for authenticating and preventing counterfeiting of computer hardware devices. Please refer to [link / reference]. Figure 1 This includes the following steps: S1. Obtain processor core information and memory node information in computer hardware devices, determine the first execution location and the second execution location corresponding to different memory nodes based on the processor core information and the memory node information, and determine the first reference task and the second reference task corresponding to the target task. S2. Run the target task at the first execution position, obtain the first resource relationship between the target task and the first reference task and the second resource relationship between the target task and the second reference task, and obtain an initial resource relationship record; S3. Keeping the execution content of the target task, the first reference task, and the second reference task unchanged, the target task is migrated from the first execution position to the second execution position, and the first resource relationship between the target task and the first reference task and the second resource relationship between the target task and the second reference task are re-acquired to obtain the resource relationship record after migration; S4. Determine the resource relationship change process corresponding to the change in the target task execution location based on the initial resource relationship record and the post-migration resource relationship record, and match the resource relationship change process with the registered resource relationship change process corresponding to the registered device to obtain the device authentication result.

[0029] In this embodiment, by establishing the process of registering resource relationship changes during the registration phase of the physical server in the data center, and obtaining the first resource relationship, the second resource relationship, and the process of resource relationship changes before and after the target task is migrated from the first execution position to the second execution position when the server is subsequently connected, it is possible to verify whether the actual resource organization status corresponding to the current server processor core and memory node is consistent with the registered device. This allows for the identification of devices whose static hardware information remains consistent but whose actual hardware resource organization status has changed, thereby improving the reliability of device identity verification after server reconnection, asset verification, and hardware replacement.

[0030] Example 2 Based on the data center physical server identity verification scenario set in Example 1, this example further describes the formation process of the first execution location, the second execution location, the first reference task, the second reference task, the first resource relationship, and the second resource relationship. This example uses a server with NUMA memory management enabled and at least two available memory nodes as the implementation object. In the same device registration or identity verification process, the processor core selection result, memory node selection result, task program, data area capacity, number of test loops, number of test rounds, and timing method are fixed. Subsequent steps continue to be executed according to the fixed parameters.

[0031] It should be noted that, in this embodiment, "fixed" means that once the parameter is determined, its value is written into the test configuration record and will not be recalculated or replaced before the end of the test. For example, if the number of test loops is determined to be 256, the value 256 will be read and executed for each group of tests after the migration of the first reference task, the second reference task, and the target task, and the number of loops will not be changed temporarily based on the results of a certain round of tests.

[0032] It should be noted that the test configuration record is used to save the actual running configuration used in the current device registration or authentication process. After the device registration process completes the three execution phases, the first processor core number, the second processor core number, the first reference processor core number, the second reference processor core number, the first memory node number, the second memory node number, the data area capacity, the address increment step size, the number of test loops, and the number of test rounds are written into the registration test configuration record and saved. Subsequent authentication first reads the registration test configuration record, and then uses the values ​​of each field in it to create the test configuration record corresponding to this authentication, thereby ensuring that the registration phase and the authentication phase use the same set of registered running configurations.

[0033] Specifically: S1 includes: S11. Read the processor core number and the memory node number corresponding to each processor core from the processor core information, and read the memory node number from the memory node information. According to the arrangement order of the memory node numbers, select the first two memory nodes from the memory nodes that each contain at least two online processor cores and determine them as the first memory node and the second memory node in sequence. According to the arrangement order of the processor core numbers, select the first two online processor cores from the processor cores corresponding to the first memory node and determine them as the first processor core and the first reference processor core in sequence. Select the first two online processor cores from the processor cores corresponding to the second memory node and determine them as the second processor core and the second reference processor core in sequence. Specifically: The identity verification program first reads the logical processor number currently marked as online by the operating system, then reads the physical processor number, physical core number, and NUMA node number corresponding to each logical processor, and uses the combination of physical processor number and physical core number as the basis for physical core identification. Multiple logical processors with the same combination are grouped into the same physical core, and only the one with the smallest logical processor number is retained for subsequent selection, thereby avoiding the target task and reference task being assigned to two hardware threads on the same physical core.

[0034] In this embodiment, the Linux system can read / sys / devices / system / cpu / online to obtain the range of online logical processors, read / sys / devices / system / cpu / cpuN / topology / physical_package_id and core_id to obtain the physical processor number and physical core number corresponding to logical processor N, and read / sys / devices / system / node / nodeM / cpulist to obtain the set of logical processors corresponding to memory node M. The identity verification program matches the above three types of data item by item according to the logical processor number to obtain the memory node to which each available physical core belongs.

[0035] Specifically: After completing the physical core grouping, count the number of physical cores remaining in each memory node. Memory nodes with less than 2 physical cores are removed from the candidate range. Sort the remaining memory nodes in ascending order of node number and read the first two node numbers. Write the first node number after sorting to the first memory node and the second node number to the second memory node. Then sort the available processor core numbers in the two memory nodes in ascending order. Write the first two numbers in the first memory node to the first processor core and the first reference processor core, respectively. Write the first two numbers in the second memory node to the second processor core and the second reference processor core, respectively.

[0036] For example, if the read results show that memory node 0 corresponds to processor cores 0, 2, 4, and 6, and memory node 1 corresponds to processor cores 8, 10, 12, and 14, then the first memory node is recorded as node 0, the second memory node is recorded as node 1, the first processor core is recorded as processor core 0, the first reference processor core is recorded as processor core 2, the second processor core is recorded as processor core 8, and the second reference processor core is recorded as processor core 10. The above six results are then written into the test configuration record.

[0037] It should be noted that the determination of whether the first memory node, the second memory node, and the processor core remain unchanged is based on the corresponding number in the test configuration record. If the number read later is the same as the corresponding number in the test configuration record, it is determined that no change has occurred. The determination is not based on the method of being basically the same or close to the original number or by manual observation.

[0038] S12. Bind the target task to the first processor core and allocate the data used by the target task to the first memory node, define the first processor core and the first memory node together as the first execution location, define the second processor core and the second memory node together as the second execution location, bind the first reference task to the first reference processor core and allocate the data used by the first reference task to the first memory node, bind the second reference task to the second reference processor core and allocate the data used by the second reference task to the second memory node.

[0039] Specifically: The identity verification program creates a target task thread, a first reference task thread, and a second reference task thread, and records thread identifiers for each of the three threads. Based on the thread identifiers, it sets processor affinity masks, where the processor affinity mask for the target task contains only the first processor core, the processor affinity mask for the first reference task contains only the first reference processor core, and the processor affinity mask for the second reference task contains only the second reference processor core. After setting, the processor affinity masks for the three threads are read again. When the read values ​​contain only the predetermined processor core numbers, the memory allocation process begins.

[0040] Specifically: allocate non-overlapping virtual address regions for the target task, the first reference task, and the second reference task respectively; set a first memory node binding strategy for the virtual address regions of the target task and the first reference task; set a second memory node binding strategy for the virtual address region of the second reference task; and then write one byte per page starting from the first address of each virtual address region according to the system memory page size, so as to trigger the virtual pages that have not yet been established to complete the actual physical memory allocation.

[0041] In this embodiment, the Linux system can use sched_setaffinity to set task processor affinity, use mmap to request virtual address regions, use mbind and set the MPOL_BIND policy to limit the corresponding virtual address regions to obtain physical pages from the specified NUMA nodes, and use move_pages to query the NUMA node number where each page is located after the page-by-page writing is completed, and check the queried node number page by page.

[0042] Specifically: If the node numbers obtained from querying all allocated pages of the target task and all allocated pages of the first reference task are equal to the first memory node number, and the node numbers obtained from querying all allocated pages of the second reference task are equal to the second memory node number, then the memory allocation result is retained and subsequent tests are initiated; if the node number corresponding to any allocated page is different from the specified node number, then the memory allocation status is recorded as failed, the data area of ​​the corresponding task is released and the current test process is terminated, no initial resource relationship record or post-migration resource relationship record is formed, and the processor core information and memory node information are reread from S11 before execution.

[0043] It should be noted that the determination of the specified memory node is based on the page query results, rather than directly assuming that the page must be located in the corresponding node based on the NUMA strategy being set up. This ensures that the data area used in subsequent tests has been actually allocated to the first or second memory node.

[0044] Specifically: Read the last-level cache capacity that can be shared by the first processor core, the first reference processor core, the second processor core, and the second reference processor core, and select the largest value from the obtained last-level cache capacity as the data area capacity benchmark. Set the data area capacity of the target task, the first reference task, and the second reference task to twice the capacity benchmark, and then adjust it upward according to the system page size to a capacity value that can be divided by the page size. All three tasks use the same adjusted capacity value.

[0045] For example, if the maximum value of the last-level cache capacity corresponding to the four processor cores is 32MB and the system page size is 4KB, then the capacity base is 32MB, and the calculated data area capacity is 64MB. Since 64MB is divisible by 4KB, all three tasks request a 64MB data area. If the calculation result is not divisible by the page size, then the integer quotient obtained by dividing the calculation result by the page size is increased by 1 and multiplied by the page size to obtain the actual allocated capacity.

[0046] Specifically: The three tasks use the same memory access operation. The identity verification program reads the size of the processor cache line and sets the cache line size as the address increment step. Each task starts from the first address of its own data area, reads the data at the current position, increments the read data by 1, writes it back to the current position, increments the current address by one address increment step, and continues to execute. When the current address reaches or exceeds the end address of its own data area, a complete traversal ends, and a complete traversal is recorded as one loop.

[0047] It should be noted that if the size of the cache line read is 64 bytes, each task will access the data area in sequence at offsets of 0 bytes, 64 bytes, 128 bytes from the beginning of its own data area until the last access position does not exceed the end of the data area. The three tasks only use the same offset rule and access their own independent data areas, and do not access the same virtual address or the same physical page.

[0048] Specifically: each time data is read, it is simultaneously added to the result variable set independently for the task. After the current test is completed, the result variable is read once and written to the task execution record, thereby ensuring that the memory read result participates in the subsequent program output and preventing the compiler from deleting memory access processes that have no subsequent use.

[0049] S2 includes: S21. When the target task is located at the first execution position, perform multiple rounds of testing for the first reference task. In each round, run the target task, run the target task and the first reference task together, and run the target task again. Record the independent running time before the first joint running, the first joint running time and the independent running time after the first joint running for the target task respectively. Specifically: Before conducting multiple rounds of testing, determine the number of test loops. The initial value of the number of test loops is set to 1. The target task executes the memory access action limited by S12 at the first execution position according to the current number of test loops and obtains the running time. When the running time is less than 100ms, multiply the current number of test loops by 2 to obtain a new number of test loops and run the target task again. Repeat the doubling and testing process until the first running time of greater than or equal to 100ms is obtained. Write the number of test loops used in this test into the test configuration record.

[0050] It should be noted that this embodiment uses 100ms as the lower limit for loop count calibration. 100ms is only used to avoid the time occupied by thread synchronization, system calls and clock reading being too high in the total running time due to the short running process of a single target task. It does not participate in the determination of the first resource relationship and the second resource relationship. When implementing other timing environments, the calibration lower limit can be set to the larger value between 1000 times the actual measured reading overhead of the timer and 100ms.

[0051] Specifically: The actual reading overhead of the timer was obtained by continuously executing 10,000 sets of adjacent clock reads. In each set, the same clock read interface was called twice and the time difference between the second read time and the first read time was calculated, thus obtaining 10,000 time differences. The 10,000 time differences were sorted in ascending order of value and the 5,000th time difference was taken as the single clock read overhead. This value was then multiplied by 1,000 and compared with 100ms. The larger value was used as the lower limit for the loop count calibration.

[0052] It should be noted that if the lower limit of the number of loops obtained according to the above rules is 100ms, then the number of test loops will increase in multiples from 1, 2, 4, 8. For example, the number of loops 128 corresponds to a running time of 87ms and the number of loops 256 corresponds to a running time of 171ms. Therefore, the number of test loops is fixed at 256, and all subsequent independent and joint running phases of the target tasks will perform 256 complete data region traversals.

[0053] Specifically: During the process of obtaining the independent running time before the first joint operation, both the first reference task and the second reference task are set to a waiting state. After reading the monotonic clock to obtain the start time, the target task is started to perform memory access actions for the number of test loops. After the target task completes the last loop, the same monotonic clock is read immediately to obtain the termination time. The termination time is subtracted from the start time to obtain the independent running time before the first joint operation.

[0054] Specifically: During the acquisition of the first common running time, the target task and the first reference task first arrive at the same synchronization barrier. After both tasks write the ready state to the synchronization barrier, the identity verification program writes the common start state. After receiving the common start state, the target task reads the monotonic clock to obtain the common running start time before performing the first memory access, and then performs the memory access action for the test loop number. After receiving the common start state, the first reference task continuously repeats the complete traversal of its own data region, and reads the target task's end state after each traversal.

[0055] Specifically: After the target task completes the last memory access in the test loop, it immediately reads the same monotonic clock to obtain the common run termination time, subtracts the common run start time from the common run termination time to obtain the first common run time, and then writes it into the target task's end status; after the first reference task reads the target task's end status, it stops starting the next data area traversal, thereby ensuring that the first common run time corresponds only to the target task's own memory access interval, and ensuring that the first reference task continues to perform memory access within this interval.

[0056] Specifically: During the process of obtaining the independent running time after the first joint run, after waiting for the first reference task to stop and confirming that the running status of the first reference task has changed to waiting, the target task is started separately to execute the same number of test loops, and the independent running time after the first joint run is obtained in the same way as the independent running time before the first joint run, using the same start and end times.

[0057] In this embodiment, the running time is obtained using the monotonic clock corresponding to CLOCK_MONOTONIC_RAW. All start and end times are converted to nanosecond integer values. The running time is equal to the nanosecond value at the end time minus the nanosecond value at the start time. Subsequently, only integer values ​​are used for size judgment, and no unit conversion or rounding is performed.

[0058] It should be noted that in this embodiment, 5 rounds of testing are performed for the first reference task. Each round is a re-execution of three consecutive stages: the target task running alone, the target task and the first reference task running together, and the target task running alone again. The 5 rounds are set based on the need to use an odd number of rounds to avoid the number of rounds that meet the requirements being equal to the number of rounds that do not meet the requirements, while reserving at least two rounds of test space that are different from the majority of results.

[0059] It should be noted that during the device registration phase, the test round number 5 and the number of test cycles, along with the first processor core number, the second processor core number, the first reference processor core number, the second reference processor core number, the first memory node number, the second memory node number, the data area capacity, and the address increment step size, are written into the registration test configuration record. Subsequent identity verification reads the corresponding fields according to the relationship established between the aforementioned current test configuration record and the registration test configuration record. Only when the values ​​of each field are equal to the corresponding values ​​saved during registration will the configuration be executed.

[0060] S22. Perform the same number of tests as in S21 for the second reference task. In each round, run the target task, run the target task and the second reference task together, and run the target task again. Record the independent running time before the second joint run, the second joint run time and the independent running time after the second joint run for the target task respectively.

[0061] Specifically: After completing 5 rounds of testing for the first reference task, keep the first processor core number, first memory node number, data area capacity, address increment step size, and number of test loops of the target task as taken from the configuration record of this test and do not modify them. Set the first reference task to a waiting state, and then change the co-running object from the first reference task to the second reference task. The remaining execution order, synchronization method, and timing method are all executed according to S21.

[0062] Specifically: In each round, the target task is run independently to obtain the second independent running time before joint running when both the first reference task and the second reference task are in a waiting state. Then, the target task and the second reference task are started together through the same synchronization barrier. The second reference task continuously and repeatedly accesses its own data area in the second memory node until the target task finishes writing, thereby obtaining the second joint running time. Then, the second reference task is confirmed to enter a waiting state and the target task is run independently again to obtain the second independent running time after joint running.

[0063] It should be noted that the only items that can change between S21 and S22 are the reference task identifiers that run together with the target task. The reference task identifier for S21 is the first reference task, and the reference task identifier for S22 is the second reference task. The target task processor core number, target task memory node number, data area capacity, address increment step, number of test loops, number of test rounds, and timing method are all read from the same test configuration record. Therefore, when the above configuration values ​​are equal item by item, it is considered that the two test groups use the same basic operating conditions.

[0064] S2 further includes: S23. In each round, determine whether the first common running time is simultaneously greater than the independent running time before the first common running and the independent running time after the first common running in the same round. When the number of rounds that satisfy the size relationship is greater than the number of rounds that do not satisfy the size relationship, record the first resource relationship as existing; otherwise, record the first resource relationship as unconfirmed. Specifically: The identity verification procedure reads the independent running time before the first joint operation, the first joint operation time, and the independent running time after the first joint operation in rounds numbered 1 to 5. First, it performs a numerical judgment that the first joint operation time is greater than the independent running time before the first joint operation, and then it performs a numerical judgment that the first joint operation time is greater than the independent running time after the first joint operation. Only when both judgment results are true is the first round judgment status of that round written as satisfied. If either judgment result is false or the two values ​​are equal, the first round judgment status of that round is written as unsatisfied.

[0065] Specifically: After all five rounds of processing are completed, the number of states that are satisfied in the first round is accumulated and recorded as the first satisfied round number. The first unsatisfied round number is obtained by subtracting the first satisfied round number from 5. When the first satisfied round number is greater than the first unsatisfied round number, the first resource relationship is recorded as existing. When the first satisfied round number is less than the first unsatisfied round number, the first resource relationship is recorded as unconfirmed.

[0066] In this embodiment, since the number of test rounds is fixed at 5, the first resource relationship is recorded as existing when the first satisfying round number is 3, 4 or 5, and the first resource relationship is recorded as unconfirmed when the first satisfying round number is 0, 1 or 2. There is no situation where the first satisfying round number is equal to the first unsatisfied round number.

[0067] For example, if the three time values ​​in the 5 rounds are 10.2ms, 13.8ms, 10.4ms, 10.3ms, 13.9ms, 10.2ms, 10.4ms, 14.1ms, 10.5ms, 10.1ms, 10.3ms, 10.2ms, and 10.3ms, 13.7ms, 10.4ms respectively, then the two size judgments in rounds 1, 2, 3, and 5 are all true. In round 4, because 10.3ms is not greater than two of the values ​​of 10.1ms and 10.2ms simultaneously, it is recorded as unsatisfied. Therefore, the first satisfied round number is 4, the first unsatisfied round number is 1, and the first resource relationship is recorded as existing.

[0068] It should be noted that the existence or unconfirmation of the first resource relationship is determined solely by the results of the above five rounds of integer time size judgments, without further judgments based on impact magnitude, percentage change, similarity, or human experience. Therefore, implementers can directly obtain a unique record status of the first resource relationship by using the three running time values ​​and the corresponding round numbers.

[0069] S24. In each round, determine whether the second common running time is simultaneously greater than the independent running time before the second common running and the independent running time after the second common running in the same round. When the number of rounds that satisfy the size relationship is greater than the number of rounds that do not satisfy the size relationship, record the second resource relationship as existing; otherwise, record the second resource relationship as unconfirmed, and write the recording status of the first resource relationship and the second resource relationship into the initial resource relationship record.

[0070] Specifically: Read the independent running time before the second joint operation, the second joint operation time, and the independent running time after the second joint operation according to the round numbers 1 to 5 respectively. Record the second round judgment status of the round as satisfied only when the second joint operation time is greater than the other two time values ​​in the same round. Otherwise, record it as unsatisfied. Then, accumulate the number of second round judgment statuses as satisfied to obtain the second satisfied round number.

[0071] Specifically: when the second round number is 3, 4 or 5, the second resource relationship is recorded as existing; when the second round number is 0, 1 or 2, the second resource relationship is recorded as unconfirmed. This process uses the same round number division rule as the first resource relationship, but uses the runtime data corresponding to the first reference task and the second reference task respectively, and does not use the two sets of test data interchangeably.

[0072] For example, if the target task is in the first execution position, and the second reference task has 5 rounds of testing, only the second round satisfies the condition that the second common running time is greater than the two independent running times. In this case, the second round satisfies the condition of 1 and the second resource relationship is recorded as unconfirmed. If the first round satisfies the condition of 4 at the same time, then this stage will obtain two record states: the first resource relationship exists and the second resource relationship is unconfirmed.

[0073] During data processing, the initial resource relationship record is fixed to include four items: the first processor core number, the first memory node number, the first resource relationship record status, and the second resource relationship record status. The first two items are used to indicate the first execution position actually used by the target task when the two resource relationship statuses are obtained, and the latter two items are stored using two enumeration values: existence or unconfirmation.

[0074] It should be noted that when determining whether an initial resource relationship record corresponds to the first execution position, the first processor core number and the first memory node number stored in it are read item by item and compared with the first processor core number and the first memory node number in the current test configuration record. If both numbers are equal, the initial resource relationship record is considered to correspond to the first execution position. If either number is not equal, the record is not used as the initial resource relationship record for the first execution position.

[0075] It should be noted that the second resource relationship record being unconfirmed only indicates that the second round of satisfaction has not reached 3 rounds. It does not translate into physical conclusions such as the second reference task and the target task not sharing hardware resources, or the second memory node being completely isolated from the first memory node. This ensures that the resource relationship record status corresponds to the actual execution time judgment method.

[0076] In this embodiment, by fixing the target task, the first reference task, and the second reference task to the corresponding processor core and memory node respectively, and using a multi-round time recording method of independent operation, joint operation, and then independent operation again to form the first resource relationship and the second resource relationship, the impact of local resource occupation in the current running state of the same server can be used as the basis for judgment. This reduces the interference of processor frequency fluctuations, background scheduling, and single-run anomalies on the resource relationship recording state. At the same time, it avoids judging the device identity based solely on static information such as device serial number and processor model. This allows the initial resource relationship record to more realistically reflect the resource organization state corresponding to the processor core and memory node in the current server, providing a stable and repeatable dynamic hardware behavior basis for subsequent device identity verification.

[0077] Example 3 Based on the data center physical server identity verification scenario set in Example 1 and the initial resource relationship record formed in Example 2, this example continues to describe the process of migrating the target task from the first execution position to the second execution position, re-acquiring the resource relationship, returning to the first execution position, and using the three execution stages to form the resource relationship change process. This example continues to use the first processor core number, second processor core number, first reference processor core number, second reference processor core number, first memory node number, second memory node number, data area capacity, address increment step size, number of test loops, number of test rounds, and timing method that have been written into the test configuration record in Example 2. The above configuration values ​​are not regenerated during the execution process.

[0078] It should be noted that the "remain unchanged" principle in this embodiment is determined by checking the configuration values ​​and actual operating status item by item. Whether the processor core has changed is determined by the processor core number in the current processor affinity mask of the task. Whether the memory node where the data is located has changed is determined by the NUMA node number of the physical page allocated to the task. Whether the task content and resource access operations have changed is determined by checking the data area capacity, address increment step size, number of test loops, and operation flag of incrementing and writing back after reading. Only when the actual values ​​of each item are equal to the corresponding values ​​in the test configuration record will the next processing step be entered.

[0079] Specifically: S3 includes: S31. Maintain the binding relationship between the first reference task and the first reference processor core, and the memory node where the data used by the first reference task is located, and maintain the binding relationship between the second reference task and the second reference processor core, and the memory node where the data used by the second reference task is located, unchanged. Specifically: After the target task completes all tests corresponding to the first execution position, both the first reference task and the second reference task are placed in a waiting state. The current processor affinity masks of the first reference task and the second reference task are read respectively. When the processor affinity mask of the first reference task contains only the first reference processor core number, the processor binding state of the first reference task is recorded as compliant. When the processor affinity mask of the second reference task contains only the second reference processor core number, the processor binding state of the second reference task is recorded as compliant.

[0080] Specifically: After completing the processor binding state reading, read the NUMA node numbers corresponding to all allocated physical pages in the data areas of the first reference task and the second reference task respectively. When the NUMA node numbers of all allocated pages in the first reference task are equal to the first memory node number, and the NUMA node numbers of all allocated pages in the second reference task are equal to the second memory node number, record the data position status of the two reference tasks as consistent.

[0081] It should be noted that S32 will only continue to be executed if the binding status of the first reference task processor, the binding status of the second reference task processor, and the data position status of both reference tasks are all recorded as compliant. If any status is not compliant, the migration test will be stopped and the obtained status records will be retained. The test data will not be used to form the resource relationship record after migration, thereby avoiding the reference task from continuing to participate in the resource relationship judgment before and after the target task migration after its own position has changed.

[0082] For example, in Embodiment 2, the first reference processor core number is 2, the second reference processor core number is 10, the first memory node number is 0, and the second memory node number is 1. When S31 is executed, the first reference task processor affinity mask is reread and required to contain only processor core 2. The second reference task processor affinity mask is reread and required to contain only processor core 10. At the same time, it is required that the query results of all allocated pages of the first reference task are all nodes 0 and the query results of all allocated pages of the second reference task are all nodes 1. When the four check results meet the above numbering relationship, S31 is completed.

[0083] S32. Unbind the target task from the first processor core, bind the target task to the second processor core, and migrate the physical page corresponding to the data used by the target task to the second memory node, keeping the task content and resource access operations of the target task unchanged, and migrate the target task from the first execution location to the second execution location.

[0084] Specifically: Before migrating the target task, wait for the current memory access loop of the target task to end and set the target task to a waiting state. During the period when the target task is not performing data read and write operations, read the starting address of the data area, the data area capacity, the address increment step, the number of test loops, and the current processor affinity mask of the target task, and save the above content as the target task state before migration. The processor affinity mask before migration should only contain the first processor core number.

[0085] Specifically: After the target task enters the waiting state, its original processor affinity setting is removed, and then the target task processor affinity mask is set to contain only the second processor core number. After the setting is completed, the target task processor affinity mask is read again. When the reading result contains only the second processor core number, the processor core migration action is considered to be completed. If the reading result still contains the first processor core number or contains processor core numbers other than the second processor core, the subsequent memory page migration process is not entered.

[0086] Specifically: After the processor core migration is completed, the target task virtual address region is not re-allocated, and the virtual starting address and region capacity of the target task data region remain unchanged. The target task data region is divided into contiguous virtual pages according to the system page size. The target NUMA node of each allocated physical page is set as the second memory node through the page migration operation, and then the physical page migration is performed.

[0087] In this embodiment, the move_pages interface of the Linux system can be used to move each physical page corresponding to the target task data area from the first memory node to the second memory node. After the page migration is completed, the NUMA node number of each physical page is queried again. When the query results for all allocated pages of the target task are equal to the second memory node number, the target task data location is recorded as the second memory node. If any page migration fails or the queried NUMA node number is not equal to the second memory node number, the target task page migration fails and the current migration test is terminated, and no post-migration resource relationship record is formed.

[0088] It should be noted that when using the physical page migration method, the original virtual address of the target task is not changed. Therefore, the target task still performs memory access operations from the starting address of the same virtual data area and in increments the same address size. Page migration only changes the actual NUMA physical memory location corresponding to the virtual page and does not rearrange the data access address of the target task.

[0089] Specifically: Before physical page migration, all valid bytes in the target task data area are read and the first data check value is calculated. After physical page migration is completed and all page query results are the second memory node, the same virtual address range is read again and the same check algorithm is used to calculate the second data check value. When the first data check value and the second data check value are equal, it is determined that the page migration process has not changed the data content of the target task.

[0090] In this embodiment, the first data check value and the second data check value can be calculated using the SHA-256 algorithm. Both check values ​​start from the first address of the target task data area and read the same byte range according to the data area capacity. When all bytes of the two SHA-256 results are equal bit by bit, the data content verification is recorded as passed. If any byte is different, the data content verification is recorded as failed and the migration result is stopped.

[0091] Specifically: After completing the processor core migration and physical page migration, read the current processor affinity mask, memory node number of each physical page, data area capacity, address increment step size, and test loop count of the target task. When the processor affinity mask only contains the second processor core number, all target task pages are located in the second memory node, and the data area capacity, address increment step size, and test loop count are equal to the values ​​saved before migration, record the current state of the target task as the second execution location.

[0092] It should be noted that the unchanged task content and resource access operation of the target task in this embodiment specifically means that the target task continues to use the processing order of data reading, reading value incrementing by 1, writing back to the original address, and accessing the data area to the end address according to the fixed address increment step size in Embodiment 2. At the same time, the three configuration values ​​of data area capacity, address increment step size and test loop count are all equal to the values ​​saved before migration, and are not judged based on similar operation mode or manual observation.

[0093] S3 further includes: S33. When the target task is located at the second execution position, perform multiple rounds of testing for the first reference task and the second reference task in the running order described in S21 and S22 of Embodiment 2, and re-record the first resource relationship and the second resource relationship in accordance with the size relationship described in S23 and S24 of Embodiment 2, and write the recording status of the re-recorded first resource relationship and the second resource relationship into the migrated resource relationship record. Specifically: After confirming that the target task is located in the second execution position, the first reference task continues to be bound to the first reference processor core and access the data area in the first memory node, and the second reference task continues to be bound to the second reference processor core and access the data area in the second memory node. The identity verification program reads the number of test loops, the number of test rounds, the data area capacity, the address increment step size and the timing method from the test configuration record, without re-executing the loop number calibration process in Example 2.

[0094] Specifically: Five rounds of testing are performed on the first reference task. In each round, three running times are obtained in the order of the target task running alone, the target task and the first reference task running together, and the target task running alone again. The same processing rules as in Example 2 are used to determine whether the running time of each round is greater than the two independent running times before and after the same round. The number of rounds that meet the requirements is counted. When the number of rounds that meet the requirements is 3, 4 or 5, the first resource relationship is recorded as existing again. When the number of rounds that meet the requirements is 0, 1 or 2, the first resource relationship is recorded as unconfirmed again.

[0095] Specifically: After completing 5 rounds of testing for the first reference task, restore the first reference task to the waiting state. Then, for the second reference task, perform 5 rounds of testing in the same order of running alone, running together, and running alone again. Use the same three-time value judgment rule to count the number of rounds that are satisfied. When the number of rounds satisfied is 3, 4, or 5, record the second resource relationship as existing. When the number of rounds satisfied is 0, 1, or 2, record the second resource relationship as unconfirmed.

[0096] It should be noted that during the period when the target task is in the second execution position, the only hardware locations that can change are the processor core number corresponding to the target task and the memory node number where the target task data is located. The target task changes from the first processor core and the first memory node to the second processor core and the second memory node. The processor core number and memory node number corresponding to the first reference task and the second reference task continue to maintain the values ​​recorded in Example 2.

[0097] For example, after the target task is migrated, 5 rounds of testing are performed on the first reference task. If the size relationship of S23 is satisfied in 1 round, the first resource relationship is re-recorded as unconfirmed. If 5 rounds of testing are performed on the second reference task. If the size relationship of S24 is satisfied in 4 rounds, the second resource relationship is re-recorded as existing. This results in two states under the second execution position: the first resource relationship is unconfirmed and the second resource relationship exists.

[0098] During data processing, the migrated resource relationship record will always contain four items: the second processor core number, the second memory node number, the first resource relationship record status, and the second resource relationship record status. The second processor core number and the second memory node number are used to indicate the actual second execution location of the target task when the corresponding resource relationship status is obtained.

[0099] S34. When the first resource relationship record in the initial resource relationship record exists and the second resource relationship record is unconfirmed, and the first resource relationship record in the migrated resource relationship record is unconfirmed and the second resource relationship record exists, the state transition from the existence of the first resource relationship to the unconfirmed state and the state transition from the unconfirmed state to the existence of the second resource relationship are recorded as the migration stage in the process of resource relationship change.

[0100] Specifically: The identity verification process first reads the status of the first resource relationship record and the status of the second resource relationship record in the initial resource relationship record, then reads the status of the first resource relationship record and the status of the second resource relationship record in the migrated resource relationship record, and performs four status judgments in a fixed order.

[0101] Specifically: The first step is to determine whether the first resource relationship in the initial resource relationship record is equal to "existing"; the second step is to determine whether the second resource relationship in the initial resource relationship record is equal to "unconfirmed"; the third step is to determine whether the first resource relationship in the post-migration resource relationship record is equal to "unconfirmed"; and the fourth step is to determine whether the second resource relationship in the post-migration resource relationship record is equal to "existing". Only when all four determinations are satisfied is the predetermined resource relationship state transition considered to have occurred during the migration phase.

[0102] In this embodiment, the migration phase records are sequentially written with the execution position before migration, the execution position after migration, the first resource relationship status before migration, the second resource relationship status before migration, the first resource relationship status after migration, and the second resource relationship status after migration. The execution position before migration is written with the first processor core number and the first memory node number, and the execution position after migration is written with the second processor core number and the second memory node number.

[0103] For example, if the initial resource relationship record shows that the first resource relationship exists and the second resource relationship is not confirmed, and the resource relationship record after migration shows that the first resource relationship is not confirmed and the second resource relationship exists, then the corresponding state sequence is recorded as Existence, Unconfirmed, Unconfirmed, Existence, and this state sequence is written into the migration stage of the resource relationship change process.

[0104] It should be noted that if any of the above four status judgments is not met, the actual status in the initial resource relationship record and the post-migration resource relationship record will still be retained, but the combination of statuses will not be recorded as a migration stage that satisfies the predetermined status transition. Subsequent identity verification will be carried out item by item according to the actual recorded status and the process of changes in the registered resource relationship.

[0105] S3 further includes: S35. Keeping the running positions of the first reference task and the second reference task unchanged, the target task is moved from the second execution position back to the first execution position. The running processes described in S21 and S22 of Embodiment 2 are re-executed for the first reference task and the second reference task respectively. The first resource relationship and the second resource relationship are re-recorded according to the size relationship described in S23 and S24 of Embodiment 2. The recording status of the re-recorded first resource relationship and the second resource relationship is written into the recovery resource relationship record. Specifically: After completing the test corresponding to the second execution position, first set the target task, the first reference task and the second reference task to the waiting state. Then, according to the processing method in S31, reread the processor affinity mask of the two reference tasks and the NUMA node number corresponding to all allocated pages. After confirming that the first reference task still corresponds to the first reference processor core and the first memory node, and the second reference task still corresponds to the second reference processor core and the second memory node, execute the target task return processing.

[0106] Specifically: the processor binding between the target task and the second processor core is removed, and the processor affinity mask of the target task is reset to contain only the first processor core number. Then, according to the physical page migration method in S32, all allocated pages corresponding to the target task data area are moved from the second memory node back to the first memory node. After the page migration is completed, the NUMA node number is queried page by page. If any page migration fails or the queried NUMA node number is not equal to the first memory node number, the migration failure is recorded and the current return test is terminated. No recovery resource relationship record is formed.

[0107] Specifically: when the target task processor affinity mask contains only the first processor core number, all allocated page query results of the target task are equal to the first memory node number, and the data area capacity, address increment step size, and test loop count are still equal to the corresponding values ​​in the current test configuration record, the target task is considered to have returned to the first execution position.

[0108] It should be noted that after the target task returns to the first execution position, the number of test loops is not recalculated, the data area capacity is not changed, the address increment step is not changed, and the positions of the first and second reference tasks are not changed. Therefore, the only items that can be changed between the return phase and the initial phase are the execution order in which the target task has passed through the second execution position and returned to the first execution position.

[0109] Specifically: After the target task returns to the first execution position, five rounds of testing are performed again for the first reference task and the second reference task. In each round, the order of running alone, running together, and running alone again is adopted, and the number of the first and second satisfying rounds are counted according to the three time size relationships in Example 2. Then, the first resource relationship and the second resource relationship are obtained again according to the rule of recording 3, 4, or 5 rounds as existing and 0, 1, or 2 rounds as unconfirmed.

[0110] During data processing, the resource relationship record is fixed to include the first processor core number, the first memory node number, the first resource relationship record status in the return phase, and the second resource relationship record status in the return phase. The first processor core number and the first memory node number are used to prove that the set of resource relationship statuses were obtained after the target task has returned to the first execution position.

[0111] S36. When the recording status of the first resource relationship and the second resource relationship in the restored resource relationship record are the same as the corresponding recording status in the initial resource relationship record, and the first resource relationship record in the initial resource relationship record is existing and the second resource relationship record is unconfirmed, the state transition of restoring the first resource relationship to existing and the second resource relationship to unconfirmed is recorded as the recovery stage in the resource relationship change process.

[0112] Specifically: sequentially read the status of the first and second resource relationship records in the initial resource relationship record, as well as the status of the first resource relationship record in the return phase and the status of the second resource relationship record in the recovery resource relationship record. First, determine whether the initial resource relationship record indicates that the first resource relationship exists and the second resource relationship is not confirmed. Then, compare the status of the first resource relationship record in the return phase with the status of the first resource relationship record in the initial resource relationship record, and compare the status of the second resource relationship record in the return phase with the status of the second resource relationship record in the initial resource relationship record. If both comparison results are equal, record this return phase as meeting the recovery conditions.

[0113] Specifically: During the recovery phase, the execution position before return, the execution position after return, the first resource relationship status after return, and the second resource relationship status after return are fixedly written. The execution position before return corresponds to the second processor core number and the second memory node number, and the execution position after return corresponds to the first processor core number and the first memory node number.

[0114] For example, after the target task returns from the second execution position to the first execution position, if the first reference task is satisfied in 4 out of 5 rounds of testing and the second reference task is satisfied in 1 out of 5 rounds of testing, then the first resource relationship is re-recorded as existing and the second resource relationship is re-recorded as unconfirmed, which corresponds to the two resource relationship states in the initial stage. At this time, the recovery stage is recorded.

[0115] It should be noted that the recovery described here is determined only based on the two resource relationship enumeration states. That is, the resource relationship state is considered to be restored when the first resource relationship exists in both the initial stage and the return stage and the second resource relationship is unconfirmed. It does not require that the specific running time values ​​obtained in the two stages be equal, nor does it use the difference in running time being less than a certain percentage as an additional condition.

[0116] S4 includes: S41. Read the initial resource relationship record, the migrated resource relationship record, and the restored resource relationship record in sequence according to the order in which the target task is located at the first execution position, migrates to the second execution position, and returns to the first execution position; Specifically: The identity verification process is set with stage number 1, stage number 2 and stage number 3. Stage number 1 corresponds to the initial resource relationship record obtained when the target task is first in the first execution position. Stage number 2 corresponds to the post-migration resource relationship record obtained after the target task migrates to the second execution position. Stage number 3 corresponds to the restored resource relationship record obtained after the target task returns to the first execution position.

[0117] Specifically: when reading stage number 1, the first processor core number, the first memory node number, the first resource relationship record status, and the second resource relationship record status are obtained; when reading stage number 2, the second processor core number, the second memory node number, the first resource relationship record status, and the second resource relationship record status are obtained; when reading stage number 3, the first processor core number, the first memory node number, the first resource relationship record status of the return stage, and the second resource relationship record status of the return stage are obtained again.

[0118] It should be noted that the three stages are generated sequentially according to the actual completion time. Stage number 2 can only be generated after stage number 1 has been generated, and stage number 3 can only be generated after stage number 2 has been generated. If any preceding stage is missing, the subsequent complete resource relationship change process will not be generated.

[0119] S42. Write the record status of the first resource relationship and the second resource relationship in the initial resource relationship record, the record status of the first resource relationship and the second resource relationship in the migrated resource relationship record, and the record status of the first resource relationship and the second resource relationship in the restored resource relationship record into the resource relationship change process in the order of change of the corresponding execution position.

[0120] Specifically: The resource relationship change process is saved using three sequential record items. The first sequential record item contains stage number 1, first processor core number, first memory node number, first resource relationship record status and second resource relationship record status. The second sequential record item contains stage number 2, second processor core number, second memory node number, first resource relationship record status and second resource relationship record status. The third sequential record item contains stage number 3, first processor core number, first memory node number, return stage first resource relationship record status and return stage second resource relationship record status.

[0121] For example, the process of resource relationship changes that are formed normally can be recorded as follows: Stage 1 corresponds to the first execution position, the first resource relationship exists, and the second resource relationship is not confirmed; Stage 2 corresponds to the second execution position, the first resource relationship is not confirmed, and the second resource relationship exists; Stage 3 corresponds to the first execution position, the first resource relationship exists, and the second resource relationship is not confirmed. The three stages are saved in a fixed numbered order of 1, 2, and 3, and are not reordered according to the running time or the status of the resource relationship.

[0122] S4 further includes: S43. During the equipment registration phase, the target task execution position in the registered equipment is changed in the order of the first execution position, the second execution position, and the first execution position. The recording status of the first resource relationship and the second resource relationship corresponding to each execution position is recorded, and the registration resource relationship change process is formed in the order of execution position change. Specifically: When the server completes identity registration for the first time, it takes the current server as the registration device and completes the first execution position test, the second execution position test and the return to the first execution position test in sequence according to the processing process of S31 to S42 of this embodiment, and obtains the processor core number, memory node number, first resource relationship status and second resource relationship status corresponding to the three stages.

[0123] Specifically, the process of registering resource relationship changes also employs three sequentially saved stages: Stage 1 saves the first execution position of the registered device and the corresponding two resource relationship states; Stage 2 saves the second execution position of the registered device and the corresponding two resource relationship states; and Stage 3 saves the two resource relationship states after the registered device returns to the first execution position. Simultaneously, the first processor core number, second processor core number, first reference processor core number, second reference processor core number, first memory node number, second memory node number, data area capacity, address increment step size, test loop count, and test round count used during device registration are written into the registration test configuration record. The process of registering resource relationship changes and the registration test configuration record are then stored in the memory of the data center verification terminal.

[0124] It should be noted that the data center verification terminal sets write permissions for the process of changes in the registered resource relationships and the registered test configuration records. Only the device registration program performs write or update operations after completing the registration process. The server to be verified only receives test tasks and returns the current test data. It does not have write permissions to modify the above registration records, thereby preventing the device to be verified from changing the registration benchmark used for subsequent identity verification.

[0125] It should be noted that the subsequent authentication process, which follows the same execution position change order as the device registration phase, specifically means first reading the first processor core number and the first memory node number in the registration test configuration record as the first stage execution position, then reading the second processor core number and the second memory node number in the registration test configuration record as the second stage execution position, and finally using the first processor core number and the first memory node number in the registration test configuration record again as the third stage execution position, thus forming a fixed change order of first execution position, second execution position, and first execution position.

[0126] S44. During the authentication phase, the resource relationship change process of the current computer hardware device is obtained in the same execution position change order as the device registration phase. The record status of the first resource relationship and the second resource relationship at the corresponding execution position during the resource relationship change process is compared stage by stage with the record status of the first resource relationship and the second resource relationship at the corresponding execution position during the registered resource relationship change process. When the record status of the first resource relationship and the second resource relationship at each stage is consistent, the device authentication result is recorded as authentication passed; otherwise, the device authentication result is recorded as authentication failed.

[0127] Specifically: When the current computer hardware device begins authentication, it first reads the registration test configuration record and establishes the target task and the running positions of the two reference tasks according to the first processor core number, the second processor core number, the first reference processor core number, the second reference processor core number, the first memory node number and the second memory node number stored therein. If any registered processor core does not exist, is offline, or any registered memory node does not exist, the device authentication result is directly recorded as authentication failure.

[0128] Specifically: After completing the three-stage test of the current device, read the current resource relationship change process and register the resource relationship change process item by item according to stage number 1, stage number 2 and stage number 3. In each stage, compare the first resource relationship record status and the second resource relationship record status. When the character values ​​or internal status codes of the two enumerated statuses are equal, record the comparison result of the corresponding fields as equal; otherwise, record it as unequal.

[0129] Specifically: The three stages generate a total of six resource relationship status comparison results, with two corresponding to stage 1, two to stage 2, and two to stage 3. When all six comparison results are recorded as equal, the device authentication result is recorded as successful. If any of the six comparison results are recorded as unequal, the device authentication result is recorded as unsuccessful.

[0130] For example, if the three stages of the registered resource relationship change process are existence, unconfirmed, existence, and unconfirmed, and the three stages of the current device are also existence, unconfirmed, existence, and unconfirmed, then the six resource relationship states are equal one by one, so the device authentication result is recorded as verification passed. If the current device is recorded as existence in the second stage, then the first resource relationship in the second stage is not equal to the registered state. Even if the other five are equal, the device authentication result is still recorded as verification failed.

[0131] It should be noted that the states described in this embodiment are all consistent, and the determination is made by comparing the results of the above six enumerated states one by one. It is not based on overall similarity, allowable error ratio, or manual observation. At the same time, whether the static identifiers such as server processor model and device serial number are the same does not replace the verification results of the above resource relationship change process. Thus, the device identity verification is completed by using the actual resource relationship states obtained before and after the change of the target task execution location.

[0132] In this embodiment, by keeping the running positions of the first and second reference tasks unchanged, the target task is migrated only in the order of the first execution position, the second execution position, and returning to the first execution position. Initial resource relationship records, migration resource relationship records, and restored resource relationship records are formed in sequence. This can verify whether the first and second resource relationships have changed accordingly with the execution position of the target task and have been restored after returning. This reduces the possibility of a single accidental resource contention or temporary system load change being mistaken for a device identity feature. Furthermore, by verifying the step-by-step correspondence between the resource relationship change process and the registered resource relationship change process, the ability to identify changes in the actual hardware resource organization status is improved in scenarios such as data center server reconnection, hardware replacement verification, and device anti-counterfeiting.

[0133] Example 4 A computer hardware device authentication and anti-counterfeiting system, please refer to Figure 2 It includes a processor and a memory. The memory is used to store program instructions, the process of changes in the registration resource relationship corresponding to the registration device, and the registration test configuration record. When the processor executes the program instructions, it runs the execution location configuration module, the initial resource relationship acquisition module, the migration resource relationship acquisition module, and the authentication module.

[0134] Specifically: The execution location configuration module reads the processor core information and memory node information, determines the first execution location and the second execution location corresponding to different memory nodes according to the processing procedures of S11 and S12 in Embodiment 2, and establishes the fixed running locations of the first reference task and the second reference task. The processor writes the determination results into the current test configuration record corresponding to the current test.

[0135] Specifically: When the target task is located at the first execution position, the initial resource relationship acquisition module obtains the first resource relationship and the second resource relationship according to the processing steps S21 to S24 in Embodiment 2 and forms an initial resource relationship record; the migration resource relationship acquisition module migrates the target task to the second execution position according to the processing steps S31 to S33 in Embodiment 3, keeping the two reference task running positions unchanged, and forms a migration resource relationship record.

[0136] Specifically: The authentication module forms a resource relationship change process according to the processing steps S34 to S44 in embodiment 3, reads the registration resource relationship change process and registration test configuration record corresponding to the registration device from the memory, compares the first resource relationship and the second resource relationship record status in the three stages item by item, and forms a verified device authentication result when all six status comparison results are equal, and forms a verified device authentication result when any status comparison result is not equal.

[0137] It should be noted that the processor can be a general-purpose processor in a data center verification server, and the memory can include volatile memory and non-volatile memory. The program instructions are loaded into the volatile memory during runtime, and the registration resource relationship change process and registration test configuration record corresponding to the registration device are stored in a non-volatile storage area with write permission control. The server to be verified does not have write permission to modify the registration resource relationship change process and the registration test configuration record.

[0138] In this embodiment, the four modules are called by the processor in the order of execution location configuration, initial resource relationship acquisition, resource relationship acquisition after target task migration, and identity verification. The modules pass processing results through the current test configuration record, initial resource relationship record, post-migration resource relationship record, and resource relationship change process, so that the system structure corresponds to the method processing process of Embodiments 1 to 3.

[0139] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended technical solutions and their equivalents.

Claims

1. A method for authenticating and preventing counterfeiting of computer hardware devices, characterized in that, Includes the following steps: S1. Obtain processor core information and memory node information in computer hardware devices, determine the first execution location and the second execution location corresponding to different memory nodes based on the processor core information and the memory node information, and determine the first reference task and the second reference task corresponding to the target task. S2. Run the target task at the first execution position, obtain the first resource relationship between the target task and the first reference task and the second resource relationship between the target task and the second reference task, and obtain an initial resource relationship record; S3. Keeping the execution content of the target task, the first reference task, and the second reference task unchanged, the target task is migrated from the first execution position to the second execution position, and the first resource relationship between the target task and the first reference task and the second resource relationship between the target task and the second reference task are re-acquired to obtain the resource relationship record after migration; S4. Determine the resource relationship change process corresponding to the change in the target task execution location based on the initial resource relationship record and the post-migration resource relationship record, and match the resource relationship change process with the registered resource relationship change process corresponding to the registered device to obtain the device authentication result.

2. The method for authentication and anti-counterfeiting of computer hardware devices according to claim 1, characterized in that, S1 includes: S11. Read the processor core number and the memory node number corresponding to each processor core from the processor core information, and read the memory node number from the memory node information. According to the arrangement order of the memory node numbers, select the first two memory nodes from the memory nodes that each contain at least two online processor cores and determine them as the first memory node and the second memory node in sequence. According to the arrangement order of the processor core numbers, select the first two online processor cores from the processor cores corresponding to the first memory node and determine them as the first processor core and the first reference processor core in sequence. Select the first two online processor cores from the processor cores corresponding to the second memory node and determine them as the second processor core and the second reference processor core in sequence. S12. Bind the target task to the first processor core and allocate the data used by the target task to the first memory node, define the first processor core and the first memory node together as the first execution location, define the second processor core and the second memory node together as the second execution location, bind the first reference task to the first reference processor core and allocate the data used by the first reference task to the first memory node, bind the second reference task to the second reference processor core and allocate the data used by the second reference task to the second memory node.

3. The method for authentication and anti-counterfeiting of computer hardware devices according to claim 2, characterized in that, S2 includes: S21. When the target task is located at the first execution position, perform multiple rounds of testing for the first reference task. In each round, run the target task, run the target task and the first reference task together, and run the target task again. Record the independent running time before the first joint running, the first joint running time and the independent running time after the first joint running for the target task respectively. S22. Perform the same number of tests as in S21 for the second reference task. In each round, run the target task, run the target task and the second reference task together, and run the target task again. Record the independent running time before the second joint run, the second joint run time and the independent running time after the second joint run for the target task respectively.

4. The method for authentication and anti-counterfeiting of computer hardware devices according to claim 3, characterized in that, S2 further includes: S23. In each round, determine whether the first common running time is simultaneously greater than the independent running time before the first common running and the independent running time after the first common running in the same round. When the number of rounds that satisfy the size relationship is greater than the number of rounds that do not satisfy the size relationship, record the first resource relationship as existing; otherwise, record the first resource relationship as unconfirmed. S24. In each round, determine whether the second common running time is simultaneously greater than the independent running time before the second common running and the independent running time after the second common running in the same round. When the number of rounds that satisfy the size relationship is greater than the number of rounds that do not satisfy the size relationship, record the second resource relationship as existing; otherwise, record the second resource relationship as unconfirmed, and write the recording status of the first resource relationship and the second resource relationship into the initial resource relationship record.

5. The method for authentication and anti-counterfeiting of computer hardware devices according to claim 4, characterized in that, S3 includes: S31. Maintain the binding relationship between the first reference task and the first reference processor core, and the memory node where the data used by the first reference task is located, and maintain the binding relationship between the second reference task and the second reference processor core, and the memory node where the data used by the second reference task is located, unchanged. S32. Unbind the target task from the first processor core, bind the target task to the second processor core, and migrate the physical page corresponding to the data used by the target task to the second memory node, keeping the task content and resource access operations of the target task unchanged, and migrate the target task from the first execution location to the second execution location.

6. The method for authentication and anti-counterfeiting of computer hardware devices according to claim 5, characterized in that, S3 further includes: S33. When the target task is located at the second execution position, perform multiple rounds of testing for the first reference task and the second reference task in the running order defined by S21 and S22 above, and re-record the first resource relationship and the second resource relationship according to the size relationship defined by S23 and S24 above, and write the recording status of the re-recorded first resource relationship and the second resource relationship into the migrated resource relationship record. S34. When the first resource relationship record in the initial resource relationship record exists and the second resource relationship record is unconfirmed, and the first resource relationship record in the migrated resource relationship record is unconfirmed and the second resource relationship record exists, the state transition from the existence of the first resource relationship to the unconfirmed state and the state transition from the unconfirmed state to the existence of the second resource relationship are recorded as the migration stage in the process of resource relationship change.

7. The method for authentication and anti-counterfeiting of computer hardware devices according to claim 6, characterized in that, S3 further includes: S35. Keep the running positions of the first reference task and the second reference task unchanged, move the target task from the second execution position back to the first execution position, re-execute the running process defined by S21 and S22 for the first reference task and the second reference task respectively, and re-record the first resource relationship and the second resource relationship according to the size relationship defined by S23 and S24, and write the recording status of the re-recorded first resource relationship and the second resource relationship into the recovery resource relationship record; S36. When the recording status of the first resource relationship and the second resource relationship in the restored resource relationship record are the same as the corresponding recording status in the initial resource relationship record, and the first resource relationship record in the initial resource relationship record is existing and the second resource relationship record is unconfirmed, the state transition of restoring the first resource relationship to existing and the second resource relationship to unconfirmed is recorded as the recovery stage in the resource relationship change process.

8. The method for authentication and anti-counterfeiting of computer hardware devices according to claim 7, characterized in that, S4 includes: S41. Read the initial resource relationship record, the migrated resource relationship record, and the restored resource relationship record in sequence according to the order in which the target task is located at the first execution position, migrates to the second execution position, and returns to the first execution position; S42. Write the record status of the first resource relationship and the second resource relationship in the initial resource relationship record, the record status of the first resource relationship and the second resource relationship in the migrated resource relationship record, and the record status of the first resource relationship and the second resource relationship in the restored resource relationship record into the resource relationship change process in the order of change of the corresponding execution position.

9. A method for authenticating and preventing counterfeiting of computer hardware devices according to claim 8, characterized in that, S4 further includes: S43. During the equipment registration phase, the target task execution position in the registered equipment is changed in the order of the first execution position, the second execution position, and the first execution position. The recording status of the first resource relationship and the second resource relationship corresponding to each execution position is recorded, and the registration resource relationship change process is formed in the order of execution position change. S44. During the authentication phase, the resource relationship change process of the current computer hardware device is obtained in the same execution position change order as the device registration phase. The record status of the first resource relationship and the second resource relationship at the corresponding execution position during the resource relationship change process is compared stage by stage with the record status of the first resource relationship and the second resource relationship at the corresponding execution position during the registered resource relationship change process. When the record status of the first resource relationship and the second resource relationship at each stage is consistent, the device authentication result is recorded as authentication passed; otherwise, the device authentication result is recorded as authentication failed.

10. A computer hardware device authentication and anti-counterfeiting system, characterized in that, It includes a processor and a memory. The memory is used to store program instructions, the process of changes in the registration resource relationships corresponding to the registration device, and registration test configuration records. The processor is used to execute the program instructions and run the following modules: An execution location configuration module is used to obtain processor core information and memory node information of computer hardware devices, determine a first execution location and a second execution location corresponding to different memory nodes based on the processor core information and the memory node information, and determine a first reference task and a second reference task corresponding to the target task. The initial resource relationship acquisition module is used to acquire the first resource relationship between the target task and the first reference task and the second resource relationship between the target task and the second reference task when the target task is running at the first execution position, and form an initial resource relationship record; The migration resource relationship acquisition module is used to keep the running content of the target task, the first reference task and the second reference task unchanged, migrate the target task from the first execution position to the second execution position, reacquire the first resource relationship and the second resource relationship, and form a migration resource relationship record; The authentication module is used to form a resource relationship change process based on the initial resource relationship record and the migrated resource relationship record, read the registered resource relationship change process corresponding to the registered device from the memory, compare the resource relationship change process with the registered resource relationship change process corresponding to the registered device stage by stage, and form a device authentication result based on the comparison result.