Memory management method and server

Abstract

The invention provides a memory management method and a server, and the method comprises the steps: obtaining a feature code of a memory fault after receiving the interruption of the memory fault; whether the feature codes exist in a BPF mapping table or not is matched, the BPF mapping table is a mapping table of a memory protection rule list in a kernel, and the memory protection rule list is used for describing the feature codes of the memory faults concerned by the user; and under the condition that the feature code exists in the BPF mapping table, executing a fault processing strategy on the memory fault. According to the method, the memory fault interruption is received, the feature code is obtained, the BPF mapping table is matched, and the predefined fault processing strategy is executed when the feature code is matched, so that quick response and accurate processing when the memory fault occurs are realized. According to the scheme, the stability and reliability of the server are improved, the influence of the memory fault on the system performance is reduced, the accuracy and efficiency of fault processing are improved, meanwhile, the protection capability of the memory fault is enhanced, and it is ensured that equipment can continuously and stably run under the condition of the memory fault.

Description

Technical Field

[0001] The present application relates to the technical field of servers, and in particular to a memory management method and a server. Background Art

[0002] Memory is an important component used to store data and programs in computing devices. Taking servers as an example, memory plays a vital role. Servers usually need to process a large amount of data and requests, and the performance of memory directly affects the operating efficiency and response speed of the server. Sufficient memory capacity and high-performance memory can improve the processing power of the server, reduce data access latency, and improve the stability and reliability of the system.

[0003] Memory failures are common in servers. Memory failures can cause system crashes or data loss, affecting the normal operation of the server and data integrity. In addition, memory failures may cause performance degradation, slow down server response speed, and affect business functions. Therefore, memory fault detection and fault handling are crucial to the stability of server operation. Summary of the invention

[0004] In view of this, an embodiment of the present application provides a memory management method and a server.

[0005] In a first aspect, an embodiment of the present application provides a memory management method, including:

[0006] After receiving a memory fault interrupt, obtaining a feature code of the memory fault, wherein the feature code is used to describe fault information of the memory fault;

[0007] Match whether the feature code exists in the Berkeley Packet Filter (BPF) mapping table, where the BPF mapping table is a mapping table of a memory protection rule list in the kernel, and the memory protection rule list is used to describe feature codes of memory faults that the user is concerned about;

[0008] In a case where the feature code exists in the BPF mapping table, a fault handling strategy is executed on the memory fault.

[0009] In the embodiment of the present application, by receiving the memory fault interrupt, obtaining the feature code and matching the BPF mapping table, the predefined fault handling strategy is executed when the feature code is matched, so as to achieve rapid response and accurate processing when the memory fault occurs. This solution improves the stability and reliability of the server, reduces the impact of memory faults on system performance, improves the accuracy and efficiency of fault handling, and enhances the protection capability of memory faults, ensuring that the server can continue to operate stably in the event of a memory fault.

[0010] In a possible implementation, before receiving the interruption of the memory failure, the method further includes:

[0011] A stub of a rule matching function is set in a memory management function; wherein the memory management function is used to isolate the memory fault described by the memory protection rule list; and the rule matching function is used to traverse the BPF mapping table to determine whether the feature code exists.

[0012] In the embodiment of the present application, by setting the stub of the rule matching function in the memory management function, the rule matching function can be set in advance before receiving the memory fault interrupt. After receiving the interrupt, when the memory management function is executed to the rule matching function, the BPF mapping table can be efficiently traversed to timely identify the feature code of the memory fault, thereby isolating the fault described in the memory protection rule list. The system's protection capability against memory faults is enhanced, further ensuring the stability and reliability of the server.

[0013] In a possible implementation, setting a stub of the rule matching function in the memory management function includes:

[0014] Based on the extended Berkeley packet filter eBPF, the memory management function calls the interface of the rule matching function.

[0015] In the embodiment of the present application, by attaching the call interface of the rule matching function to the memory management function based on the extended Berkeley packet filter mechanism, efficient fault signature matching is achieved. This integration improves the system's ability to detect memory faults, enabling real-time identification and response to potential faults during the memory management process, thereby enhancing the effect of memory protection and the overall stability and reliability of the server.

[0016] In a possible implementation, the rule matching function adopts a kernel security module LSM architecture.

[0017] In the embodiment of the present application, the kernel security module (LSM) architecture is used to implement the rule matching function, thereby enhancing the security and flexibility of memory fault detection. The LSM architecture allows dynamic insertion of security checks at the kernel level, so that rule matching can be performed at a higher security level, ensuring that the system's response to memory faults is not only efficient but also has stronger protection capabilities, further improving the stability and overall security of the server.

[0018] In a possible implementation, before receiving the interruption of the memory failure, the method further includes:

[0019] Load an extended Berkeley packet filter (eBPF) program to load the memory protection rule list into the kernel to obtain the BPF mapping table.

[0020] In the embodiment of the present application, by loading the eBPF program, the memory protection rule list is dynamically loaded into the kernel, thereby forming a BPF mapping table. This process enables the kernel to access and apply memory protection rules in real time, improves the speed and accuracy of fault detection, reduces the switching overhead between user mode and kernel mode, enhances the system's ability to protect against memory failures, and ensures the stability and reliability of the server when a failure occurs.

[0021] In a possible implementation manner, the memory protection rule list includes at least a feature code of a software recoverable operation optional error SRAO.

[0022] In the embodiment of the present application, by writing the characteristic code of the optional software recoverable operation error (SRAO) into the memory protection rule list, the system can actively identify and handle this type of specific error. This rule list containing the SRAO characteristic code enhances the pertinence of memory fault handling, helps reduce system crashes or data loss caused by SRAO errors, and thus improves the overall stability and reliability of the device.

[0023] In a possible implementation, the memory protection rule list is stored in a system configuration file; wherein the system configuration file is a file loaded during the startup of an operating system.

[0024] In the embodiment of the present application, by saving the memory protection rule list in the system configuration file loaded during the operating system startup process, the management and update of the rules are made more convenient and efficient. It is ensured that the memory protection rules are automatically loaded when the system starts, thereby improving the system's protection capabilities and response speed, reducing the need for manual intervention, and enhancing overall security and stability.

[0025] In a possible implementation, when the memory safety protection list is modified, the method further includes:

[0026] Reload the eBPF program to load the modified memory protection rule list into the kernel to obtain an updated BPF mapping table, so as to perform memory management according to the updated BPF mapping table.

[0027] In the embodiment of the present application, when the memory security protection list is modified, the eBPF program is reloaded, and the updated rule list is dynamically loaded into the kernel to form an updated BPF mapping table. This mechanism ensures that the system can adapt to new memory protection rules in real time, improve the flexibility and accuracy of memory management, enhance the defense capability against emerging security threats, and thus improve the security and stability of the overall system.

[0028] In a possible implementation, the extended Berkeley packet filter program runs as a daemon process.

[0029] In the embodiment of the present application, by running the extended Berkeley Packet Filter (eBPF) program as a daemon process, continuous monitoring and dynamic management of memory protection rules are achieved. This design enables the eBPF program to automatically handle memory security events in the background and respond to rule changes in real time, improving the system's adaptive capabilities and security, ensuring that effective measures can be taken quickly in the face of new threats to reduce potential risks.

[0030] In a possible implementation, the calling function is a kernel security module LMS stub.

[0031] In the embodiment of the present application, by setting the calling function as an LMS stub, the monitoring and control capabilities of the system kernel operation are enhanced. It allows the insertion of a custom security check or response mechanism when a specific event occurs, thereby improving the security and stability of the kernel and ensuring that the system can take corresponding protective measures in a timely manner when facing potential security threats.

[0032] In a second aspect, an embodiment of the present application provides a memory management device, the device comprising:

[0033] An acquisition module, configured to acquire a feature code of the memory fault after receiving an interrupt of the memory fault, wherein the feature code is used to describe fault information of the memory fault;

[0034] A matching module, used for matching whether the feature code exists in a Berkeley Packet Filter (BPF) mapping table, where the BPF mapping table is a mapping table of a memory protection rule list in a kernel, and the memory protection rule list is used for describing feature codes of memory faults that a user is concerned about;

[0035] A processing module is used to execute a fault processing strategy for the memory fault when the feature code exists in the BPF mapping table.

[0036] In one possible implementation, the device also includes a setting module, which is used to set a pile point of a rule matching function in a memory management function before receiving an interruption of a memory fault; wherein the memory management function is used to isolate the memory fault described by the memory protection rule list; and the rule matching function is used to traverse the BPF mapping table to see whether the feature code exists.

[0037] In a possible implementation, the setting module is specifically configured to attach the calling interface of the rule matching function to the memory management function based on an extended Berkeley packet filter mechanism.

[0038] In a possible implementation, the rule matching function adopts a kernel security module LSM architecture.

[0039] In one possible implementation, the device also includes a loading module, and before receiving the interrupt of the memory failure, the loading module is used to load the extended Berkeley packet filter eBPF program to load the memory protection rule list into the kernel to obtain the BPF mapping table.

[0040] In a possible implementation manner, the memory protection rule list includes at least a feature code of a software recoverable operation optional error SRAO.

[0041] In a possible implementation, the memory protection rule list is stored in a system configuration file; wherein the system configuration file is a file loaded during the startup of an operating system.

[0042] In one possible implementation, when the memory security protection list is modified, the loading module is also used to reload the eBPF program to load the modified memory protection rule list into the kernel to obtain an updated BPF mapping table, so as to perform memory management according to the updated BPF mapping table.

[0043] In a possible implementation, the extended Berkeley packet filter program runs as a daemon process.

[0044] In a third aspect, an embodiment of the present application provides a server, comprising a processor, and a memory communicatively connected to the processor;

[0045] The memory is used to store computer-executable instructions;

[0046] The processor is used to execute the computer-executable instructions stored in the memory to implement the memory management method described in any embodiment of the first aspect above.

[0047] In a fourth aspect, an embodiment of the present application provides a server cluster, wherein the server cluster includes a management node, a computing node, and a storage node, wherein the storage node includes internal storage of the server cluster and external storage of the server cluster; the management node is used to implement the memory management method described in any embodiment of the first aspect above.

[0048] In a fifth aspect, an embodiment of the present application provides a computer storage medium, in which code is stored. When the code is executed, the device executing the code implements the memory management method described in any one of the first aspects above.

[0049] It should be understood that the description of technical features, technical solutions, beneficial effects or similar language in this application does not imply that all features and advantages can be realized in any single embodiment. On the contrary, it is understood that the description of features or beneficial effects means that specific technical features, technical solutions or beneficial effects are included in at least one embodiment. Therefore, the description of technical features, technical solutions or beneficial effects in this specification does not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions and beneficial effects described in the present embodiment can also be combined in any appropriate manner. Those skilled in the art will understand that the embodiment can be realized without one or more specific technical features, technical solutions or beneficial effects of a specific embodiment. In other embodiments, additional technical features and beneficial effects can also be identified in a specific embodiment that does not embody all embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the technical solutions in this embodiment or the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0051] Figure 1 A schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0052] Figure 2 A software architecture diagram of a computing device provided in an embodiment of the present application;

[0053] Figure 3 A flowchart of a memory management method provided in an embodiment of the present application;

[0054] Figure 4 A schematic diagram of the structure of a memory management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0055] It should be noted that the embodiments described in this application are only part of the embodiments of this application, rather than all the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0056] In order to make the following embodiments clear, the technical terms involved in this application are first introduced.

[0057] The extended Berkeley Packet Filter (eBPF) is a program code pre-written for security protection functions, which is used to access the memory protection rules stored in the packet filter map (Berkeley Packet Filter Map, BPF Map) to provide security protection for the memory. In an embodiment of the present application, the user can edit the memory protection rules through the user-state application, and the user-state application can interact with the eBPF program in the kernel through the system call of the eBPF program, and the edited memory protection rules can be mapped to the BPF Map in the kernel through the mapping relationship between the user state and the kernel. When the kernel eBPF program (KerneleBPF) is loaded in the kernel, the edited memory protection rules in the BPF Map can be read to implement security protection for the memory.

[0058] BPF Map is a structure used to store data in the Linux kernel and is a data structure used by the kernel. BPF Map supports users to read, write and modify data in BPF Map through eBPF programs when the system is running. Among them, arrays and hash tables are two common map types, both of which support data modification and access during system operation. In an embodiment of the present application, memory protection rules are stored in the BPF Map in the form of an array. BPF Map is usually generated when the eBPF program is created and loaded into the kernel.

[0059] Discretionary Access Control (DAC) is an access control mechanism that autonomously determines the control rights of a subject (such as a user) over an object (such as a file, resource, or program). In this access control model, the subject has the autonomy to control access to the objects it owns and can decide on its own the rights to access the objects. In an embodiment of the present application, the eBPF program can be access-edited based on the autonomous access control function, and then the relevant programs of the memory protection function can be added to the eBPF program.

[0060] Linux Security Modules (LSM) is an architecture in the Linux kernel that provides a standard, pluggable security framework. Through LSM, developers can write custom security modules and load them into kernel programs to implement various security policies and mechanisms. LSM can provide autonomous access control functions.

[0061] In order to detect and manage memory failures, the embodiment of the present application first proposes an implementation method, which uses memory protection rules as system startup parameters, and turns on the memory periodic inspection function and loads the memory protection rules during the process of loading the Basic Input Output System (BIOS) when the computing device starts. During the operation of the computing device, the memory controller performs memory management based on the memory protection rules. However, in this embodiment, the memory protection rules are not convenient for users to configure or adjust. When the user needs to edit the memory protection rules, the edited memory protection rules need to be used as system startup parameters, and the computing device needs to be restarted to load the edited memory protection rules. However, restarting the computing device requires interrupting the task being executed, affecting business continuity. In addition, the system startup parameters have certain size requirements, that is, there is a limit on the number of memory protection rules, and it is impossible to configure more abundant protection rules, which may have a certain impact on the reliability and accuracy of memory security protection.

[0062] To address this problem, an embodiment of the present application further provides a memory management method, which reflects the user-configured memory protection rule list in the kernel in the form of a BPF Map (also called a BPF mapping table). After receiving a memory fault interrupt, by matching the feature code of the memory fault with the feature code in the BPF Map, if the feature code of the memory fault is the feature code recorded in the BPF Map, the memory fault is processed accordingly. In an embodiment of the present application, memory management can be performed based on user-defined memory protection rules to meet the user's personalized needs.

[0063] In addition, based on the eBPF mechanism, memory protection rules can be modified and BPFMap can be updated during the operation of the operating system without restarting the computing device; BPFMap can also store more memory protection rules and corresponding feature codes. Users can set as many memory protection rules as possible based on the actual needs of the protection scenario, thereby improving the coverage of security protection scenarios and the security protection level.

[0064] The following is an example of an application scenario provided in the embodiments of the present application.

[0065] The embodiments of the present application can be applied to a scenario where a computing device inspects memory based on memory protection rules, and can also be applied to a scenario where a user modifies memory protection rules through a computing device. The computing device can be a server, a computer, or a device deployed as a virtualization (such as a container or a virtual machine, etc.), but is not limited thereto.

[0066] As an example, an embodiment of the present application provides a structural diagram of a computing device.

[0067] like Figure 1As shown, the computing device 100 may include a processor 110, a storage 120, a memory 130, and a communication interface 140, and the storage 120, the memory 130, and the communication interface 140 may be communicatively connected to the processor 110 via a bus 160. In addition, the computing device 100 may also include a memory controller 150, and the memory controller 150 may be connected to hardware such as the processor 110, the storage 120, and the memory 130 via the bus 160. After the memory inspection function is enabled in the BIOS, the memory controller 150 may periodically inspect the memory 130 and record the feature code (fault information used to describe the memory fault, such as the fault type) in a register.

[0068] Processor 110 (or central processing unit (CPU)) is the computing core and control core of computing device 100. It can be used to process access requests from outside computing device 100, and also to process events and requests generated inside computing device 100, such as performing memory fault processing (such as isolation) according to BPF Map and feature codes in registers.

[0069] The memory 120 can provide storage resources for the computing device 100 for storing computer program instructions, including a computer operating system (operating system, OS) 101, firmware (such as BIOS) 102, eBPF program 103 and other programs. The memory 120 is a disk or other types of storage media, such as a solid state drive or a shingled magnetic recording hard disk, etc. It can also be a universal flash storage (UFS) or a read-only memory (ROM), or any other computer-readable storage medium that can be used to carry or store program codes in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto.

[0070] Memory 130 refers to an internal memory that directly exchanges data with the processor. It can read and write data at any time to serve as a temporary data storage for OS101 or other running programs. Memory 130 can be a random access memory, for example, the random access memory is a dynamic random access memory (DRAM), or a storage class memory (SCM), or a static random access memory (SRAM), etc. Memory 130 can also be a dual in-line memory module or a dual-line memory module (DIMM), that is, a module composed of DRAM. In actual applications, the computing device 100 may include multiple memories 130, and the types of the multiple memories 130 may be different.

[0071] Memory 130 may include multiple memory pages. Memory page is the basic unit for processor 110 to manage memory 130. Typically, memory 130 is divided into fixed-size blocks, which are called "pages". In most modern operating systems, the size of memory pages is generally 4KB, 2MB or larger, depending on the architecture and configuration of the system. When a process needs to allocate memory, processor 110 allocates these memory pages to the process. Multiple memory pages can be combined to form a larger memory area for use by the program. Processor 110 can manage each memory page separately.

[0072] As an example, the software architecture diagram of a computing device provided in an embodiment of the present application is as follows. Figure 2 As shown, the software architecture includes at least two parts: user mode and kernel.

[0073] In the user state, various applications that provide business functions for users are run, such as applications that can edit memory protection rules. Users can edit memory protection rules through applications (such as adding or deleting). After the editing is completed, the memory protection rules edited by the user are converted into a hexadecimal array that can be recognized by BPF Map by loading the eBPF program to obtain a list of memory protection rules, such as Figure 2 In the memory protection rule list shown in the figure, "0x9d000000000000c0" and "0x9d000000000000c2" are the signature codes corresponding to two different memory protection rules. Through the BPF system call (bpf syscall) and memory mapping (memmap) provided by the kernel, the mapping between the user-mode memory protection rule list and the kernel's BPF Map can be achieved.

[0074] The kernel runs the memory management function and the rule matching function to check whether the feature code corresponding to each memory protection rule in the BPF Map is the same as the feature code of the memory fault, so as to determine whether the memory fault is an object that needs to be protected, and then implement fault handling. The calling interface of the rule matching function is attached to the memory management function based on the eBPF mechanism. In an embodiment of the present application, each memory protection rule is described in the form of a feature code in the BPF Map. By running the eBPF program in the kernel, the memory protection rule list in the user state is loaded into the kernel to obtain the corresponding BPF Map.

[0075] The memory protection rule list records multiple memory protection rules for uncorrectable errors (UCE), and correspondingly, the BPF Map records multiple feature codes corresponding to the memory protection rules for uncorrectable errors. The feature code is used to describe the fault information of the memory fault, and the fault information includes the fault type of the faulty memory.

[0076] The memory management function includes a fault detection function, a rule matching function and a fault handling function in sequence. After receiving the interrupt of the memory fault, the feature code of the memory fault is first obtained from the register by loading the fault detection function; then, the rule matching function is recorded to match whether there is a feature code of the memory fault in the BPF Map; finally, according to the matching result, the fault handling function is loaded to handle the memory fault. In an embodiment of the present application, the BPF Map includes feature codes corresponding to at least two SRAO errors. If the BPF Map includes the feature code of the memory fault, it indicates that the memory fault is an SRAO error. The faulty memory is isolated and processed by recording the fault handling function.

[0077] In the embodiment of the present application, a calling interface of the rule matching function is added to the memory management function based on the eBPF mechanism, such as a function pointer (such as an LSM stub), and the calling interface indicates the address of the rule matching function, and the rule matching function can be called through the calling interface. Figure 2 As shown, the calling interface in the memory management function is an LSM stub. By adding a calling interface, the processor 110 can load and execute the rule matching function in combination with the BPF Map for fault matching during the execution of the memory management function. As an example, the embodiment of the present application adds an LSM stub to the memory management function to provide an interface, and during the operation of the memory management function, when it runs to the LSM stub, it can jump to the execution rule matching function. In other words, the LSM stub can be understood as an extension point, which extends the memory management function based on the eBPF mechanism.

[0078] The memory management method provided by the embodiment of the present application is introduced below in conjunction with the accompanying drawings. Figure 3 As shown, the method includes:

[0079] S301: The processor 110 writes the rule matching function into the memory management function through the eBPF mechanism.

[0080] The processor 110 modifies the memory management function based on the eBPF mechanism, introduces a rule matching function into the memory management function, and then in the process of loading the memory management function, memory management can be performed according to the BPF Map through the rule matching function.

[0081] In one implementation, the rule matching function can be completely attached to the memory management function; in another implementation, the calling interface of the rule matching function can be written into the memory management function. It should be noted that, no matter which method is adopted, the rule matching function is loaded after the fault detection function is loaded and before the fault handling function is loaded.

[0082] In an embodiment of the present application, the rule matching function can adopt the LSM architecture. The LSM architecture allows the rule matching function to be integrated in a modular manner. This means that different security modules can be added, deleted or replaced without modifying the kernel core code. This flexibility makes the implementation and update of memory protection rules more convenient and efficient. In addition, the LSM architecture provides a set of standard interfaces so that various security modules can interact with the kernel in a unified manner. This standardized approach improves the compatibility between different security modules, making it easier for the rule matching function to be integrated into the memory management function without conflicting with other security functions.

[0083] S302: The processor 110 loads the eBPF program and loads the memory protection rule list into the kernel to obtain a BPF Map.

[0084] Before performing memory security protection, you need to load the memory protection rules into the kernel and obtain the BPF Map of the memory protection rule list in the kernel so that fault handling can be performed according to the memory protection rules when the system is running. The memory protection rule list includes one or more memory protection rules. The memory protection rule includes the fault type and the feature code corresponding to the fault type. The memory protection rule list can be pre-configured when the server leaves the factory, or it can be the memory protection rules edited by the user during the last operation of the server.

[0085] The memory protection rule list is saved in the system configuration file. The system configuration file refers to the file that the operating system needs to load during startup. The system configuration file includes not only the memory protection rule list, but also other startup parameters required during the operating system startup process.

[0086] As an example, memory protection rules can be recorded in a separate file, such as in the / etc / mce_isolate.conf file. Storing memory protection rules in a separate file has higher reliability and is easier to manage and maintain. As another example, memory protection rules can be recorded in a file with other system startup parameters, which will make the file structure more concise.

[0087] In a possible implementation, the memory protection rules in the file are loaded into the kernel by enabling the eBPF program. The file path of the file storing the memory protection rules is recorded in the eBPF program. After the eBPF program is enabled, the eBPF program reads the memory protection rules according to the file path and loads them into the kernel to obtain the corresponding BPF Map.

[0088] In one possible implementation, the eBPF program can be run as a daemon process and managed by systemd. systemd can automatically start the daemon process when the system starts, ensuring that the eBPF program is always running. Running the eBPF program as a daemon process and managing it by systemd can not only ensure the stable operation of the eBPF program, improve the security and reliability of the system, but also facilitate maintenance and management by the system administrator.

[0089] It should be noted that the above steps S301 and S302 are preparatory steps for the memory management method provided in the embodiment of the present application, and do not need to be executed every time memory management is performed. They can be executed once after the server is started, and do not need to be repeated before each memory management.

[0090] S303: The processor 110 receives an interruption of a memory failure and obtains a feature code of the memory failure.

[0091] After the memory inspection function is turned on, the processor 110 or the memory controller 150 performs periodic inspections on the memory 130. Taking the memory controller 150 as an example, the memory controller 150 will periodically read the data in the memory 130 to check whether there is an error. If the memory controller 150 detects a fault in the memory 130, it will generate an interrupt of the memory fault and record detailed error information in the register, that is, record the feature code of the memory fault and the physical address of the faulty memory. This information usually includes the error type, the hardware component where the error occurred, and other related context information.

[0092] There are many possible situations for memory failure. For repairable errors (such as single-bit errors), the processor 110 can automatically correct and write back the repaired data. For unrepairable errors (such as SRAO errors), the processor 110 needs to isolate the failed memory.

[0093] A UCE error is a serious memory error, indicating that the data in the memory is corrupted and cannot be automatically repaired by technologies such as Error Checking and Correcting (ECC). UCE errors may cause system crashes, data loss, or critical mission failures. Examples of UCE errors include multi-bit errors (multiple bits in the memory are simultaneously faulty), row and column errors (errors in the entire memory row or column), permanent hardware failures (physical damage to the memory chip or module, resulting in the inability to read or write valid data), and address line errors (errors in the memory address line, resulting in incorrect memory addresses being accessed).

[0094] The register records the characteristic code of the memory fault and the physical address of the faulty memory. The faulty memory is the memory that has failed, and the memory fault is the fault that has occurred in the memory. The characteristic code is used to describe the fault information of the memory fault, and the fault information includes the fault type of the memory fault. The physical address of the faulty memory can be the physical address of the memory page that has failed in the memory, or the physical address of the memory that has failed.

[0095] By recording the characteristic code of the memory fault and the physical address of the faulty memory, the processor 110 can read the fault information from the register and perform fault processing in combination with the memory protection rule.

[0096] In the embodiment of the present application, the processor 110 obtains the characteristic code of the memory fault by executing the "fault detection function" in the memory management function and reading the register (the register in which the memory controller 150 records the memory fault characteristic code and the physical address of the faulty memory).

[0097] In a possible implementation, the processor 110 may also pass the characteristic code of the memory fault to the user state when executing the "fault detection function" so that the system administrator can view and handle these errors. As an example, the characteristic code of the memory fault may be recorded in the system log.

[0098] S304: The processor 110 matches the feature code in the BPF Map according to the feature code of the memory fault.

[0099] UCE errors can be divided into Software Recoverable Action Optional (SRAO) and Software Recoverable Action Required (SRAR).

[0100] On some CPUs that do not support advanced RAS, for SRAO errors, if the kernel receives a memory fault (that is, the kernel determines that a UCE error occurs in the memory), it will downgrade the SRAO error to a correctable error (CE). The SRAO error cannot be correctly identified, affecting system operation.

[0101] The fault information includes the fault type of the memory fault, such as a multi-bit error, a single-bit error, or a row and column error. The processor 110 executes a rule matching function to match the feature code of the memory fault with the feature code in the BPF Map one by one, that is, to match the memory fault with the memory protection rules in the memory protection rule list. In an embodiment of the present application, the memory protection rules in the memory protection rule list are for the fault types that require memory isolation; similarly, the feature codes in the BPF Map are also used to describe the fault types that require memory isolation. As an example, the BPF Map is shown in Table 1. Two types of SRAO errors and corresponding feature codes are recorded in the BPF Map. The table is only an example and is not limited to only including these two types of SRAO errors.

[0102] Table 1: BPF Map

[0103] Signature Code Fault type 0x9d000000000000c0 SRAO Error 1 0x9d000000000000c2 SRAO Error 2

[0104] After reading the feature code stored in the register, the processor 110 executes the rule matching function to match the feature code of the memory fault with the feature code in the BPF Map one by one, and then determines whether the fault type described by the fault information is consistent with the fault type targeted by the memory protection rule. When the feature code of the memory fault successfully matches the feature code in the BPF Map, that is, the fault type in the fault information is the same as the fault type of a memory protection rule in the memory protection rule list, step S305 is executed to process the faulty memory. When the feature code of the memory fault cannot match the feature code in the BPF Map, that is, the fault type in the fault information is different from the fault type of each memory protection rule in the memory protection rule list, step S306 is executed to perform other processing on the faulty memory.

[0105] As an example, the characteristic code of the memory fault is “0x9d000000000000c0”, that is, the fault type of the faulty memory is SRAO error 1. The processor 110 matches the characteristic code of the memory fault with the characteristic codes in the BPF Map one by one.

[0106] It should be noted that, in the process of feature code matching, the embodiment of the present application does not limit the order of feature code matching, and can be matched one by one according to the order in the BPF Map, such as matching "0x9d000000000000c2" first and then matching "0x9d000000000000c0"; it can also be randomly matched with the memory protection rule, such as matching "0x9d000000000000c0" first and then matching "0x9d000000000000c2". However, it should be noted that the determination that the feature code of the memory fault cannot match the BPF Map can only be determined after traversing and matching each feature code in the BPF Map, that is, the feature code of the memory fault cannot match all the feature codes in the BPF Map.

[0107] S305: The processor 110 executes a fault handling strategy for the memory fault.

[0108] After determining that the memory fault is a memory fault targeted by the memory protection rule list, the processor 110 can handle the memory fault according to the adopted fault handling strategy. The fault handling strategy is a method for handling memory faults described in the memory protection rule list. The fault handling strategy can be customized by a technician. For example: the technician sets the fault types corresponding to the feature codes in the memory protection rule list to be fault types that need to be isolated and processed; then the fault handling strategy is isolation processing. If the technician sets the fault types corresponding to the feature codes in the memory protection rule list to be fault types that need to be formatted, then the fault handling strategy is formatting processing.

[0109] In an embodiment of the present application, the fault types corresponding to the feature codes in the memory protection rule list may be SRAO error 1 and SRAO error 2. Isolation processing is required for these two memory faults.

[0110] After the processor 110 determines that the characteristic code of the memory fault is the characteristic code in the BPF Map, the processor 110 determines the faulty memory according to the physical address of the faulty memory in the register, and isolates the faulty memory to make the faulty memory unavailable. In one possible implementation, a memory page in the memory 130 fails, and the processor 110 can determine the faulty memory page that has failed according to the physical address of the faulty memory, and then isolate the faulty memory page. After successful isolation, the faulty memory page will not be allocated by the kernel's memory allocator. As an example, the processor 110 modifies the data structure of the system kernel to mark the metadata of the faulty memory (or faulty memory page) as "poisoned" to indicate that the memory (or memory page) is unavailable.

[0111] The memory management is usually implemented by the operating system through page metadata (Page Struct), so the processor 110 will mark the page corresponding to the faulty memory as unavailable. For example, in a Linux system, this can be implemented by modifying the page metadata of the memory management subsystem.

[0112] After isolating the faulty memory, the processor 110 will also update the memory status to ensure that the faulty memory will not be allocated to any process or kernel module. In addition, if the faulty memory has been used by some processes or kernel modules, the processor 110 may need to notify these components to perform corresponding processing. For example, it may be necessary to terminate these processes or migrate the data they are using to other healthy memory areas.

[0113] By isolating faulty memory, these unreliable memory areas are prevented from being used further, reducing the risk of data corruption and system crashes.

[0114] S306: The processor 110 performs other processing on the faulty memory.

[0115] If the feature code of the memory fault does not match the feature code in the BPF Map, that is, the fault type of the faulty memory does not need to be isolated, the processor 110 can also perform other processing on the faulty memory. That is, if the feature code of the memory fault does not match the feature code in the BPF Map, the faulty memory (or faulty memory page) indicated by the physical address does not need to be isolated.

[0116] For some uncorrectable non-architecture errors (UNCA), the processor 110 may choose to record these error information into the system log for subsequent analysis and monitoring. If a certain type of error is detected, but the error does not affect the current system operation, the processor 110 may inform the system administrator by sending a notification or an alarm.

[0117] Through the above processing method, the processor 110 can effectively manage and handle memory errors to ensure the stability and availability of the system. This flexible processing mechanism helps to improve the robustness of the system and reduce the impact caused by memory failures.

[0118] In the above embodiment, a memory protection rule list is used to record the fault types that the user is concerned about, such as SRAO errors. When the feature code of the memory fault successfully matches the feature code in the BPF Map, the corresponding fault handling strategy is executed on the faulty memory according to the physical address in the fault information. When the feature code of the memory fault cannot match the feature code in the BPF Map, other processing can be performed on the faulty memory. The above method can accurately distinguish the fault types that use different processing methods, and by matching the feature code of the memory fault with the feature code in the BPF Map, it can be accurately determined which fault handling method needs to be used for the faulty memory.

[0119] The embodiment of the present application also provides another possible implementation method, which records the fault types that do not need to be isolated in the memory protection rule list. After performing the rule feature code matching as described in step S304, if the feature code of the memory fault successfully matches the feature code in the BPF Map, then perform other processing on the faulty memory as described in step S306, and if the feature code of the memory fault does not match the feature code in the BPF Map, then execute the fault handling strategy for the memory fault as described in step S305.

[0120] The following uses the memory protection rule list to record the fault types that need to be isolated as an example to introduce the process of users modifying the memory protection rule list during system operation.

[0121] During system operation, users can Figure 2 The application shown edits the memory protection rule list (eg, adds or deletes a memory protection rule). The user can add a signature code corresponding to a fault type that needs to be handled by a fault handling strategy through the application.

[0122] When the user modifies the memory protection rule list, the eBPF program is reloaded, the modified memory protection rule list is reloaded into the kernel, a new BPF Map is generated, and the original BPF Map is overwritten. When steps S303-S306 are executed again, memory management can be performed according to the modified memory protection rule list.

[0123] In an embodiment of the present application, a method for implementing memory protection rules that can be modified during system operation is provided to the user. Based on the feature that BPF Map can be modified during the operation of the operating system, when the memory protection rule list is modified, the modified memory protection rule list is mapped to the kernel by reloading the eBPF program to apply the modified memory protection rule list for memory management. Through the above method, the user can dynamically add, modify or delete memory protection rules, update the memory protection rule list and BPF Map while the operating system is running, without restarting the system. When new types of memory failures or security vulnerabilities are discovered, users are supported to quickly add corresponding protection rules and respond to potential threats in a timely manner without restarting the system to interrupt the current task process. In addition, based on the BPF system call and memory mapping, the user-edited memory protection rules can be mapped to the kernel in the correct format, so that the edited memory protection rules can be accurately recognized and applied by the rule matching function.

[0124] The above are some specific implementations of the memory management method provided in the embodiment of the present application. Based on this, the present application also provides a corresponding memory management device. The device provided in the embodiment of the present application will be introduced below in combination with the above method. Figure 4 As shown, the memory management device includes:

[0125] An acquisition module 401 is used to acquire a feature code of the memory fault after receiving an interrupt of the memory fault, wherein the feature code is used to describe fault information of the memory fault;

[0126] A matching module 402 is used to match whether the feature code exists in a Berkeley Packet Filter (BPF) mapping table, where the BPF mapping table is a mapping table of a memory protection rule list in a kernel, and the memory protection rule list is used to describe a feature code of a memory fault that a user is concerned about;

[0127] The processing module 403 is used to execute a fault handling strategy for the memory fault when the feature code exists in the BPF mapping table.

[0128] The embodiments of the present application also provide corresponding devices and computer storage media for implementing the solutions provided by the embodiments of the present application.

[0129] The device includes a memory and a processor, the memory is used to store instructions or codes, and the processor is used to execute the instructions or codes so that the device executes the memory management method described in any embodiment of the present application.

[0130] The computer storage medium stores code, and when the code is executed, the device executing the code implements the memory management method described in any embodiment of the present application.

[0131] The "first" and "second" in the names such as "first" and "second" (if any) mentioned in the embodiments of the present application are only used as name identifiers and do not represent the first or second in order.

[0132] Through the description of the above implementation methods, it can be known that those skilled in the art can clearly understand that all or part of the steps in the above-mentioned embodiment method can be implemented by means of software plus a general hardware platform. Based on such an understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a storage medium, such as a read-only memory (ROM) / RAM, a magnetic disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network communication device such as a router) to execute the methods described in each embodiment of the present application or some parts of the embodiments.

[0133] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative work.

[0134] The above description is merely an exemplary embodiment of the present application and is not intended to limit the protection scope of the present application.

Claims

1. A memory management method, characterized in that: include: After receiving a memory fault interrupt, obtaining a feature code of the memory fault, wherein the feature code is used to describe fault information of the memory fault; Match whether the feature code exists in the Berkeley Packet Filter (BPF) mapping table, where the BPF mapping table is a mapping table of a memory protection rule list in the kernel, and the memory protection rule list is used to describe feature codes of memory faults that the user is concerned about; In a case where the feature code exists in the BPF mapping table, a fault handling strategy is executed on the memory fault.

2. The method according to claim 1, characterized in that Prior to receiving the interrupt of the memory failure, the method further comprises: A stub of a rule matching function is set in a memory management function; wherein the memory management function is used to isolate the memory fault described by the memory protection rule list; and the rule matching function is used to traverse the BPF mapping table to determine whether the feature code exists.

3. The method according to claim 2, characterized in that The step of setting a stub point of the rule matching function in the memory management function includes: Based on the extended Berkeley packet filter eBPF, the memory management function calls the interface of the rule matching function.

4. The method according to claim 2 or 3, characterized in that: The rule matching function adopts the kernel security module LSM architecture.

5. The method according to claim 1, characterized in that Prior to receiving the interrupt of the memory failure, the method further comprises: Load the eBPF program to load the memory protection rule list into the kernel to obtain the BPF mapping table.

6. The method according to claim 1, characterized in that The memory protection rule list at least includes a feature code of a software recoverable operation optional error SRAO.

7. The method according to claim 2 or 3, characterized in that: The memory protection rule list is stored in a system configuration file; wherein the system configuration file is a file loaded during the startup process of the operating system.

8. The method according to claim 1, characterized in that In the case where the memory safety protection list is modified, the method further includes: Reload the eBPF program to load the modified memory protection rule list into the kernel to obtain an updated BPF mapping table, so as to perform memory management according to the updated BPF mapping table.

9. The method according to claim 5 or 8, characterized in that: The Extended Berkeley Packet Filter program runs as a daemon process.

10. A server, characterized in that: comprising a processor, and a memory communicatively connected to the processor; The memory is used to store computer-executable instructions; The processor is used to execute the computer-executable instructions stored in the memory to implement the memory management method described in any one of claims 1-9.

Images