Gpu memory security detection method and device, electronic equipment and readable storage medium

Abstract

This application discloses a GPU memory security detection method, apparatus, electronic device, and readable storage medium, relating to the field of GPU memory technology. The method includes, in response to a memory allocation request in a GPU program, allocating a memory buffer with header metadata and storing precise boundary information of the memory buffer in the header metadata; generating a pointer corresponding to the memory buffer, wherein a metadata tag is embedded in the high-order bits of the pointer's virtual address, the metadata tag including an alignment tag for locating the header metadata; in response to a memory access instruction in the GPU program, locating the header metadata according to the alignment tag and reading the precise boundary information; performing space out-of-bounds checks on memory accesses based on the precise boundary information; and performing time corruption detection in response to a memory buffer release operation. This application improves the deployability of GPU memory security detection and enhances detection capabilities.

Description

Technical Field

[0001] This application relates to the field of GPU memory technology, and in particular to a GPU memory security detection method, apparatus, electronic device and readable storage medium. Background Technology

[0002] In related technologies, GPU memory safety detection solutions are mainly divided into two categories: hardware and software. Hardware solutions achieve low-overhead detection by customizing hardware or embedding precise boundary information in pointers, but they rely on special hardware support and cannot be deployed on commercial GPUs. Software solutions, for example, canary-based tools can only detect linear overflows and are powerless against non-linear overflows. Furthermore, similar solutions on CPUs are mainly designed for serial or low-parallelism environments, failing to fully utilize the high concurrency characteristics of GPUs and lacking mechanisms to address common pointer arithmetic errors in GPUs. Summary of the Invention

[0003] The purpose of this application is to at least solve one of the technical problems existing in the prior art, and to provide a GPU memory security detection method, apparatus, electronic device and readable storage medium, which aims to improve the deployability of GPU memory security detection and enhance detection capabilities.

[0004] In a first aspect, embodiments of this application provide a GPU memory security detection method, including:

[0005] In response to a memory allocation request in a GPU program, a memory buffer with header metadata is allocated, and the precise boundary information of the memory buffer is stored in the header metadata;

[0006] A pointer corresponding to the memory buffer is generated, wherein a metadata tag is embedded in the high-order bits of the virtual address of the pointer, and the metadata tag includes an alignment tag for locating the header metadata;

[0007] In response to memory access instructions in the GPU program, the header metadata is located based on the alignment tag and the precise boundary information is read;

[0008] The memory access is checked for spatial out-of-bounds based on the precise boundary information, and temporal corruption is detected in response to the release operation of the memory buffer.

[0009] The technical solution according to the embodiments of this application has at least the following beneficial effects: Based on software implementation, it utilizes existing MMU hardware of commercial GPUs and the open-source LLVM toolchain, eliminating the need for customized hardware or reliance on proprietary toolchains, thus solving the deployability problem; it employs an in-band precise boundary mechanism, storing the actual allocation size in the buffer header and encoding the alignment tag for locating the precise boundary in the high-order bits of the pointer's virtual address. During each memory access, the header is quickly located and the precise boundary is read using the alignment tag, thereby achieving accurate detection of linear / non-linear out-of-bounds errors of arbitrary offsets (including internal out-of-bounds errors within the aligned precise boundary), compensating for the blind spots of related software solutions. Simultaneously, the release operation clears the precise boundary in the header to zero, ensuring that any subsequent access is intercepted due to the failure of the precise boundary check, effectively preventing time corruption.

[0010] According to some embodiments of this application, the time corruption detection in response to the release operation of the memory buffer includes:

[0011] In response to the release operation of the memory buffer, the precise boundary information in the header metadata is invalidated;

[0012] In response to an access instruction to a freed memory buffer, detect post-free reuse errors based on precise invalidation boundary information.

[0013] According to some embodiments of this application, the metadata tag further includes a pointer type bit and an identity identifier; the pointer type bit is used to distinguish between pointers to global memory and local memory;

[0014] For pointers to local memory, the identifier is the stack period, which includes stack depth and generation, used to uniquely identify the lifecycle of a stack frame; for pointers to global memory, the identifier is virtual address randomization information implemented by configuring the GPU memory management unit page table.

[0015] According to some embodiments of this application, locating the header metadata based on the alignment tag includes:

[0016] Based on the number of bits indicated by the alignment tag, the low-order bits of the pointer are cleared to obtain the address of the header metadata;

[0017] Memory access broadcasting combines multiple threads' header metadata read requests for the same memory buffer into a single memory request.

[0018] According to some embodiments of this application, it also includes:

[0019] In response to pointer arithmetic operations, perform metadata integrity verification on the resulting pointer, including:

[0020] Calculate the XOR value between the original pointer and the result pointer;

[0021] If the XOR value is non-zero in the high-order region defined by the alignment label, then the result pointer is marked as invalid;

[0022] During memory access checks, if a pointer is detected as invalid, a pointer arithmetic error is reported.

[0023] According to some embodiments of this application, invalidating the precise boundary information in the header metadata includes:

[0024] Set the precise boundary information to zero;

[0025] For local memory, a unique stack era identifier is assigned to each stack frame, and the consistency between the stack era in the pointer and the current thread's stack era is verified during dereference. For global memory, random values ​​are introduced into specific bits of the virtual address through the page table configuration of the memory management unit during memory allocation.

[0026] According to some embodiments of this application, it also includes:

[0027] The method can eliminate duplicate memory access checks, merge adjacent memory access checks, or move memory access checks based on inductive variables within a loop to outside the loop.

[0028] Secondly, embodiments of this application provide an operation control device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement the GPU memory security detection method described in the first aspect.

[0029] Thirdly, embodiments of this application provide an electronic device including the operation control device described in the second aspect above.

[0030] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which are used to cause a computer to execute the GPU memory security detection method as described in the first aspect above.

[0031] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0032] The accompanying drawings are used to provide a further understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0033] The present application will be further described below with reference to the accompanying drawings and embodiments;

[0034] Figure 1 This is a flowchart of a GPU memory security detection method provided in one embodiment of this application;

[0035] Figure 2 This is a flowchart of a GPU memory security detection method provided in another embodiment of this application;

[0036] Figure 3 This is a flowchart of a GPU memory security detection method provided in another embodiment of this application;

[0037] Figure 4 This is a flowchart of a GPU memory security detection method provided in another embodiment of this application;

[0038] Figure 5 This is a flowchart of a GPU memory security detection method provided in another embodiment of this application;

[0039] Figure 6 This is a flowchart of a GPU memory security detection method provided in another embodiment of this application;

[0040] Figure 7 This is a schematic diagram of an operation control device for performing a GPU memory security detection method according to an embodiment of this application. Detailed Implementation

[0041] This section will describe in detail the specific embodiments of this application. Preferred embodiments of this application are shown in the accompanying drawings. The purpose of the drawings is to supplement the textual description with graphics, so that people can intuitively and vividly understand each technical feature and the overall technical solution of this application, but they should not be construed as limiting the scope of protection of this application.

[0042] In the description of this application, it should be understood that the orientation descriptions, such as up, down, front, back, left, right, etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0043] In the description of this application, "several" means one or more, "more than" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is for the purpose of distinguishing technical features only and should not be construed as indicating or implying relative importance, nor as implying or specifying the number of indicated technical features, nor as implying or specifying the sequential relationship of the indicated technical features.

[0044] In the description of this application, unless otherwise expressly defined, terms such as "setup," "installation," and "connection" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this application in conjunction with the specific content of the technical solution.

[0045] In some cases, with the widespread application of GPUs in fields such as machine learning and scientific computing, the inherent memory insecurity of their programming models leads to frequent memory corruption errors, affecting program stability and potentially being exploited to launch attacks or compromise the accuracy of machine learning models.

[0046] GPU memory security solutions in related technologies are mainly divided into two categories: hardware and software.

[0047] Hardware solution:

[0048] Methods such as GPUShield, IMT, LMI, and GPUArmor implement access checks by customizing hardware or embedding precise boundary information in pointers. They typically have low overhead but rely on special hardware support and cannot be deployed on existing commercial GPUs.

[0049] Software solution:

[0050] GMOD and clArmor: They use canary value protection, placing guard values ​​around the buffer, but they can only detect linear overflows and will miss non-linear overflows. Furthermore, they fail if the overflow skips the guard value. Some schemes use 2^n alignment markers, which cannot detect internal out-of-bounds accesses within or outside the precisely aligned boundary.

[0051] NVIDIA compute-sanitizer: Uses out-of-band shadow memory to track all allocations, but has a huge performance overhead and is not suitable for practical deployment.

[0052] cuCatch: It uses pointer markers and a two-level structure to query the exact boundaries of the buffer. Its tags may be contaminated or tampered with by arithmetic overflows. Moreover, it is based on NVIDIA's proprietary toolchain and is not publicly available, so it cannot be deployed.

[0053] Similar tasks on CPUs (RSan uses in-band metadata) are primarily designed for serial or low-parallelism environments, failing to fully utilize the high-parallelism architecture of GPUs and lacking effective mechanisms to address common pointer arithmetic overflow issues on GPUs. Regarding time corruption, memory may be reallocated after being freed. If the metadata locations of the old and new objects are identical or their tags conflict, the old pointer may incorrectly access the data of the new object, resulting in missed detections. Furthermore, common pointer arithmetic errors in GPU code can corrupt the tags or metadata indexes embedded in pointers, causing the detection mechanism to fail.

[0054] Based on this, the GPU memory safety detection method provided in this application solves the problem that existing technologies cannot achieve comprehensive memory protection on commercial GPUs. By constructing a hybrid metadata system, the precise boundary information of the memory buffer is stored in the buffer header in an in-band manner. At the same time, the alignment tag used to quickly locate the header is encoded into the high bits of the pointer's virtual address. The GPU's unique memory access broadcast mechanism is used to optimize metadata retrieval. Then, during each memory access, the precise boundary information of the header is read to perform space out-of-bounds checks, and timing errors are detected when memory is released. Thus, runtime memory safety protection for GPU programs is provided without relying on any hardware modifications and using only open source toolchains.

[0055] The various embodiments of the GPU memory security detection method of this application will be further described below with reference to the accompanying drawings.

[0056] like Figure 1 As shown, Figure 1 This is a flowchart of a GPU memory security detection method provided in one embodiment of this application. The GPU memory security detection method may include, but is not limited to, steps S110 to S140.

[0057] Step S110: In response to a memory allocation request in the GPU program, allocate a memory buffer with header metadata and store the precise boundary information of the memory buffer in the header metadata;

[0058] Step S120: Generate a pointer corresponding to the memory buffer. The high-order bits of the pointer's virtual address contain a metadata tag, which includes an alignment tag for locating the header metadata.

[0059] Step S130: In response to memory access instructions in the GPU program, locate the header metadata based on the alignment tag and read the precise boundary information;

[0060] Step S140: Perform space out-of-bounds checks on memory accesses based on precise boundary information, and perform time corruption detection in response to memory buffer release operations.

[0061] For example, when a GPU program initiates a memory allocation request, additional operations can be performed at the underlying memory allocator level by intercepting cudaMalloc or similar API calls during the CUDA runtime. When a user program requests a memory block of size S bytes, the system does not simply allocate exactly S bytes of space, but rather allocates a slightly larger block of S plus a preset header metadata length. In one embodiment, the header metadata can be set to a fixed 8 bytes to store the boundary information of the memory buffer. Here, the precise boundary refers to the logical size S actually requested by the user program, not the physical space actually occupied by the memory allocator for alignment purposes. For example, when the user requests 100 bytes, the allocator may allocate according to 128-byte alignment, but the boundary value stored in the header metadata is still 100, serving as the sole basis for verifying the legitimacy of all subsequent memory accesses.

[0062] The specific storage method for header metadata can be simple direct storage, that is, writing 8 bytes consecutively at the starting address of the memory block to represent the boundary value. To enhance security and prevent malicious tampering, the boundary value can also be lightly encrypted, for example, by performing an XOR operation with a randomly generated key and then storing it. The key can be stored in the GPU's register. Since the register cannot be directly accessed by the user program during kernel execution, the confidentiality of the metadata itself is guaranteed.

[0063] After memory allocation and header metadata are filled, a pointer to the buffer can be generated and returned to the user program. The high-order bits of the pointer's virtual address embed metadata tags, including alignment tags. Here, the value of the alignment tag originates from the alignment rules used by the memory allocator. For example, if the allocator aligns to 2^n bytes, the alignment tag is n. The alignment tag is encoded into specific high-order bits of the pointer's virtual address, utilizing the high-order portions of the 64-bit virtual address that are not used for addressing. For instance, in the x86-64 architecture, the lower 48 bits of the virtual address are used for addressing, and the higher 16 bits can be used to store metadata, from which several bits are extracted to store the alignment tag. Understandably, the encoding method of storing the high-order bits does not affect the normal dereferencing of the pointer, because during address translation, the MMU only uses the lower-order portions for physical address mapping; the high-order bits are ignored or reserved before address translation, thus ensuring the safe carrying of information. Therefore, the virtual address of any pointer pointing to a location within the buffer carries the buffer's alignment tag, providing a zero-cost mechanism for quickly locating the buffer's head. Given a pointer `p` and its extracted alignment tag `n`, simply clearing the lower `n` bits of `p` yields the starting address of the head metadata. This is because, according to the alignment rules, the buffer's head must lie on a 2^n alignment boundary, and the user data area pointed to by pointer `p` is located after the head. Therefore, the lower `n` bits of `p` precisely reflect its offset relative to the head; clearing them backtracks to the head. In this way, through the natural alignment properties of memory allocation, no additional mapping tables or complex hash calculations are required, achieving extremely low overhead for head location.

[0064] For example, when the GPU program subsequently executes memory access instructions, such as reading and writing pointers in a CUDA kernel function, runtime checking code can be inserted to verify each access. Specifically, it first checks whether the highest bit of the pointer is marked as invalid. This mark is set by a subsequent pointer arithmetic verification mechanism to capture metadata corruption caused by pointer arithmetic overflow. If the pointer is valid, the out-of-bounds detection step can proceed. The first step in the detection is to locate the header metadata using the alignment tag carried in the pointer. The header address is calculated by clearing the pointer address using the alignment tag as a mask. Then, the previously stored 8 bytes of precise boundary information are read from the header address. Here, since a large number of threads (32 threads in a thread bundle) need to read the same header metadata when accessing the same buffer at the same time, and since all threads request the same header address, the GPU's memory subsystem can merge multiple access requests into a single memory transaction. That is, it only needs to read the data once from the global memory or L1 cache, and then distribute the result to all threads through a broadcast mechanism. Therefore, in one embodiment, by placing the metadata in the header of the same buffer shared by all threads, the metadata retrieval overhead can be reduced from one memory access per thread to one per thread bundle, thereby significantly reducing memory bandwidth pressure.

[0065] After obtaining the precise boundary, the offset of the current access is calculated, which is the pointer value minus the header address, to obtain the position of this access relative to the start of the buffer. This is then compared with the precise boundary. If the offset is less than 0 or greater than or equal to the boundary value, meaning the access occurred before the header or exceeded the range actually requested by the user, it is determined to be an out-of-bounds access, an error is immediately reported, and program execution is terminated. If the offset is within the legal range, memory access is allowed to continue. It is important to note that the precise boundary-based checking method can capture all types of space out-of-bounds errors, including but not limited to linear overflows (continuous writing beyond the end of the buffer), non-linear overflows (directly accessing out-of-bounds regions by bypassing canary values ​​through pointer arithmetic), and internal out-of-bounds errors. For example, if a program actually requests 100 bytes, but the allocator aligns it to 128 bytes, and the program incorrectly accesses offset 110 bytes, although the address is still within the 128-byte alignment boundary, it exceeds the 100 bytes actually requested by the user. In one embodiment, precise boundary comparison can accurately identify such violations, while simply checking whether the alignment boundary is exceeded will miss the report, fundamentally overcoming the shortcomings of methods such as canary values.

[0066] For example, during the memory release phase, when the GPU program calls release functions such as cudaFree, it does not immediately return the memory to the underlying system. Instead, it performs a metadata invalidation operation, setting the precise boundary information at the buffer header to 0, instantly invalidating all metadata associated with the buffer. After clearing the metadata, the underlying actual memory release function is called to reclaim the physical memory. Here, for detecting reuse errors after release, assuming that a dangling pointer to a buffer still exists in the program after it is released, if a memory access is subsequently initiated through this pointer, the check process will be triggered again. At this time, the precise boundary value read from the header by the system is 0, and any legal access offset must be greater than or equal to 0. Therefore, an offset greater than or equal to 0 and a boundary value of 0 will inevitably result in an offset greater than or equal to the boundary value, thus triggering an out-of-bounds error report and successfully capturing reuse after release. In this way, maintaining a complex memory allocation state table or using expensive reference counting is avoided, achieving time corruption detection at a very low cost.

[0067] Understandably, the GPU memory safety detection method provided in this application uses in-band precise boundaries instead of out-of-band shadow memory or canaries for metadata storage, preserving boundary precision while leveraging spatial locality to achieve merged broadcasting of metadata access. In pointer encoding, alignment tags are embedded in the high-order bits of the virtual address, simplifying the header location operation to a single bitwise operation instruction with negligible overhead. In detection logic, space out-of-bounds checks and temporal corruption detection are unified under a single boundary comparison mechanism; during release, simply clearing the boundary to zero is sufficient to prevent both types of errors, resulting in a concise and efficient architecture. Furthermore, the GPU memory safety detection method provided in this application is entirely software-based, relying solely on existing MMU hardware in commercial GPUs and the open-source LLVM compiler toolchain. No hardware modifications or proprietary tools are required, allowing direct application to existing NVIDIA GPU platforms, solving the problem of hardware-based solutions being unfeasible. It can detect all forms of space out-of-bounds errors, including internal out-of-bounds and non-linear overflows, as well as temporal corruption such as reuse after release.

[0068] like Figure 2 As shown, Figure 2 This is a flowchart of a GPU memory security detection method provided in another embodiment of this application; regarding the above step S140, it may include, but is not limited to, steps S210 and S220.

[0069] Step S210: In response to the memory buffer release operation, invalidate the precise boundary information in the header metadata;

[0070] Step S220: In response to an access instruction pointing to a freed memory buffer, detect a post-free reuse error based on the precise boundary information of the invalidation.

[0071] Understandably, reuse after free is a serious memory safety issue in GPU computing environments. When a program retains a pointer to a memory location after freeing it and attempts to access it, the memory may have already been reallocated to other objects, leading to data corruption and abnormal program behavior. It could also be maliciously exploited for privilege escalation or information leakage attacks. Maintaining complex allocation tracking tables or using reference counting mechanisms for reuse after free would incur enormous synchronization overhead and memory consumption on GPUs with thousands of concurrent threads, making practical applications difficult.

[0072] In one embodiment, invalidation refers to modifying the precise boundary value originally stored in the header 8 bytes of the buffer to a predefined invalid value. In one embodiment, the invalid value can be set to 0, because in normal program behavior, the offset corresponding to any legal memory access should be a positive value greater than or equal to 0 and less than the actual size of the buffer. Since 0 as the boundary value makes the buffer size 0, any access with an offset greater than or equal to 0 will cause the boundary check to fail, thereby detecting reuse errors after release. The invalidation can be implemented by clearing the 8 bytes at the header address with a simple atomic write instruction. Since each memory block has only one header and the release operation is initiated by a single thread, there are no concurrency issues, and the overhead is extremely low. It is important to note that the invalidation operation must be completed before the actual memory reclamation to ensure that all dangling pointers pointing to the memory block cannot be verified during subsequent accesses before the memory block is returned to the system.

[0073] After the metadata invalidation is completed, the underlying GPU driver interface can be called to actually reclaim the physical memory. In this way, even if the memory block is physically reallocated to other objects, the header metadata still stores the invalid value 0, and each new allocation will write new precise boundary information to the header. Therefore, the new object will have its own independent metadata, completely isolated from the old object.

[0074] For example, suppose the program has a defect and retains a dangling pointer to the memory region after freeing it, and then initiates memory access through this pointer at some later time. In this case, the alignment tag is extracted from the high-order bits of the pointer's virtual address, the header address is calculated using the alignment tag, and then the precise boundary information is read from that address. Since the memory block has been freed, the header stores the previously set invalid value 0, so the read boundary value is 0. Next, the offset of the current access is calculated; for example, if the pointer points to an offset position inside the buffer, the offset must be a value greater than or equal to 0. The offset is compared with the boundary value 0. Since the offset is greater than or equal to 0 and the boundary value is 0, the comparison result must be that the offset is greater than or equal to the boundary value, thus triggering an out-of-bounds error report. The program is terminated and the corresponding error message is output, clearly indicating that reuse after free has occurred.

[0075] For example, suppose there is a CUDA program that processes dynamic arrays. The program first allocates an array containing 100 integers using cudaMalloc, with the pointer denoted as ptr. The precise boundary value stored in the header metadata is 400 bytes. In the kernel function, the program uses this pointer to fill in data, and then mistakenly calls cudaFree(ptr) to release the array. However, after the release, the value of ptr is still retained and is not set to null. At the moment of the release operation, the 400 in the header 8 bytes of the memory block pointed to by ptr is rewritten to 0. Then, in another kernel function, ptr is mistakenly used again to access array elements. For example, the operation intval=ptr

[50] is executed. At this time, the memory access check code is activated, extracts the alignment tag (let's say it's 6) from ptr, and calculates... The header address is the value of the lower 6 bits of ptr after clearing them, and then the boundary value 0 is read from the header. Then, the offset of the current access is calculated. The offset of the address corresponding to ptr

[50] relative to the header is (50*4) + header offset. Assuming that the header occupies 8 bytes and is located before the user data area, the actual offset should be 8+200=208 bytes. During the boundary check, it is found that 208>=0 and 208>=0 (the boundary value is 0), so it is determined to be an out-of-bounds access. The error is immediately reported and the kernel execution is terminated, thereby avoiding possible data corruption or security vulnerabilities.

[0076] Understandably, the GPU memory safety detection method provided in this application achieves complete coverage detection of reuse errors after release, filling the gap in time corruption detection in traditional schemes such as canary canaries. Moreover, the detection mechanism is extremely lightweight, with the invalidation operation consisting of only one memory write. The detection operation reuses existing boundary checks, without introducing new data structures or synchronization primitives, thus having a small impact on program performance. Furthermore, because the header metadata of each memory block is independent and unique, the release operation only modifies the header of the current block and does not affect the metadata of other memory blocks. Multiple threads can execute in complete parallelism when releasing different memory blocks simultaneously.

[0077] In another embodiment of the GPU memory security detection method provided in this application, the metadata tag also includes a pointer type bit and an identity identifier; the pointer type bit is used to distinguish between pointers to global memory and local memory;

[0078] For pointers to local memory, the identifier is the stack duration, which includes stack depth and generation, used to uniquely identify the lifecycle of a stack frame; for pointers to global memory, the identifier is virtual address randomization information implemented by configuring the GPU memory management unit page table.

[0079] Understandably, in a GPU programming model, memory can be divided into global memory and local memory. Global memory is the heap memory shared by all threads and used to store long-term data. Local memory refers to the stack memory private to each thread, used to store local variables and intermediate results of function calls. The allocation and deallocation of global memory are explicitly controlled by the program, and dangling pointers may exist pointing to global memory that has already been freed. The allocation and deallocation of local memory are automatically bound to the push and pop operations of the function call stack, and its lifespan is determined by the depth of the function call. When the function returns, the stack frame is destroyed, but if there are pointers pointing to local variables within that stack frame, a dangling pointer problem similar to that of freed and reused stack memory can occur.

[0080] For example, a pointer type bit is introduced in the metadata tag to distinguish whether the current pointer points to global memory or local memory. In one embodiment, the pointer type bit occupies 1 bit; for example, when this bit is 0, it indicates that it points to global memory, and when it is 1, it indicates that it points to local memory. The pointer type bit can be automatically set according to the source of the allocation request when the pointer is generated. If the memory allocation is performed through heap memory allocation functions such as cudaMalloc, the type bit is set to 0; if the memory allocation is due to the automatic allocation of local variables on the stack because of function calls, such as non-static local arrays declared in kernel functions, the type bit is set to 1, so that when the system performs memory access checks, it can immediately know the type of memory pointed to by the current pointer, thereby calling the corresponding verification logic.

[0081] For pointers to local memory, an identity is encoded in the metadata tag, specifically represented by a stack duration. Stack duration includes stack depth and generations. Stack depth refers to the nesting level of the current thread's function call stack; for example, the main function's depth is 0, the called sub-function's depth is 1, and so on. Generations are monotonically increasing counters used to distinguish different instantiations at different times with the same stack depth. When a function call occurs, a new stack frame is created, and the system allocates a unique stack duration to it. For example, the current thread's stack depth is incremented by 1, and the generation counter is incremented by 1, or other unique incrementing methods are used. These two values ​​are then combined and encoded into a single value; for example, depth occupies 5 bits, and generation occupies 5 bits, together forming a 10-bit stack duration. Subsequently, the stack duration is embedded in the high-order bits of pointers to any local variables within that stack frame. Thus, each stack frame possesses a unique identity throughout the entire program execution, ensuring that even if the same function is called multiple times at the same depth, the stack duration acquired each time will be different. When memory is accessed subsequently through this pointer, in addition to performing regular boundary checks, it is also necessary to verify whether the stack age carried in the pointer matches the actual stack state of the current thread. For example, the stack depth in the pointer is extracted and it is determined whether it is less than or equal to the actual stack depth of the current thread. If the pointer depth is greater than the current depth, it means that the stack frame pointed to by the pointer has been popped, and the access is illegal. If the depth is less than or equal to the current depth, the generation value is further extracted and compared with the generation value of the corresponding depth maintained by the current thread. Only if the generation values ​​are completely consistent does it mean that the stack frame is still alive. Here, each thread also needs to maintain a small stack age table in memory, recording the currently active generation value for each stack depth. When a function call enters, the table is updated, and when the function returns, it is rolled back. Since each thread maintains its own table independently, the stack depth is very small, so the overhead is extremely low, which can effectively prevent dangling pointer access on the stack.

[0082] For pointers to global memory, virtual address randomization is used as an identifier. The dangling pointer problem in global memory arises when programmers mistakenly continue using the pointer after it has been freed. Preventing this confusion involves ensuring that when freed memory is reallocated, the new object has a different identifier than the old object, preventing the old pointer from successfully accessing the new object. Therefore, each time global memory is allocated via cudaMalloc, in addition to allocating physical memory, a virtual address is requested from the MMU for that physical page. Random numbers are introduced into specific controllable bits of the virtual address. For example, bits 40 to A in the virtual address are filled with a randomly generated value, where A is determined by the system configuration. This randomization operation is implemented by modifying the corresponding fields in the page table entry, without changing the actual location of the physical memory. Therefore, it has no impact on program functionality, but it introduces randomness into the high-order bits of the virtual address obtained with each allocation. When the same physical memory is freed and then reallocated, even though the physical pages are the same, the random high-order bits of the virtual address are highly likely to be different from the previous one due to the randomization mechanism. Therefore, any dangling pointer holding the old pointer will be checked by the MMU when dereferenced. Since the high-order bits of the virtual address do not match the current page table, the address translation will fail, triggering an exception. Even if the address translation succeeds in some special cases, such as the random part being exactly the same as the old value, the probability is extremely low. When the program accesses memory and performs boundary checks, because the header address pointed to by the old pointer is calculated based on the old virtual address, while the header of the new object is located at the new virtual address, the old pointer cannot correctly locate the header of the new object and cannot pass the boundary check. This greatly improves the success rate of detecting the reuse of global memory after freeing.

[0083] For example, suppose a CUDA kernel function defines a local array intarr

[10] and obtains a pointer p to that array. Then the function calls a subfunction foo, which attempts to access arr through p. In some cases, the program may still access arr using p in the parent function after foo returns, at which point the stack frame containing arr has been destroyed. When `arr` is created in the parent function's stack frame, the system allocates a unique stack era for that stack frame, for example, depth = 0, generation = 1234. These two values ​​are encoded and embedded in the high bits of pointer `p`. When entering the child function `foo`, the thread's stack depth becomes 1, and the generation is updated to the new value. At this time, if you try to access `arr` using `p` in `foo`, since the depth in pointer `p` is 0, which is less than the current depth of 1, and the generation 1234 is consistent with the generation recorded at the current depth 0, the access is legal. When `foo` returns, the thread's stack depth returns to 0. If you try to access `arr` again using `p`, you will find that the depth in the pointer is equal to the current depth 0. However, during the generation check, it is found that the generation value recorded at the current depth 0 may have been reset or updated to other values ​​due to the function return, which does not match the 1234 in the pointer. Therefore, the access is determined to be illegal, and an error is immediately reported.

[0084] Suppose the program allocates a block of global memory, pointer p1, with a virtual address of 0x7f8a4b3c0100, where the high-order bits contain randomization information 0x7f8a4b. Subsequently, the program frees p1 and allocates memory of the same size again. Due to randomization, the virtual address of the new pointer p2 may be 0x3d2e1f5c0800, with completely different high-order bits. If the program mistakenly retains p1 and continues to use it after freeing it, for example, by executing p1[0]=10, when the MMU attempts to translate the virtual address of p1, it finds that its high-order bits 0x7f8a4b do not match the high-order bits 0x3d2e1f recorded in the current page table, directly triggering a page fault, causing the program to crash and prompt an illegal access error. Even if the MMU translation succeeds under certain circumstances, such as when the system does not enable strict high-order matching, when performing boundary checks, the system will calculate the header address based on the alignment tag in p1. However, this header address is calculated based on the virtual address of p1, while the header of the actual memory block is located at the virtual address of p2. Therefore, the header metadata read by p1 is a random invalid value, and the boundary check will also fail.

[0085] Therefore, by distinguishing pointer types, fine-grained protection against different memory characteristics is achieved, avoiding performance or coverage loss caused by using a single solution to solve all problems. Secondly, the uniqueness and verifiability of the stack phase ensure that the life cycle of the stack frame can be accurately determined even in complex multi-level function call scenarios. The virtual address randomization scheme utilizes existing MMU hardware features to achieve global memory anti-obfuscation protection at extremely low cost, without modifying the hardware or introducing complex software tracing mechanisms. The overhead is only in generating random numbers and configuring page tables during allocation, which has no impact on runtime performance.

[0086] like Figure 3 As shown, Figure 3 This is a flowchart of a GPU memory security detection method provided in another embodiment of this application; regarding the above step S130, it may include, but is not limited to, steps S310 and S320.

[0087] Step S310: Clear the low bits of the pointer to obtain the address of the header metadata according to the number of bits indicated by the alignment tag;

[0088] Step S320: Merge multiple threads’ header metadata read requests for the same memory buffer into a single memory request by using memory access broadcast.

[0089] For example, the alignment tag is determined according to the allocator's alignment rules during memory allocation and encoded in binary form in the high-order bits of the pointer's virtual address. For instance, if the memory allocator uses a 2^n byte alignment, the value of the alignment tag is n, written to specific high-order bits of the pointer during allocation, occupying 6 bits to represent a maximum alignment of 2^63. When the subsequent program accesses memory through this pointer, it needs to locate the head of the memory buffer to which the pointer belongs in order to read precise boundary information. Since the memory allocator guarantees that the starting address of the buffer is aligned to a 2^n byte, the lower n bits of any pointer p pointing to a location inside the buffer reflect the offset of that location relative to the starting address of the buffer. Clearing the lower n bits to zero yields the starting address of the buffer, which is the storage location of the header metadata. In some embodiments, the compiler generates a corresponding instruction sequence during instrumentation. First, it extracts the alignment tag from the high-order bits of the pointer through shift and mask operations, then generates a mask and performs a bitwise AND operation on the pointer to obtain the header address, and finally uses this address to initiate a memory read.

[0090] When multiple threads access the same buffer, they need to read the same header metadata, so all threads calculate the same header address. During instruction execution, although each thread independently initiates a read request to the same address, the hardware detects that these requests target the same address and automatically merges them into a single memory read transaction. After retrieving the result from memory or cache, it distributes it to all requesting threads via a broadcast mechanism. Thus, regardless of how many threads in a thread bundle are accessing the same buffer, the metadata is actually read only once.

[0091] like Figure 4 As shown, Figure 4 This is a flowchart of a GPU memory security detection method provided in another embodiment of this application; the above method may also include, but is not limited to, step S410.

[0092] Step S410: In response to pointer arithmetic operations, perform metadata integrity verification on the result pointer after the operation.

[0093] The above step S410 may include, but is not limited to, steps S420 to S440.

[0094] Step S420: Calculate the XOR value between the original pointer and the result pointer;

[0095] Step S430: If the XOR value is non-zero in the high-order region defined by the alignment label, then mark the result pointer as invalid;

[0096] Step S440: In the memory access check, if a pointer is detected as invalid, a pointer arithmetic error is reported.

[0097] Understandably, if an arithmetic operation causes a pointer to cross the boundary of its original buffer, or if an integer overflow causes a change in the high-order bits, metadata embedded in the high-order bits, such as alignment tags, pointer type bits, and identifiers, may be accidentally modified or lost. When metadata is corrupted, subsequent memory access checks will be based on erroneous information, potentially causing out-of-bounds accesses that should be caught to go undetected due to metadata errors, and causing legitimate accesses to be falsely detected due to metadata errors.

[0098] Based on this, after each pointer arithmetic operation, the original pointer and the result pointer are XORed, and it is checked whether the high-order part corresponding to the metadata area in the XOR result is zero. Here, the metadata area refers to a specific set of bit positions in the pointer virtual address used to store metadata tags. For example, in a 64-bit system, bits 48 to 63 may be used to store alignment tags, type bits, and identity identifiers, etc. The alignment tag itself is not only used to locate the header but also defines which high-order bits are fixed and immutable. Specifically, the alignment tag n indicates that the alignment granularity of the buffer is 2 to the power of n, meaning that the lower n bits of the pointer can freely vary to represent an offset, but the bits higher than n should remain unchanged within the normal buffer range because any legitimate pointer arithmetic operation can only occur within the same buffer and does not change the high-order part of the buffer base address. Therefore, if an arithmetic operation causes a change in the high-order bits of the result pointer relative to the original pointer, it indicates that the operation may have caused the pointer to cross out of the original buffer or an integer overflow has occurred, destroying the integrity of the metadata. By calculating the XOR value of the original pointer and the result pointer and then masking off the lower n bits, if the masked XOR value is non-zero, it indicates that the high-order bits have changed, suggesting that the metadata may have been corrupted.

[0099] In some embodiments, the compiler will identify all pointer arithmetic operation instructions during the stamping process and insert verification code after them. For example, for the expression p = p + i, the compiler will first generate a new pointer value p_new, then calculate xor_val = (uintptr_t)p_old ^ (uintptr_t)p_new, generate a mask mask = ~((1 << n) - 1) according to the alignment tag n, that is, all high-order bits are 1 and the lower n bits are 0, and then calculate changed = xor_val & mask. If changed is non-zero, then mark p_new as an invalid pointer. The way to mark it as invalid can be to set the highest bit of the pointer to 1 because this bit of a normal pointer is usually 0. Setting this bit to 1 is equivalent to creating a non-existent address, and any subsequent dereference will trigger a hardware exception. At the same time, the system can also explicitly check this bit to report an error; or record the validity of each pointer in a separate shadow storage. For any subsequent memory access check on a marked pointer, the highest bit will be checked first. If it is found to be 1, a pointer arithmetic error will be immediately reported and the program will be terminated.

[0100] For example, consider a pointer `p` pointing to an array of size 100 bytes with an alignment label of 6. The program iterates through the array using a loop `p++`. When `p` points to the last element, another `p++` will make `p` point to memory beyond the array. At this point, the lower 6 bits of `p_new` relative to `p_old` might change from a certain value to 0, but the higher bits of `p_new` change because they cross a 2^6 boundary; for example, they might carry over from the base address to a higher bit. The verification code calculates `xor_val & mask` and finds a change in the higher bit region, so it sets the highest bit of `p_new` to 1. When subsequent programs access memory using an out-of-bounds pointer, checking the highest bit and finding it to be 1 immediately reports a pointer arithmetic error, preventing further out-of-bounds access.

[0101] If the value of pointer p is 0xFFFFFFFFFFFFFF000 and the alignment label is 12, adding a large offset to p will cause an overflow, resulting in a complete flip of the high-order bits. At this time, the high-order region of xor_val will be non-zero, and the verification mechanism will also capture this and mark the result pointer as invalid.

[0102] In some embodiments, if an attacker tampers with the metadata in the high bits of a pointer through arithmetic operations, for example, changing the type bit from local to global, or modifying the stack epoch to bypass the timing check, the high-bit integrity verification provided in this application embodiment can detect any unintended modification to the high bits, because any intentional tampering will result in a non-zero XOR value for the high bits, thus being marked as invalid.

[0103] Based on this, the GPU memory security detection method provided in this application protects the integrity of metadata, ensuring that all subsequent memory access checks are based on correct information, fundamentally avoiding detection failures caused by metadata corruption. Furthermore, by directly embedding an invalid flag into the highest bit of the pointer, zero-cost error state propagation is achieved, requiring no additional data structures or synchronization. This complements space bounds checking and temporal corruption detection, jointly constructing a comprehensive protection system. Space bounds checking captures out-of-bounds access, temporal corruption detection captures reuse after release, and pointer arithmetic verification protects the metadata itself from corruption. The collaborative work of these three components ensures the entire memory security detection system remains stable and reliable under various program behaviors and potential attacks, greatly improving the security of GPU programs.

[0104] like Figure 5 As shown, Figure 5 This is a flowchart of a GPU memory security detection method provided in another embodiment of this application; regarding the above step S210, it may include, but is not limited to, steps S510 and S520.

[0105] Step S510: Set the precise boundary information to zero;

[0106] Step S520: For local memory, allocate a unique stack era identifier for each stack frame, and verify the consistency between the stack era in the pointer and the current thread's stack era when dereferencing; for global memory, introduce random values ​​in specific bits of the virtual address through the page table configuration of the memory management unit during memory allocation.

[0107] Understandably, when a buffer is freed, whether for local or global memory, the precise boundary value stored in the header is rewritten to 0. This causes any subsequent access initiated via a dangling pointer to fail during boundary checks because the offset is greater than or equal to 0, resulting in a boundary value of 0 and triggering an error report. However, simply setting it to zero does not completely solve the obfuscation problem. If memory is reallocated, the new object will write a new boundary value at the same location. If the old pointer happens to be able to locate the new header—for example, if the new header address obtained by the old pointer after alignment tag calculation is the same as the header address of the new object—the boundary check might be based on the new boundary value. If the offset pointed to by the old pointer happens to be within the valid range of the new object, it will be mistakenly judged as a valid access.

[0108] For local memory, when a function is called, a new stack frame is created to store local variables, function parameters, and the return address. When the function returns, the stack frame is destroyed, and the memory space it occupies can be reused by subsequent function calls. Thus, if a pointer points to a local variable within a stack frame and is still used after the function returns, the pointer might accidentally access data in the new stack frame because the stack space may have been overwritten by subsequent function calls. Therefore, each stack frame is assigned a unique stack era identifier, including stack depth and generation. Each stack frame has a unique identifier. When memory is accessed subsequently through this pointer, the system, in addition to performing regular boundary checks, also extracts the stack era from the pointer and compares it with the current thread's stack state.

[0109] For global memory, allocation and deallocation are explicitly controlled by the program through APIs such as cudaMalloc and cudaFree. When a block of memory is freed and then reallocated to another object, if the old pointer happens to point to the header of the new object, it may read the new object's metadata, leading to a false positive for reuse after deallocation. Therefore, during each memory allocation, random numbers are introduced into specific controllable bits of the virtual address by configuring the GPU's memory management unit page table, so that the same physical memory page obtains distinctly different virtual addresses in different allocation cycles.

[0110] like Figure 6 As shown, Figure 6This is a flowchart of a GPU memory security detection method provided in another embodiment of this application; the above method may also include, but is not limited to, step S610.

[0111] Step S610: Perform duplicate checks on memory access check instructions, or merge adjacent memory access check instructions, or elevate memory access checks based on inductive variables within a loop to execution outside the loop.

[0112] Understandably, in instrumented memory safety checks, the compiler inserts check code before each memory access instruction. For large-scale GPU programs, instrumentation can lead to an overabundance of check instructions, potentially exceeding the program's own instruction count and causing performance degradation. Therefore, compiler optimization techniques can be used to reduce the overhead of these checks, such as eliminating duplicate checks, merging adjacent memory access checks, or moving induction-based memory access checks within loops to outside the loop.

[0113] Duplicate check elimination is an optimization based on data flow analysis. It is used to identify and remove scenarios where the same memory address is checked multiple times in a short period of time. In other words, if there is no operation that can change the validity of a memory address between the first check and the second check on a certain code path, such as no reallocation of the same buffer or pointer arithmetic operations that change pointer values, then the second check is redundant and can be safely eliminated.

[0114] In some embodiments, the compiler constructs control flow graphs and data flow graphs in the intermediate presentation layer to track the definition and usage of each pointer variable. For example, in a piece of code where the same pointer p accesses different fields p->a, p->b, and p->c of the same structure multiple times, the compiler analyzes the code and finds that after the first check of p, the value of p has not changed, and the memory buffer pointed to by p has not been freed or reallocated during this period. Therefore, the access checks for p->b and p->c can be eliminated, and only the check for p->a is retained. In some embodiments, if the same address is accessed multiple times in a loop body, and that address remains unchanged during the loop iteration, the check can be moved to an execution outside the loop, and is not repeated inside the loop.

[0115] Adjacent check merging is an optimization that combines multiple independent check instructions into a composite check, which can be used in scenarios where multiple memory access instructions are adjacent in program order and the accessed memory addresses have some regularity. For example, for different offsets based on the same base address. At this time, originally multiple header metadata reads and multiple boundary comparisons were required. After merging, only one header read can be performed, and then batch verification can be performed for multiple offsets. In one embodiment, the compiler will identify consecutive accesses to different offsets of the same buffer and aggregate them into a check block. For example, for the code a = p[0]; b = p[1]; c = p[2]; originally three checks were required, each time reading the header, calculating the offset, and comparing. After merging, the header metadata can be read once first, then three offsets are calculated, and then it is checked at once whether all three offsets are within the boundaries. If any one is out of bounds, an error is reported. If all are legal, the subsequent three actual memory accesses are allowed to execute.

[0116] Memory access check promotion based on induction variables within a loop is an optimization for loop structures. In GPU programs, a large amount of computation is carried out in the form of loops. For example, element-by-element operations on arrays. Inside the loop, each iteration accesses an array element. If a check is inserted for each iteration, it will result in extremely high overhead. However, the addresses accessed in the loop change linearly based on induction variables and the entire loop is carried out within the same buffer. At this time, the checks for each iteration within the loop can be promoted to outside the loop, and only one check is performed to verify whether the entire access range is legal. Specifically, the compiler analyzes the start index, end index of the loop, and the access address corresponding to each index, calculates the minimum offset and maximum offset that may be accessed during the entire loop process, and then inserts a check before the loop to verify whether the entire range from the minimum offset to the maximum offset is within the legal boundaries of the buffer. If it passes, all accesses within the loop body do not need to be checked separately. For example, for the loop for(i = 0; i < N; i++){sum += A[i];}, the compiler can calculate that the access range is from offset 0 to offset (N - 1) * element size, and then check whether this range is within the boundaries of array A before the loop. If the size of A is sufficient to accommodate these elements, all accesses to A[i] within the loop body do not need to be checked again.

[0117] Based on the GPU memory safety detection methods of the above various embodiments, the following respectively present various embodiments of the operation control device, electronic device, and computer-readable storage medium of this application.

[0118] As Figure 7 shown, Figure 7This is a schematic diagram of a runtime control device for executing a GPU memory security detection method according to an embodiment of this application. The runtime control device 700 implemented in this application includes: a processor 720, a memory 710, and a computer program stored in the memory 710 and executable on the processor 720, wherein... Figure 7 The example uses a processor 720 and a memory 710.

[0119] The processor 720 and memory 710 can be connected via a bus or other means. Figure 7 Taking the example of a connection between China and Israel via a bus.

[0120] The memory 710, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, the memory 710 may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 710 may optionally include remotely located memories 710 relative to the processor 720, which can be connected to the operation control device 700 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0121] Those skilled in the art will understand that Figure 7 The device structure shown does not constitute a limitation on the operation control device 700, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0122] exist Figure 7 In the illustrated operation control device 700, the processor 720 can be used to call the control program stored in the memory 710, thereby implementing the GPU memory security detection method described above. Specifically, the non-transitory software program and instructions required to implement the GPU memory security detection method of the above embodiment are stored in the memory 710, and when executed by the processor 720, the GPU memory security detection method of the above embodiment is executed.

[0123] It is worth noting that, since the operation control device 700 of this application embodiment can execute the GPU memory security detection method of any of the above embodiments, the specific implementation method and technical effect of the operation control device 700 of this application embodiment can refer to the specific implementation method and technical effect of the GPU memory security detection method of any of the above embodiments.

[0124] Furthermore, one embodiment of this application also provides an electronic device that includes the operation control device described in the above embodiment.

[0125] It is worth noting that, since the electronic device of this application embodiment includes the operation control device of the above embodiment, and the operation control device of the above embodiment can execute the GPU memory security detection method of any of the above embodiments, the specific implementation method and technical effect of the electronic device of this application embodiment can refer to the specific implementation method and technical effect of the GPU memory security detection method of any of the above embodiments.

[0126] Furthermore, one embodiment of this application also provides a computer-readable storage medium storing computer-executable instructions for performing the aforementioned GPU memory security detection method. Exemplarily, the above-described method is executed... Figures 1 to 6 The methods and steps in the text.

[0127] It is worth noting that, since the computer-readable storage medium of this application embodiment can execute the GPU memory security detection method of any of the above embodiments, the specific implementation and technical effects of the computer-readable storage medium of this application embodiment can be referred to the specific implementation and technical effects of the GPU memory security detection method of any of the above embodiments.

[0128] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which may include computer storage media or non-transitory media and communication media or transient media. As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc DVD or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0129] In the several embodiments provided in this application, it should be understood that the disclosed systems, instruments, and methods can be implemented in other ways. For example, the instrument embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between instruments or units may be electrical, mechanical, or other forms. Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, i.e., they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0130] It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

[0131] The embodiments of this application have been described in detail above with reference to the accompanying drawings. However, this application is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of this application.

Claims

1. A GPU memory security detection method, characterized in that, include: In response to a memory allocation request in a GPU program, a memory buffer with header metadata is allocated, and the precise boundary information of the memory buffer is stored in the header metadata; A pointer corresponding to the memory buffer is generated, wherein a metadata tag is embedded in the high-order bits of the virtual address of the pointer, and the metadata tag includes an alignment tag for locating the header metadata; In response to memory access instructions in the GPU program, the header metadata is located based on the alignment tag and the precise boundary information is read; The memory access is checked for spatial out-of-bounds based on the precise boundary information, and temporal corruption is detected in response to the release operation of the memory buffer. In response to pointer arithmetic operations, perform metadata integrity verification on the resulting pointer. The step of performing metadata integrity verification on the result pointer in response to pointer arithmetic operations includes: Calculate the XOR value between the original pointer and the result pointer; If the XOR value is non-zero in the high-order region defined by the alignment label, then the result pointer is marked as invalid; During memory access checks, if a pointer is detected as invalid, a pointer arithmetic error is reported.

2. The method according to claim 1, characterized in that, The time corruption detection in response to the release operation of the memory buffer includes: In response to the release operation of the memory buffer, the precise boundary information in the header metadata is invalidated; In response to an access instruction to a freed memory buffer, detect post-free reuse errors based on precise invalidation boundary information.

3. The method according to claim 1, characterized in that, The step of locating the header metadata based on the alignment tag includes: Based on the number of bits indicated by the alignment tag, the low-order bits of the pointer are cleared to obtain the address of the header metadata; Memory access broadcasting combines multiple threads' header metadata read requests for the same memory buffer into a single memory request.

4. The method according to claim 2, characterized in that, The step of invalidating the precise boundary information in the header metadata includes: Set the precise boundary information to zero; For local memory, a unique stack era identifier is assigned to each stack frame, and the consistency between the stack era in the pointer and the current thread's stack era is verified during dereference. For global memory, random values ​​are introduced into specific bits of the virtual address through the page table configuration of the memory management unit during memory allocation.

5. The method according to claim 1, characterized in that, Also includes: The method can eliminate duplicate memory access checks, merge adjacent memory access checks, or move memory access checks based on inductive variables within a loop to outside the loop.

6. An operation control device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the method as claimed in any one of claims 1 to 5.

7. An electronic device, characterized in that, Includes the operation control device as described in claim 6.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to perform the method as described in any one of claims 1 to 5.

Images