Memory exception positioning method and device based on dynamic page protection

Abstract

This application relates to a method and apparatus for memory anomaly localization based on dynamic page protection. The method includes: acquiring a target memory object to be monitored; determining the target code execution interval corresponding to the target memory object; in response to the execution flow entering the target code execution interval, applying write protection to the target memory page corresponding to the target memory object; monitoring write access operations to the target memory page within the target code execution interval; when a write access to the target memory page triggers an access permission anomaly, acquiring anomaly context information corresponding to the access permission anomaly; and determining the location of the memory anomaly based on the anomaly context information. This application dynamically binds the business code execution interval to the hardware write protection of memory pages, utilizing the MMU anomaly mechanism to transform the random destructive behavior of irregular memory crashes into precise and catching deterministic anomaly events, thereby achieving automated localization of the root cause of the crash.

Description

Technical Field

[0001] This application relates to the field of computer information processing, and more specifically, to a method and apparatus for locating memory anomalies based on dynamic page protection. Background Technology

[0002] In modern Linux kernel-based network devices (such as routers and firewalls) and high-performance servers, core network data forwarding functions are implemented by the kernel, while diverse business logic (such as traffic management and security detection) is often dynamically loaded as kernel modules. These modules frequently manipulate the core network data structure sk_buff during development. Because modules are usually developed independently by different teams, iterate rapidly, and test scenarios are difficult to fully cover, hidden memory operation defects can easily be introduced. The most harmful type is memory trampling—that is, a module incorrectly writes to or corrupts the sk_buff memory area managed by other modules or not under its responsibility.

[0003] System failures caused by these defects are highly destructive and extremely difficult to diagnose, mainly because: Triggered sporadically and difficult to reproduce: Stampedes are often triggered only occasionally under specific concurrency conditions, data packet sequences, or system loads, and are difficult to reproduce stably in development and testing environments.

[0004] The scene is lost and the root cause is unclear: After a system crash, only the final abnormal state (such as pointer error) can usually be observed, while key root cause information such as the specific module, code location and execution context of the first illegal write has been lost.

[0005] There is a conflict between debugging methods and production environment requirements: Traditional and effective kernel debugging methods (such as hardware breakpoints and a large number of instrumentations) usually seriously interfere with system performance or cause service interruptions, making them difficult to implement in production or near-production environments that require high availability.

[0006] Therefore, the industry has long faced a technical challenge: how to intercept sk_buff memory overflows in real time in production or near-production environments with acceptable and extremely low overhead, and accurately pinpoint the specific business module and line of code causing the problem. Conventional methods such as log analysis and static analysis are often ineffective against such sporadic and persistent memory issues.

[0007] The information disclosed in the background section is only intended to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0008] In view of this, this application provides a memory anomaly localization method and apparatus based on dynamic page protection. By dynamically binding the execution range of business code with the hardware write protection of memory pages, the random destructive behavior of irregular memory trampling is transformed into a precise and catchable deterministic anomaly event by utilizing the MMU anomaly mechanism, thereby achieving automated localization of the root cause of the trampling with extremely low performance overhead.

[0009] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0010] According to one aspect of this application, a memory anomaly localization method based on dynamic page protection is proposed. The method includes: acquiring a target memory object to be monitored; determining a target code execution interval corresponding to the target memory object; in response to an execution flow entering the target code execution interval, applying write protection to the target memory page corresponding to the target memory object; monitoring write access operations to the target memory page within the target code execution interval; when a write access to the target memory page triggers an access permission anomaly, acquiring an anomaly context information corresponding to the access permission anomaly; and determining the location of the memory anomaly based on the anomaly context information.

[0011] In one exemplary embodiment of this application, the method further includes: in response to the execution flow exiting the target code execution region, releasing the write protection of the target memory page and restoring the target memory page to a writable state.

[0012] In one exemplary embodiment of this application, determining the target code execution interval corresponding to the target memory object includes: determining the target business module where the target memory object has a memory abnormality based on at least one of historical fault logs, system abnormal information, memory abnormality statistics, and static code analysis results; determining the target code region in the target business module; and determining the entry position to the exit position of the target code region as the target code execution interval.

[0013] In one exemplary embodiment of this application, before applying write protection to the target memory page corresponding to the target memory object, the method further includes: allocating an independent target memory page for the target memory object; and performing page-aligned storage on the target memory object according to a preset page boundary, so that the target memory object exclusively occupies the target memory page.

[0014] In one exemplary embodiment of this application, applying write protection to the target memory page corresponding to the target memory object includes: modifying the access permissions in the page table entry corresponding to the target memory page so that the target memory page is in a write-protected state.

[0015] In one exemplary embodiment of this application, in response to the execution flow entering the target code execution region, applying write protection to the target memory page corresponding to the target memory object includes: in response to the execution flow entering the target code execution region, calling a first permission control interface to apply write protection to the target memory page corresponding to the target memory object.

[0016] In one exemplary embodiment of this application, when a write access to the target memory page triggers an access permission exception, obtaining the exception context information corresponding to the access permission exception includes: determining the generated access permission exception when the memory management unit detects that a write operation is performed on the target memory page which is in a non-writable state; obtaining the exception context information based on the exception address, processor running state, and call relationship corresponding to the access permission exception, wherein the exception context information includes at least one of the following: function call stack information; processor register information; exception memory address; thread context information; instruction address information.

[0017] In one exemplary embodiment of this application, in response to the execution flow exiting the target code execution region, the write protection of the target memory page is released, which includes: in response to the execution flow exiting the target code execution region, calling a second permission control interface to release the write protection of the target memory page.

[0018] In one exemplary embodiment of this application, the method runs in a pre-built debug runtime environment. The construction of the debug runtime environment includes: modifying the memory allocation strategy of the target memory object so that the target memory object is allocated memory according to a preset page boundary, so that each target memory object corresponds to an independent target memory page; configuring permission control logic at the entry and exit positions of the target code execution interval to apply write protection to the target memory page when the execution flow enters the target code execution interval and to remove the write protection when the execution flow exits the target code execution interval; and generating the debug runtime environment based on the memory allocation strategy and the permission control logic.

[0019] According to one aspect of this application, a memory anomaly localization device based on dynamic page protection is proposed. The device includes: an object module for acquiring a target memory object to be monitored; an interval module for determining a target code execution interval corresponding to the target memory object; a write protection module for applying write protection to a target memory page corresponding to the target memory object in response to the execution flow entering the target code execution interval; a detection module for monitoring write access operations to the target memory page within the target code execution interval; an information module for acquiring an anomaly scene information corresponding to the access permission anomaly when a write access to the target memory page triggers an access permission anomaly; and a localization module for determining the location where the memory anomaly occurred based on the anomaly scene information.

[0020] According to one aspect of this application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs; and, when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the method as described above.

[0021] According to one aspect of this application, a computer-readable medium is provided having a computer program stored thereon that, when executed by a processor, implements the method described above.

[0022] According to the memory anomaly localization method and apparatus based on dynamic page protection of this application, the following steps are taken: First, a target memory object to be monitored is acquired. Then, the target code execution interval corresponding to the target memory object is determined. In response to the execution flow entering the target code execution interval, write protection is applied to the target memory page corresponding to the target memory object. Within the target code execution interval, write access operations to the target memory page are monitored. When a write access to the target memory page triggers an access permission anomaly, an anomaly scene information corresponding to the access permission anomaly is acquired. The location of the memory anomaly is determined based on the anomaly scene information. By dynamically binding the business code execution interval with the hardware write protection of the memory page, the random destructive behavior of irregular memory crashes is transformed into precise and catching deterministic anomaly events using the MMU anomaly mechanism, thereby achieving automated localization of the root cause of the crash with extremely low performance overhead.

[0023] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0024] The above and other objects, features, and advantages of this application will become more apparent from the detailed description of exemplary embodiments with reference to the accompanying drawings. The drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0025] Figure 1 This is a schematic diagram of existing memory anomaly location methods.

[0026] Figure 2 This is a schematic diagram illustrating a memory anomaly location method based on dynamic page protection, according to an exemplary embodiment.

[0027] Figure 3 This is a flowchart illustrating a memory anomaly location method based on dynamic page protection, according to an exemplary embodiment.

[0028] Figure 4 This is a flowchart illustrating a memory anomaly location method based on dynamic page protection, according to another exemplary embodiment.

[0029] Figure 5 This is a schematic diagram illustrating a memory anomaly location method based on dynamic page protection, according to another exemplary embodiment.

[0030] Figure 6 This is a schematic diagram illustrating a memory anomaly location method based on dynamic page protection, according to another exemplary embodiment.

[0031] Figure 7 This is a block diagram illustrating a memory anomaly location device based on dynamic page protection, according to another exemplary embodiment.

[0032] Figure 8 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0033] Figure 9 This is a block diagram illustrating a computer-readable medium according to an exemplary embodiment. Detailed Implementation

[0034] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this application will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0035] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0036] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0037] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0038] It should be understood that although the terms first, second, third, etc., may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another. Therefore, the first component discussed below may be referred to as the second component without departing from the teachings of this application. As used herein, the term "and / or" includes all combinations of any one and more of the associated listed items.

[0039] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of exemplary embodiments, and the modules or processes in the drawings are not necessarily essential for implementing this application, and therefore cannot be used to limit the scope of protection of this application.

[0040] The technical abbreviations used in this application are explained as follows: sk_buff: Socket Buffer, a core data structure of the Linux kernel network subsystem. It encapsulates network packets and their metadata for transmission within the kernel protocol stack. This invention is the key target object monitored and protected by the proposed solution.

[0041] MMU: Memory Management Unit, a hardware component integrated into the CPU, responsible for virtual address translation and enforcing access permissions in the Page Fault (PTE). This invention utilizes its hardware characteristics to convert illegal writes into page faults in real time.

[0042] Page protection: a memory protection mechanism that controls access to physical memory pages by setting or clearing permission bits (mainly the "writable" bit) in the Page Entrance Table (PTE). The core mechanism of this invention is a dynamic and reversible page protection.

[0043] Call stack: A data structure that records the sequence of function calls during program execution, including information such as return addresses. When a program encounters an exception, tracing back the call stack is crucial for locating the root cause. This invention captures one of the key pieces of context information when an exception is triggered.

[0044] Page fault: A hardware exception triggered by the MMU when the virtual address accessed by the CPU cannot be effectively mapped (e.g., the page is not in memory or there are insufficient permissions). This invention transforms illegal write behavior of sk_buff into a specific, catchable page fault event.

[0045] KDB: Kernel Debugger, a tool for interactive debugging during kernel runtime. In this invention, it serves as a context capture and information output environment automatically entered after an exception is triggered.

[0046] Through extensive research, the applicant discovered that in operating systems such as the Linux kernel, network protocol stacks, driver modules, and various kernel business modules typically require frequent access to and modification of target memory objects (such as kernel data structures like sk_buff). When programs suffer from defects such as out-of-bounds writes, illegal access, reference counting anomalies, or concurrent access conflicts, memory crashes can easily occur. Because such problems are usually characterized by random occurrences, complex triggering conditions, and low reproducibility, once they occur, they often only manifest as system crashes, data anomalies, or pointer invalidation, while the specific location of the first illegal write and the execution context are lost, making problem localization extremely difficult.

[0047] To address the aforementioned issues, existing technologies typically employ debugging methods such as static code analysis, dynamic log tracing, and hardware breakpoints for localization. Static code analysis involves manually or using auxiliary tools to examine the source code and identify potential memory access risks. Dynamic log tracing embeds logs into the target code path to record access to target memory objects during runtime, and analyzes the location of exceptions based on log information. Hardware breakpoints utilize the processor's debug registers to set write breakpoints at preset memory addresses, triggering debug exceptions when a write operation is detected at the corresponding address, and combining this with contextual information such as the call stack and registers for problem analysis.

[0048] However, the above-mentioned technical solutions still have certain limitations. On the one hand, both static code analysis and dynamic log tracing rely on debuggers to pre-determine the code paths or memory locations where anomalies may occur. For sporadic memory crashes with random locations and complex triggering conditions, analysis may easily miss some issues, and a large amount of manual intervention or log instrumentation is required, resulting in low debugging efficiency and increased system overhead. On the other hand, although hardware breakpoints can accurately locate the location of anomalies, they are limited by the number of processor debug registers and can only monitor a limited number of preset memory addresses. For scenarios where abnormal writes may occur at any location within the target memory object, comprehensive monitoring is difficult to achieve. In addition, hardware breakpoints require frequent entry into debug mode after being triggered, which can easily affect the normal operation of the system and is not conducive to continuous anomaly localization in production or high-load environments.

[0049] Therefore, how to monitor memory anomalies that occur randomly in the target memory object and have complex triggering conditions in real time while ensuring the normal operation of the system, and how to automatically obtain complete anomaly scene information when an anomaly occurs, so as to achieve rapid and accurate location of memory anomalies, has become a technical problem that urgently needs to be solved in this field.

[0050] To address the challenge of existing debugging techniques failing to effectively pinpoint the irregular memory overflows into the `sk_buff` structure within business modules, this application proposes a memory anomaly localization method based on dynamic page protection. This method enables real-time interception of illegal writes at runtime and precise identification of the root cause within specific business functions and lines of code.

[0051] More specifically, this application aims to solve the industry-wide problem of locating critical data structures such as `sk_buff` in the kernel due to "irregular memory dumping." Its core is to build and deploy a dedicated kernel debugging version during the problem localization phase. This version uses a dynamic page protection mechanism that trades space for monitoring scope. Within the fixed execution range of the business code, it dynamically manages the hardware write permissions of the target memory page, thereby directly converting illegal write behavior at runtime into page fault exceptions triggered by the Memory Management Unit (MMU). This allows the system to automatically enter debug mode the instant the damage occurs and capture the precise execution context, including the complete call stack and register states, enabling accurate localization of the root cause of the problem.

[0052] like Figure 1 As shown, traditional hardware breakpoint solutions are limited by the number of CPU debug registers, and can only monitor a few pre-defined memory addresses; such as Figure 2The dynamic page protection mechanism described in this application can set the entire 4KB physical memory page as a unified monitoring area. By forcibly aligning the target sk_buff with the page boundary during allocation and exclusively occupying the page, any write attempts to all addresses within the page (i.e., any field of sk_buff) will be captured, thereby fundamentally solving the core defect of insufficient monitoring range for "irregular page breaks".

[0053] The content of this application will be described in detail below with the aid of specific embodiments.

[0054] Figure 3 This is a flowchart illustrating a memory anomaly location method based on dynamic page protection, according to an exemplary embodiment. The memory anomaly location method 30 based on dynamic page protection includes at least steps S302 to S312.

[0055] like Figure 3 As shown, in S302, the target memory object to be monitored is obtained.

[0056] The target memory object can be a target data object in the kernel that needs to be located for memory anomalies, such as a network data buffer object, protocol data object, or other kernel data structure. In one embodiment, the target memory object can be an sk_buff structure. The target memory object to be monitored can be pre-specified according to debugging needs, or it can be automatically determined by the system based on the fault analysis results.

[0057] In S304, the target code execution interval corresponding to the target memory object is determined. For example, based on at least one of historical fault logs, system exception information, memory exception statistics, and static code analysis results, the target business module where the memory exception occurred in the target memory object is determined; the target code region in the target business module is determined; and the entry position to the exit position of the target code region is determined as the target code execution interval.

[0058] Furthermore, historical fault logs can include system crash logs, abnormal alarm information, call stack records, etc. System abnormal information can include runtime abnormal information such as illegal access exceptions, page exceptions, and pointer exceptions. Memory abnormality statistics can include the number of times, location, and associated modules of historical exceptions occurring in the target memory object. Static code analysis results can include analysis results such as out-of-bounds access risks, reference counting processing anomalies, concurrent write risks, and missing boundary checks. After determining the target code execution range based on the above analysis results, the target code execution range can be pre-fixed in the debugging runtime environment, so that when subsequent execution flows enter the target code execution range, dynamic page protection is automatically triggered without re-determining the monitoring scope during runtime, thereby improving the determinism and repeatability of the monitoring process.

[0059] In S306, in response to the execution flow entering the target code execution region, write protection is applied to the target memory page corresponding to the target memory object. In response to the execution flow entering the target code execution region, a first access control interface is invoked to apply write protection to the target memory page corresponding to the target memory object. For example, the access permissions in the page table entry corresponding to the target memory page can be modified to put the target memory page in a write-protected state.

[0060] In one embodiment, before applying write protection to the target memory page corresponding to the target memory object, the method further includes: allocating an independent target memory page for the target memory object; and performing page-aligned storage on the target memory object according to a preset page boundary, so that the target memory object exclusively occupies the target memory page.

[0061] Furthermore, the memory allocation strategy for target memory objects can be adjusted to allocate them according to preset page boundaries, ensuring that each target memory object corresponds to an independent target memory page. Since each target memory object exclusively occupies an entire target memory page, any address within the target memory object resides within the same target memory page. When the target memory page is write-protected, write access to any field or address of the target memory object can be uniformly monitored through the page-level protection mechanism without needing to predetermine specific monitoring addresses, thereby expanding the monitoring scope.

[0062] In S308, within the target code execution interval, write access operations to the target memory page are monitored.

[0063] Specifically, while the execution flow is within the target code execution interval, the target memory page is continuously kept in a write-protected state, and write access operations to the target memory page are monitored. When the execution flow only performs read operations or no write access to the target memory page occurs, the business logic continues to execute normally; when any code in the execution flow attempts to write data to the write-protected target memory page, the access permission exception handling process is entered. Since write protection applies to the entire target memory page, it is not necessary to set monitoring points for each field within the target object to cover write access behavior to all addresses within the target memory object.

[0064] In S310, when a write access to the target memory page is detected and triggers an access permission exception, the exception situation information corresponding to the access permission exception is obtained.

[0065] In one embodiment, for example, when the memory management unit detects a write operation on a target memory page that is in a non-writable state, it determines that an access permission exception has occurred; and obtains exception context information based on the exception address corresponding to the access permission exception, the processor running state, and the call relationship. The exception context information includes at least one of the following: function call stack information; processor register information; exception memory address; thread context information; and instruction address information.

[0066] Furthermore, access permission exceptions are generated when the processor's memory management unit performs access permission checks on the target memory page. When a write access request for a write-protected page is detected, the memory management unit immediately triggers a page exception. The exception handler identifies that the exception is an access permission exception generated by the monitored target memory page and automatically obtains the exception context information. In one embodiment, the exception context information may also include the currently executing thread, the processor context at the time of the exception, function call relationships, and the target instruction that caused the exception, to completely preserve the runtime context at the time of the exception and provide a basis for subsequent exception localization.

[0067] In S312, the location where the memory exception occurred is determined based on the abnormal scene information.

[0068] Specifically, the business module and function call path where the exception occurred can be determined based on the function call stack information. By combining the exception memory address, instruction address, and processor running state, the location of the illegal write can be determined, and the specific function, code region, or code location where the memory exception occurred can be further located to assist developers in completing exception analysis and problem repair. Because the exception context information is obtained in real time when the access permission exception occurs, the execution context at the time of the exception can be completely preserved, improving the accuracy of locating sporadic memory exceptions.

[0069] In one embodiment, the method further includes: in response to the execution flow exiting the target code execution region, removing the write protection of the target memory page, restoring the target memory page to a writable state. In response to the execution flow exiting the target code execution region, invoking a second access control interface to remove the write protection of the target memory page.

[0070] For example, by restoring write permissions in the corresponding page table entry of the target memory page, the target memory page can be made writable again. When the execution flow exits the target code execution area normally without any access permission exceptions, the system automatically restores the write permissions of the target memory page to ensure that subsequent business processes can access the target memory object normally. If an access permission exception occurs during execution and the exception situation information is obtained, the write permissions of the target memory page can also be restored according to the debugging process to complete a complete dynamic page protection and memory exception localization process. The entire dynamic page protection process is automatically completed around the pre-determined target code execution area without modifying the business logic code or setting monitoring points for each field inside the target memory object, thereby ensuring the monitoring scope while reducing the impact on the business operation process.

[0071] According to the memory anomaly localization method based on dynamic page protection of this application, the following steps are taken: First, a target memory object to be monitored is obtained. Then, the target code execution interval corresponding to the target memory object is determined. In response to the execution flow entering the target code execution interval, write protection is applied to the target memory page corresponding to the target memory object. Within the target code execution interval, write access operations to the target memory page are monitored. When a write access to the target memory page triggers an access permission anomaly, the anomaly scene information corresponding to the access permission anomaly is obtained. Based on the anomaly scene information, the location of the memory anomaly is determined. By dynamically binding the business code execution interval with the hardware write protection of the memory page, and utilizing the MMU anomaly mechanism, the random destructive behavior of irregular memory crashes is transformed into precise and catching deterministic anomaly events, thereby achieving automated localization of the root cause of the crash with extremely low performance overhead.

[0072] It should be clearly understood that this application describes how specific examples are formed and used, but the principles of this application are not limited to any details of these examples. Rather, based on the teachings of the disclosure of this application, these principles can be applied to many other embodiments.

[0073] Figure 4 This is a flowchart illustrating a memory anomaly location method based on dynamic page protection, according to another exemplary embodiment. Figure 4 The process shown in step 40 is... Figure 3 Supplementary description of the process shown.

[0074] like Figure 4 As shown, in S402, the memory allocation strategy of the target memory object is modified so that the target memory object is allocated memory according to a preset page boundary, so that each target memory object corresponds to an independent target memory page.

[0075] Specifically, the memory allocation logic corresponding to the target memory object can be adjusted so that the target memory object is no longer allocated using the conventional memory pool or shared memory page allocation method, but is instead allocated independently according to a preset page boundary, ensuring that each target memory object exclusively occupies its corresponding target memory page. The preset page boundary can correspond to the starting address of the system memory page, so that the target memory object is stored in the target memory page in a page-aligned manner.

[0076] Furthermore, by making the target memory object exclusively occupy the target memory page, mutual interference caused by multiple target objects sharing the same memory page can be avoided. When write protection is subsequently applied to the target memory page, it can cover the entire storage space occupied by the target memory object. This allows write access to any field, any offset, and any address within the target memory object to be uniformly monitored through the page-level protection mechanism, without the need to set monitoring points for each member within the target object. This expands the monitoring scope and improves the ability to capture random memory anomalies.

[0077] In one embodiment, the above-mentioned independent page allocation strategy can be applied only to the target memory objects to be monitored, while other memory objects not involved in debugging will still use the original memory allocation method, so as to reduce the impact of the debugging environment on the overall memory management mechanism of the system.

[0078] In S404, permission control logic is configured at the entry and exit positions of the target code execution interval to apply write protection to the target memory page when the execution flow enters the target code execution interval and to remove the write protection when the execution flow exits the target code execution interval.

[0079] Specifically, based on the target code execution interval determined in S204, a first permission control logic can be configured at the corresponding entry point of the target code execution interval, and a second permission control logic can be configured at the corresponding exit point of the target code execution interval. When the execution flow enters the target code execution interval, the first permission control logic calls the permission control interface to modify the access permissions in the corresponding page table entry of the target memory page, causing the target memory page to enter a write-protected state; when the execution flow exits the target code execution interval normally, the second permission control logic restores the write permissions in the corresponding page table entry of the target memory page, causing the target memory page to return to a writable state.

[0080] Furthermore, the permission control logic keeps the target memory page in a write-protected state only while the execution flow is within the target code execution interval. Therefore, the target memory page is only subject to access restrictions within the preset monitoring range, while other business processes outside the target code execution interval can still access the target memory object with normal permissions. This reduces the impact of long-term page protection on the normal operation of the system, while taking into account both anomaly location capabilities and system performance.

[0081] In one embodiment, the entry and exit positions may correspond to the function entry and exit points of the target code region, or other positions that can characterize the entry and exit of the execution flow into and out of the target code execution region; the permission control logic may be deployed using instrumentation, interface calling, or other methods that can achieve dynamic permission switching.

[0082] In S406, the debug runtime environment is generated based on the memory allocation strategy and the permission control logic.

[0083] Specifically, the modified target memory object memory allocation strategy and access control logic are integrated into the debug runtime environment to form a debug runtime environment with dynamic page protection capabilities. This debug runtime environment can automatically allocate memory according to independent pages when the target memory object is created, automatically enable page protection when the execution flow enters the target code execution area, and automatically restore write permissions to the target memory pages when the execution flow exits the target code execution area, thus forming a complete dynamic page protection process.

[0084] Furthermore, during the operation of the debug runtime environment, when a write access to a target memory page occurs within the target code execution interval, the processor memory management unit performs permission verification based on the access permissions of the target memory page. When a write operation is detected on a target memory page that is in a write-protected state, an access permission exception is automatically triggered, and an exception handling process is entered to obtain exception context information such as function call stack information, processor register information, exception memory address, thread context information, and instruction address information, thereby achieving automatic location of the memory exception.

[0085] Therefore, by pre-building the aforementioned debugging and running environment, the independent page allocation mechanism of the target memory object, the target code execution interval control mechanism, and the dynamic page protection mechanism can be uniformly integrated. This allows for automatic anomaly detection, anomaly scene acquisition, and anomaly location when illegal writes occur, without the need for manual setting of hardware breakpoints or extensive logging during operation. This improves the efficiency and accuracy of locating random memory anomalies.

[0086] In one embodiment, such as Figure 5 As shown, the method of this application includes a debug runtime environment construction stage and a memory anomaly online location stage. The debug runtime environment construction stage is used to pre-build a debug runtime environment with dynamic page protection capabilities, and the memory anomaly online location stage is used to automatically complete memory anomaly detection, anomaly scene acquisition, and anomaly location during the operation of the target device.

[0087] During the debugging and runtime environment construction phase, the location of memory anomalies in the target memory object is first analyzed based on historical fault logs, system crash information, system anomaly information, and historical memory anomaly statistics. This identifies the target business module or target code region where memory anomalies are most likely to occur, and the entry and exit points corresponding to the identified target code region are defined as the target code execution interval. This target code execution interval can serve as the monitoring interval for subsequent dynamic page protection and is pre-defined in the debugging and runtime environment, eliminating the need to dynamically determine the monitoring scope during operation. This ensures the determinism and repeatability of the monitoring process.

[0088] Furthermore, after determining the target code execution range, the debugging and runtime environment is customized, including modifying the memory allocation strategy of the target memory object and configuring dynamic page protection logic.

[0089] Specifically, the memory allocation path corresponding to the target memory object can be adjusted to ensure that the target memory object is stored in page alignment according to a preset page boundary, and that each target memory object exclusively occupies its corresponding target memory page. In a specific embodiment, the target memory object can be aligned according to the system page size through the attribute ((aligned(PAGE_SIZE))) provided by the GCC compiler, so that the target memory object corresponds to a complete physical memory page, providing a memory foundation for subsequent dynamic page protection based on page-level access control.

[0090] After modifying the memory allocation strategy, permission control logic is configured at the pre-determined entry and exit points of the target code execution interval. When the execution flow enters the target code execution interval, the first permission control logic calls the page permission control interface to apply write protection to the target memory page; when the execution flow exits the target code execution interval, the second permission control logic restores the write permission of the target memory page. In a specific embodiment, the `set_memory_ro` and `set_memory_rw` interfaces provided by the Linux kernel can be called respectively to modify the access permissions in the corresponding page table entries of the target memory page, making the target memory page in a read-only state and a writable state, respectively. Since the permission control logic is pre-embedded in the target code execution interval, dynamic page protection can be automatically enabled and disabled with the execution flow without modifying the business processing logic of the business module.

[0091] After completing the above modifications, build the debugging and runtime environment. For example... Figure 6As shown, in one embodiment, kernel compilation parameters can be configured and kernel debugging functionality enabled to compile the modified kernel source code into a dedicated debugging runtime environment. Furthermore, kernel debugger (KDB) support can be configured, enabling the debugging runtime environment to simultaneously possess dynamic page protection capabilities and the ability to automatically acquire exception context.

[0092] After the debugging and running environment is built, it is deployed to the target device to be tested, so that the target device runs in a debugging environment with dynamic page protection capabilities.

[0093] When the business application is running normally, if the execution flow has not yet entered the target code execution area, the target memory object will be read and written according to normal access permissions. Once the execution flow enters the target code execution area, the system automatically calls the first permission control logic to set the target memory page to write-protected status.

[0094] In one embodiment, when no write access to the target memory page occurs within the target code execution interval, the business program continues execution according to the normal flow. When the execution flow exits the target code execution interval, the system automatically calls the second permission control logic to restore the write permission in the corresponding page table entry of the target memory page, making the target memory page writable again, and the business process can continue to run without manual intervention.

[0095] In another embodiment, when any code within the target code execution interval attempts to perform a write operation on a target memory page that is in a write-protected state, the processor's memory management unit (MMU) performs an access check based on the access permissions of the target memory page and immediately triggers a page fault. Subsequently, the exception handler identifies that the page fault is an access permission exception generated by the monitored target memory page and enters the exception handling process.

[0096] Furthermore, during exception handling, the system can automatically enter a debugging environment and acquire exception context information. This exception context information may include function call stack information, processor register information, exception memory address, thread context information, and instruction address information. Specifically, the function call stack can completely record the call relationships at the time of the illegal write; the processor register information includes the processor's operating state, such as general-purpose registers, program counter, or instruction pointer; and the exception memory address is used to record the target address that triggered the access permission exception.

[0097] Based on the obtained abnormal situation information, developers can determine the business module, function call relationship, target code area and specific code location corresponding to the illegal write, thereby realizing the rapid location and defect repair of the target memory object memory abnormality.

[0098] Therefore, this application, by pre-constructing a debugging and running environment with dynamic page protection capabilities and integrating the target code execution range, independent page memory allocation strategy, and dynamic page protection mechanism, enables the target device to automatically trigger hardware page exceptions when illegal writes occur without the need for extensive log instrumentation or manual setting of hardware breakpoints during operation. This allows for the real-time acquisition of complete exception context information and accurate location of the memory exception, thereby improving the efficiency and accuracy of random memory exception location.

[0099] In summary, this application dynamically enables page-level write protection when the execution flow enters the target code execution area, and automatically restores write permissions when the execution flow exits the target code execution area, thus ensuring that the target memory object is dynamically page-protected within a preset monitoring range. When an illegal write access to the target memory page occurs, the page protection mechanism of the processor memory management unit (MMU) can be used to trigger an access permission exception in real time, and automatically obtain exception context information such as function call stack, processor registers, exception memory address, thread context, and instruction address, thereby accurately locating the business module, function, and code location where the memory exception occurred.

[0100] Compared to existing technologies, this application eliminates the need to predetermine specific abnormal write addresses, enabling unified monitoring of illegal write accesses at any location within the target memory object. This effectively solves the problems of locating random, sporadic, and difficult-to-reproduce memory anomalies. Furthermore, this application utilizes the processor hardware page protection mechanism to achieve real-time capture of anomalies at the moment of occurrence, avoiding the difficulties in location caused by log instrumentation, manual analysis, or limited hardware breakpoints, thus improving the real-time performance and accuracy of anomaly location. In addition, the dynamic page protection of this application only takes effect within the preset target code execution range, requiring no modification to business processing logic, remaining transparent to the business operation process, and incurring controllable system resource overhead. When a memory anomaly occurs, this application can automatically output complete anomaly context information, providing developers with accurate and reliable problem location data, significantly improving the diagnostic efficiency and location certainty of sporadic memory anomalies in complex systems.

[0101] Those skilled in the art will understand that all or part of the steps of the above embodiments are implemented as a computer program executed by a CPU. When the computer program is executed by the CPU, it performs the functions defined by the method provided in this application. The program can be stored in a computer-readable storage medium, such as a read-only memory, a magnetic disk, or an optical disk.

[0102] Furthermore, it should be noted that the above figures are merely illustrative representations of the processes included in the method according to exemplary embodiments of this application, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0103] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0104] Figure 7 This is a block diagram illustrating a memory anomaly location device based on dynamic page protection, according to an exemplary embodiment. Figure 7 As shown, the memory anomaly location device 70 based on dynamic page protection includes: an object module 702, an interval module 704, a write protection module 706, a detection module 708, an information module 710, and a location module 712. The memory anomaly location device 70 based on dynamic page protection may also include: a recovery module 714 and an environment module 716.

[0105] Object module 702 is used to obtain the target memory object to be monitored; The interval module 704 is used to determine the target code execution interval corresponding to the target memory object; Write protection module 706 is used to apply write protection to the target memory page corresponding to the target memory object in response to the execution flow entering the target code execution area; The detection module 708 is used to monitor write access operations to the target memory page within the target code execution interval; The information module 710 is used to obtain the abnormal situation information corresponding to the abnormal access permission when a write access to the target memory page is detected to trigger an abnormal access permission. The positioning module 712 is used to determine the location where the memory abnormality occurred based on the abnormal scene information.

[0106] The recovery module 714 is used to release the write protection of the target memory page and restore the target memory page to a writable state in response to the execution flow exiting the target code execution interval.

[0107] The environment module 716 is used to modify the memory allocation strategy of the target memory object, so that the target memory object is allocated memory according to a preset page boundary, so that each target memory object corresponds to an independent target memory page; permission control logic is configured at the entry and exit positions of the target code execution interval, so as to apply write protection to the target memory page when the execution flow enters the target code execution interval, and remove the write protection when the execution flow exits the target code execution interval; the debugging runtime environment is generated based on the memory allocation strategy and the permission control logic.

[0108] According to the memory anomaly localization device based on dynamic page protection of this application, the following steps are taken: First, a target memory object to be monitored is acquired. Then, the target code execution interval corresponding to the target memory object is determined. In response to the execution flow entering the target code execution interval, write protection is applied to the target memory page corresponding to the target memory object. Within the target code execution interval, write access operations to the target memory page are monitored. When a write access to the target memory page triggers an access permission anomaly, an anomaly scene information corresponding to the access permission anomaly is acquired. Based on the anomaly scene information, the location of the memory anomaly is determined. By dynamically binding the business code execution interval with the hardware write protection of the memory page, and utilizing the MMU anomaly mechanism, the random destructive behavior of irregular memory crashes is transformed into precise and catching deterministic anomaly events, thereby achieving automated localization of the root cause of the crash with extremely low performance overhead.

[0109] Figure 8 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0110] The following reference Figure 8 To describe an electronic device 800 according to this embodiment of the present application. Figure 8 The electronic device 800 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0111] like Figure 8 As shown, the electronic device 800 is presented in the form of a general-purpose computing device. The components of the electronic device 800 may include, but are not limited to: at least one processing unit 810, at least one storage unit 820, a bus 830 connecting different system components (including storage unit 820 and processing unit 810), a display unit 840, etc.

[0112] The storage unit stores program code that can be executed by the processing unit 810, causing the processing unit 810 to perform the steps described in this specification according to various exemplary embodiments of this application. For example, the processing unit 810 can perform actions such as... Figure 3 , Figure 4 The steps are shown in the figure.

[0113] The storage unit 820 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 8201 and / or a cache storage unit 8202, and may further include a read-only memory unit (ROM) 8203.

[0114] The storage unit 820 may also include a program / utility 8204 having a set (at least one) program module 8205, such program module 8205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0115] Bus 830 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0116] Electronic device 800 can also communicate with one or more external devices 800' (e.g., keyboard, pointing device, Bluetooth device, etc.), enabling users to communicate with devices that interact with electronic device 800, and / or any device (e.g., router, modem, etc.) that allows electronic device 800 to communicate with one or more other computing devices. This communication can be performed via input / output (I / O) interface 850. Furthermore, electronic device 800 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 860. Network adapter 860 can communicate with other modules of electronic device 800 via bus 830. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 800, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0117] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software, or by combining software with necessary hardware. Therefore, as... Figure 9 As shown, the technical solution according to the embodiments of this application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, mobile hard drive, etc.) or on a network, and includes several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the above-described method according to the embodiments of this application.

[0118] The software product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0119] The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0120] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0121] The aforementioned computer-readable medium carries one or more programs. When the one or more programs are executed by a device, the computer-readable medium performs the following functions: acquiring a target memory object to be monitored; determining a target code execution interval corresponding to the target memory object; applying write protection to a target memory page corresponding to the target memory object in response to an execution flow entering the target code execution interval; monitoring write access operations to the target memory page within the target code execution interval; acquiring abnormal context information corresponding to the abnormal access permission when a write access to the target memory page triggers an abnormal access permission; and determining the location where the memory abnormality occurred based on the abnormal context information.

[0122] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0123] Through the description of the above embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0124] Exemplary embodiments of this application have been specifically shown and described above. It should be understood that this application is not limited to the detailed structures, arrangements, or implementation methods described herein; rather, this application is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended claims.

Claims

1. A method for locating memory anomalies based on dynamic page protection, characterized in that, include: Obtain the target memory object to be monitored; Determine the target code execution interval corresponding to the target memory object; In response to the execution flow entering the target code execution region, write protection is applied to the target memory page corresponding to the target memory object; Within the target code execution interval, monitor write access operations to the target memory page; When a write access to the target memory page is detected and triggers an access permission exception, the exception situation information corresponding to the access permission exception is obtained. The location where the memory error occurred is determined based on the abnormal scene information.

2. The method as described in claim 1, characterized in that, Also includes: In response to the execution flow exiting the target code execution region, the write protection of the target memory page is released, restoring the target memory page to a writable state.

3. The method as described in claim 1, characterized in that, Determining the target code execution interval corresponding to the target memory object includes: Based on at least one of the following: historical fault logs, system anomaly information, memory anomaly statistics, and static code analysis results, determine the target business module where the target memory object has experienced a memory anomaly. Identify the target code region within the target business module; The entry and exit positions of the target code region are defined as the target code execution interval.

4. The method as described in claim 1, characterized in that, Before applying write protection to the target memory page corresponding to the target memory object, the method further includes: Allocate a separate target memory page for the target memory object; The target memory object is stored in page alignment according to a preset page boundary so that the target memory object exclusively occupies the target memory page.

5. The method as described in claim 1, characterized in that, Applying write protection to the target memory page corresponding to the target memory object includes: Modify the access permissions in the page table entry corresponding to the target memory page to put the target memory page in a write-protected state.

6. The method as described in claim 1, characterized in that, In response to the execution flow entering the target code execution region, write protection is applied to the target memory page corresponding to the target memory object, including: In response to the execution flow entering the target code execution region, the first permission control interface is invoked to apply write protection to the target memory page corresponding to the target memory object.

7. The method as described in claim 1, characterized in that, When a write access to the target memory page is detected, triggering an access permission exception, the exception context information corresponding to the access permission exception is obtained, including: When the memory management unit detects a write operation on a target memory page that is in a non-writable state, it determines that an access permission exception has occurred. The abnormal scene information is obtained based on the abnormal address corresponding to the abnormal access permission, the processor running state, and the call relationship. The abnormal scene information includes at least one of the following: function call stack information; processor register information; abnormal memory address; thread context information; and instruction address information.

8. The method as described in claim 2, characterized in that, In response to the execution flow exiting the target code execution region, the write protection of the target memory page is released, including: In response to the execution flow exiting the target code execution region, the second permission control interface is invoked to remove the write protection of the target memory page.

9. The method as described in claim 1, characterized in that, The method runs in a pre-built debug runtime environment, which includes: Modify the memory allocation strategy of the target memory object so that the target memory object is allocated memory according to the preset page boundary, so that each target memory object corresponds to an independent target memory page; Access control logic is configured at the entry and exit points of the target code execution interval to apply write protection to the target memory page when the execution flow enters the target code execution interval and to remove the write protection when the execution flow exits the target code execution interval. The debugging and running environment is generated based on the memory allocation strategy and the permission control logic.

10. A memory anomaly location device based on dynamic page protection, characterized in that, include: The object module is used to obtain the target memory object to be monitored; The interval module is used to determine the target code execution interval corresponding to the target memory object; The write protection module is used to apply write protection to the target memory page corresponding to the target memory object in response to the execution flow entering the target code execution area; The detection module is used to monitor write access operations to the target memory page within the target code execution interval; The information module is used to obtain the abnormal situation information corresponding to the abnormal access permission when a write access to the target memory page is detected to trigger an abnormal access permission. The location module is used to determine the location where the memory exception occurred based on the abnormal scene information.

Images