A memory self-checking method and apparatus

Abstract

The application provides a memory self-checking method and device, electronic equipment and computer program product, the method comprises: obtaining the memory mapping relationship of the virtual memory address and the physical memory binding of the to-be-tested memory partition by using a predefined compiler variable; based on the memory mapping relationship, using a self-checking strategy matched with the user state permission of the to-be-tested memory partition to perform memory self-checking on the to-be-tested memory partition. The application obtains the exact physical memory address corresponding to the virtual memory address by using the predefined compiler variable, and based on the mapping relationship of the virtual-physical address, uses different self-checking strategies to perform memory self-checking on the memory partitions with different user state permissions, which can perform memory self-checking on the user state scene of the secure operating system, thereby ensuring the safety and reliability of the system memory.

Description

Technical Field

[0001] This application relates to the field of memory testing technology, specifically to a memory self-testing method, apparatus, electronic device, and computer program product. Background Technology

[0002] Currently, in systems such as rail transit, various control systems and equipment are characterized by complex functions, high real-time requirements, and stringent safety and reliability demands. Errors or malfunctions in any component of the system can lead to catastrophic consequences. Therefore, memory self-testing of core control systems has become increasingly important.

[0003] Existing memory self-test technologies are mainly applicable to embedded bare metal (without an operating system) and operating system kernel mode, and are performed by reading and writing all physical memory.

[0004] However, for user-mode programs running secure operating systems (such as QNX), due to the operating system's own security features, user-mode programs can only access memory within their own process space and can no longer directly access all physical memory. Furthermore, some areas within the process space are defined as read-only by the secure operating system, making traditional memory read / write tests impossible.

[0005] In summary, existing technologies cannot perform memory self-testing in user-mode scenarios of secure operating systems. Summary of the Invention

[0006] This application provides a memory self-testing method, apparatus, electronic device, and computer program product, which can perform memory self-testing in user-mode scenarios of a secure operating system.

[0007] In a first aspect, embodiments of this application provide a memory self-test method, including:

[0008] The memory mapping relationship between the virtual memory address and the physical memory binding of the memory partition under test is obtained using predefined compiler variables;

[0009] Based on the memory mapping relationship, a self-testing strategy matching the user-mode permissions of the memory partition under test is used to perform a memory self-test on the memory partition under test.

[0010] In one embodiment, the user-mode permission is read-only permission or read-write permission;

[0011] The step of performing a memory self-test on the memory partition under test based on the memory mapping relationship and using a self-testing strategy that matches the user-mode permissions of the memory partition under test includes:

[0012] When the user-mode permission of the memory partition under test is identified as read-only, a preset first self-test strategy is used to perform a memory self-test on the memory partition under test based on the memory mapping relationship.

[0013] When the user-mode permissions of the memory partition under test are identified as read-write permissions, a preset second self-test strategy is used to perform a memory self-test on the memory partition under test based on the memory mapping relationship.

[0014] In one embodiment, the memory partition to be tested includes a first memory partition to be tested with read-only user-mode permissions and a second memory partition to be tested with read-write user-mode permissions;

[0015] The step of performing a memory self-test on the memory partition under test based on the memory mapping relationship and using a self-testing strategy that matches the user-mode permissions of the memory partition under test includes:

[0016] Based on the memory mapping relationship, a preset first self-test strategy is used to perform a memory self-test on the first memory partition to be tested.

[0017] Based on the memory mapping relationship, a preset second self-test strategy is used to perform a memory self-test on the second memory partition to be tested.

[0018] In one embodiment, before obtaining the memory mapping relationship between the virtual memory address and physical memory binding of the memory partition under test using predefined compiler variables, the method further includes:

[0019] The memory mapping relationship between the virtual memory address and the physical memory of the memory partition under test is locked using a preset memory locking function.

[0020] In one embodiment, before obtaining the memory mapping relationship between the virtual memory address and physical memory binding of the memory partition under test using predefined compiler variables, the method further includes:

[0021] The user-mode permissions of each memory partition are identified using a preset recognition function, and the memory partition with readable user-mode permissions is identified as the memory partition to be tested.

[0022] In one embodiment, the memory partition under test with read-only user-mode permissions includes a code segment; the memory partition under test with read-write user-mode permissions includes one or more of the heap, data segment, and stack.

[0023] In one embodiment, the self-test strategy includes the MD5 checksum and the Abraham memory read / write test.

[0024] Secondly, embodiments of this application provide a memory self-testing device, comprising:

[0025] The address acquisition module is used to obtain the memory mapping relationship between the virtual memory address and the physical memory binding of the memory partition under test using predefined compiler variables;

[0026] The memory self-test module is used to perform a memory self-test on the memory partition under test based on the memory mapping relationship and using a self-test strategy that matches the user-mode permissions of the memory partition under test.

[0027] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the program to implement the steps of the memory self-test method described in the first aspect.

[0028] Fourthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the memory self-test method described in the first aspect.

[0029] The memory self-testing method, apparatus, electronic device, and computer program product provided in this application obtain the exact physical memory address corresponding to the virtual memory address by predefined compiler variables, and perform memory self-testing by adopting different self-testing strategies for memory partitions with different user-mode permissions based on the virtual-physical address mapping relationship. This enables memory self-testing for user-mode scenarios of a secure operating system, thereby ensuring the security and reliability of the system's memory. Attached Figure Description

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

[0031] Figure 1 This is one of the flowcharts illustrating the memory self-test method provided in the embodiments of this application;

[0032] Figure 2 This is a second flowchart illustrating the memory self-test method provided in the embodiments of this application;

[0033] Figure 3 This is a schematic diagram of the memory self-test device provided in the embodiments of this application;

[0034] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0036] Figure 1 This is a flowchart illustrating the memory self-test method. (Refer to...) Figure 1 This application provides a memory self-test method, which may include the following steps:

[0037] S1. Use predefined compiler variables to obtain the memory mapping relationship between the virtual memory address and the physical memory binding of the memory partition under test;

[0038] S2. Based on the memory mapping relationship, a self-testing strategy matching the user-mode permissions of the memory partition under test is used to perform a memory self-test on the memory partition under test.

[0039] This application provides a memory self-test method for the user-mode memory space of a secure operating system. This application uses the QNX secure operating system as an example for illustration.

[0040] First, predefined compiler variables are used to obtain the memory mapping relationship between the virtual memory address and physical memory of the memory partition under test. It should be noted that the virtual memory within the user process space is subdivided into several regions by the QNX operating system, of which only the stack, code segment, data segment, and heap are visible to the user. The address range of the virtual memory in these user-mode visible regions is determined during program compilation and linking. To obtain these exact addresses, compiler-predefined variables are needed; that is, variables are directly defined during compilation to store these compilation parameters. These variables are not explicitly defined in the source code, but can be accessed, read, and written within the source code. By setting compiler variables during compilation and linking and reading them during program execution, the exact addresses of each virtual memory segment in the user process space can be obtained during the execution of the user-mode program.

[0041] Then, based on the exact address obtained (determined according to the memory mapping relationship), different self-testing strategies are adopted to perform memory self-testing according to the different user-mode permissions for different virtual memory segments.

[0042] The memory self-testing method provided in this application obtains the exact physical memory address corresponding to the virtual memory address by predefining compiler variables, and performs memory self-testing by adopting different self-testing strategies for memory partitions with different user-mode permissions based on the mapping relationship between virtual and physical addresses. It can perform memory self-testing for user-mode scenarios of a secure operating system, thereby ensuring the security and reliability of the system's memory.

[0043] In one embodiment, the user-mode permission is read-only permission or read-write permission;

[0044] Step S2 may include:

[0045] S201. When the user-mode permission of the memory partition to be tested is identified as read-only, a preset first self-test strategy is used to perform a memory self-test on the memory partition to be tested based on the memory mapping relationship.

[0046] S202. When the user-mode permissions of the memory partition under test are identified as read-write permissions, a preset second self-test strategy is used to perform a memory self-test on the memory partition under test based on the memory mapping relationship.

[0047] The self-testing strategies include MD5 checksum and Abraham memory read / write test, wherein the first self-testing strategy includes MD5 checksum and the second self-testing strategy includes Abraham memory read / write test.

[0048] In this embodiment, a memory self-test can be performed on a single memory partition under test. In practical applications, it is not necessary to perform a memory self-test on all memory partitions, but only on a specific memory partition. The user-mode permissions of the specified memory partition under test can be read-only or read-write. Accordingly, when the user-mode permissions of the memory partition under test are read-only, a preset first self-test strategy (such as MD5 checksum, CRC checksum, etc.) is used to perform the memory self-test; when the user-mode permissions of the memory partition under test are read-write, a preset second self-test strategy (such as memory read-write test based on the Abraham algorithm, etc.) is used to perform the memory self-test.

[0049] It is understandable that the user-mode permissions of the memory partition under test are divided into two types: read-only permissions and read-write permissions. Among them, the memory partition under test with read-only user-mode permissions includes the code segment area; the memory partition under test with read-write user-mode permissions includes one or more of the heap area, data segment area, and stack area.

[0050] It should be noted that existing memory self-testing technologies are primarily applicable to embedded bare-metal systems (without an operating system) and operating system kernel mode, performing read and write tests on all physical memory. However, for user-mode programs running secure operating systems (such as QNX), due to the security features of the secure operating system, user-mode programs can only access memory within their own process space and can no longer directly access all physical memory. Furthermore, some areas within the process space are defined as read-only by the secure operating system, making traditional memory read and write tests impossible.

[0051] The memory self-testing method provided in this application adopts different self-testing strategies based on the different user-mode permissions of the memory partition under test. For the memory self-testing requirements of the user-mode scenario of a secure operating system, it can feasiblely and specifically realize memory self-testing, turning memory self-testing in this scenario from infeasible to feasible, effectively improving the pertinence and feasibility of memory self-testing, thereby further ensuring the security and reliability of system memory.

[0052] In one embodiment, the memory partition to be tested includes a first memory partition to be tested with read-only user-mode permissions and a second memory partition to be tested with read-write user-mode permissions;

[0053] Step S2 may include:

[0054] S211. Based on the memory mapping relationship, a preset first self-test strategy is used to perform a memory self-test on the first memory partition to be tested; wherein, the first self-test strategy includes the MD5 checksum method.

[0055] S212. Based on the memory mapping relationship, a preset second self-test strategy is used to perform a memory self-test on the second memory partition to be tested; wherein, the second self-test strategy includes the Abraham memory read / write test method.

[0056] It should be noted that, compared to the previous embodiment's scheme of performing memory self-tests on a single memory partition to be tested, this embodiment can perform memory self-tests on multiple memory partitions to be tested simultaneously. Specifically, the multiple memory partitions to be tested include both a first memory partition to be tested with read-only user-mode permissions and a second memory partition to be tested with read-write user-mode permissions.

[0057] For the first memory partition under test with read-only user-mode permissions, a corresponding first self-test strategy (such as MD5 checksum, CRC checksum, etc.) is used to perform memory self-test; for the second memory partition under test with read-write user-mode permissions, a corresponding second self-test strategy (such as memory read-write test based on Abraham algorithm, etc.) is used to perform memory self-test.

[0058] It is understood that, similar to the previous embodiment, the user-mode permissions of the memory partition under test are divided into two types: read-only permissions and read-write permissions; among them, the memory partition under test with read-only user-mode permissions includes the code segment area; the memory partition under test with read-write user-mode permissions includes one or more of the heap area, data segment area, and stack area.

[0059] The memory self-testing method provided in this application can simultaneously perform memory self-tests on multiple memory partitions to be tested. By adopting different self-testing strategies based on the different user-mode permissions of the memory partitions to be tested, the method can feasiblely, comprehensively, and specifically achieve memory self-testing for the memory self-testing requirements of user-mode scenarios in secure operating systems. This transforms the memory self-testing in such scenarios from infeasible to feasible, effectively improving the pertinence and feasibility of memory self-testing, thereby further ensuring the security and reliability of system memory.

[0060] In one embodiment, before obtaining the memory mapping relationship between the virtual memory address and physical memory binding of the memory partition under test using predefined compiler variables, the method further includes:

[0061] The memory mapping relationship between the virtual memory address and the physical memory of the memory partition under test is locked using a preset memory locking function.

[0062] It should be noted that in user-mode process space, the memory addresses visible to user programs are all virtual addresses, not representing actual physical memory. The mapping between virtual addresses and actual physical memory is managed by the operating system, and there are actually two management methods:

[0063] Method 1: Once physical memory is allocated, it remains fixed, and the mapping between virtual addresses and physical memory also remains unchanged;

[0064] Method 2: The allocation of physical memory can be dynamically adjusted by the operating system, and the physical memory corresponding to the virtual address may be changed.

[0065] In this embodiment, a preset memory locking function can be used to lock the memory mapping relationship between the virtual memory address and physical memory of the memory partition under test. Specifically, the QNX API function mlockall() can be used to explicitly lock the physical memory corresponding to the user process space, that is, to force processing according to method 1, where the physical memory corresponding to the process space is fixed once allocated. The advantage of doing this is that the user program always runs on these fixed physical memories, so as long as a self-check algorithm is performed on these physical memories periodically, it can be ensured that the memory where the user program resides is healthy, without having to worry about the physical memory outside the user process.

[0066] The memory self-test method provided in this application locks the memory mapping relationship between the virtual memory address and physical memory of the memory partition under test using a preset memory locking function. During memory testing, only a fixed physical memory space needs to be tested, without needing to consider external physical memory usage, thus ensuring the health of the memory where the user program resides. Therefore, this application embodiment narrows the scope of memory self-testing, improves its efficiency, and further ensures the security and reliability of system memory.

[0067] In one embodiment, before obtaining the memory mapping relationship between the virtual memory address and physical memory binding of the memory partition under test using predefined compiler variables, the method further includes:

[0068] The user-mode permissions of each memory partition are identified using a preset recognition function, and the memory partition with readable user-mode permissions is identified as the memory partition to be tested.

[0069] It should be noted that for user-mode programs running secure operating systems (such as QNX), due to the operating system's inherent security features, user-mode programs can only access memory within their own process space and can no longer directly access all physical memory. Furthermore, some areas within the process space are defined as read-only by the secure operating system, making traditional memory read / write tests impossible. To implement memory self-testing in user-mode scenarios using secure operating systems like QNX, it is necessary to analyze the user-mode memory layout and protection mechanisms of this operating system beforehand.

[0070] In this embodiment, a preset identification function is used to identify user-mode permissions for each memory partition, and the memory partition with readable user-mode permissions is identified as the memory partition to be tested. Specifically, the QNX user-mode process memory space identified by the identification function is as follows:

[0071] Operating system reserved area: not readable or writable in user space, no self-check required.

[0072] Object area (device mapping): The mapping of external devices in memory. Drivers and processes share memory, and it is not readable or writable by user space. The operating system manages and ensures isolation, and no self-test is required.

[0073] Dynamic library area: Memory mapping for interfaces with dynamic libraries, not readable or writable by user space. Managed and isolated by the operating system, requiring no self-checking.

[0074] Heap area: Read and write in user space, read and write tests are required.

[0075] Data segment: User-space readable and writable, read and write tests are required.

[0076] Code segment: Read-only in user space, requires read verification.

[0077] Stack area: Read and write in user space, read and write tests are required.

[0078] Low address reserved area: not readable or writable in user space, no self-check required.

[0079] The above analysis shows that in the user-mode process space, only the stack, code segment, data segment, and heap are actually visible to the user (with read permissions). The code segment is fixed after the program is loaded, and is read-only in user mode, meaning it cannot be written to or modified (read-only permission). The other three areas can be read and written to as the user program executes (read-write permission). It should be noted that, among the user-mode permissions mentioned above, read-only and read-write permissions both have read access.

[0080] The memory self-testing method provided in this application pre-identifies user-mode permissions for each memory partition using an identification function, determining the memory partition with readable user-mode permissions as the memory partition to be tested. This method can identify the user-mode permission status of each memory partition and then implement a targeted memory self-test based on the user-mode permission identification results. Therefore, it can feasiblely and specifically implement memory self-testing for user-mode scenarios in secure operating systems, transforming the previously infeasible scenario into a feasible one. This effectively improves the targeting and feasibility of memory self-testing, thereby further ensuring the security and reliability of system memory.

[0081] Please see Figure 2 Based on the above scheme, and to facilitate a better understanding of the memory self-test method provided in the embodiments of this application, the following detailed explanation is provided:

[0082] First, let's analyze the memory space of QNX user-mode processes:

[0083] Operating system reserved area: not readable or writable in user space, no self-check required.

[0084] Object area (device mapping): The mapping of external devices in memory. Drivers and processes share memory, and it is not readable or writable by user space. The operating system manages and ensures isolation, and no self-test is required.

[0085] Dynamic library area: Memory mapping for interfaces with dynamic libraries, not readable or writable by user space. Managed and isolated by the operating system, requiring no self-checking.

[0086] Heap area: Read and write in user space, read and write tests are required.

[0087] Data segment: User-space readable and writable, read and write tests are required.

[0088] Code segment: Read-only in user space, requires read verification.

[0089] Stack area: Read and write in user space, read and write tests are required.

[0090] Low address reserved area: not readable or writable in user space, no self-check required.

[0091] The above analysis shows that in the user-mode process space, only the stack, code segment, data segment, and heap are actually visible to the user. The code segment remains fixed after the program is loaded; it is read-only in user mode and cannot be written to or modified. The other three areas can be read and written to as the user program executes.

[0092] In user-mode process space, the memory addresses visible to user programs are virtual addresses, which do not represent actual physical memory. The mapping between virtual addresses and actual physical memory is managed by the operating system, and there are two management methods:

[0093] Method 1: Once physical memory is allocated, it remains fixed, and the mapping between virtual addresses and physical memory also remains unchanged;

[0094] Method 2: The allocation of physical memory can be dynamically adjusted by the operating system, and the physical memory corresponding to the virtual address may be changed.

[0095] The QNX API function `mlockall()` can be used to explicitly lock the physical memory corresponding to the user process space, thus forcing the process to follow method 1, where the physical memory corresponding to the process space is fixed once allocated. The advantage of this is that user programs always run on these fixed physical memory locations. Therefore, by periodically performing a self-check algorithm on these physical memory locations, the health of the memory where the user program resides can be ensured, without needing to concern oneself with the physical memory situation outside the user process.

[0096] Of course, for method 2, instead of locking physical memory, the operating system dynamically allocates physical memory, which can achieve better program execution efficiency. However, since user processes may frequently change the actual physical memory location, the user program needs to perform a self-check algorithm on the newly allocated physical memory each time it is allocated to ensure that the newly allocated physical memory is healthy.

[0097] Furthermore, the virtual memory within the user process space is subdivided into several regions by the QNX operating system, of which only the stack, code segment, data segment, and heap are visible to the user. The address range of these user-visible regions is determined during program compilation and linking. To obtain these precise addresses, compiler-predefined variables are used; these variables are defined directly during compilation to store compilation parameters. These variables are not explicitly defined in the source code, but can be accessed and read / written within the source code. The address range of all these memory partitions can be determined using compiler-predefined variables. Typical compiler-predefined variables related to user process space virtual memory segmentation include:

[0098] __executable_start: The starting address of the user space, followed by the stack area;

[0099] _btext: The starting address of the code segment, followed by the code segment itself;

[0100] _etext: The address of the end of the code segment, followed by the data segment;

[0101] _edata: The end address of the data segment, followed by the heap area;

[0102] _end: End address of user space;

[0103] By properly setting these compiler variables during compilation and linking, and reading them during program execution, the exact addresses of each virtual memory segment in the user process space can be obtained during the execution of the user-mode program. Then, different memory self-tests can be performed for different user-mode permissions of different virtual memory segments.

[0104] Since the code segment is read-only and cannot be changed during runtime, the self-check method for the code segment can be MD5 checksum. That is, during the self-check, the MD5 checksum of the code segment is calculated, and the MD5 checksum is checked to see if it is consistent with the expectation.

[0105] Since the stack, data segment, and heap are all user-readable and writable, their correctness can be verified using traditional memory read / write testing methods. That is, by executing a specific memory read / write sequence, most memory hardware errors can be detected. For example, the classic Abraham algorithm can be used. The specific memory read / write test algorithm will not be described in detail here.

[0106] The memory self-testing device provided in the embodiments of this application is described below. The memory self-testing device described below can be referred to in correspondence with the memory self-testing method described above.

[0107] Please see Figure 3 This application provides a memory self-test device, including:

[0108] Address acquisition module 1 is used to obtain the memory mapping relationship between the virtual memory address and the physical memory binding of the memory partition under test using predefined compiler variables;

[0109] The memory self-test module 2 is used to perform a memory self-test on the memory partition under test based on the memory mapping relationship and using a self-test strategy that matches the user-mode permissions of the memory partition under test.

[0110] In one embodiment, the user-mode permission is read-only permission or read-write permission;

[0111] The memory self-test module 2 is specifically used for:

[0112] When the user-mode permission of the memory partition under test is identified as read-only, a preset first self-test strategy is used to perform a memory self-test on the memory partition under test based on the memory mapping relationship.

[0113] When the user-mode permissions of the memory partition under test are identified as read-write permissions, a preset second self-test strategy is used to perform a memory self-test on the memory partition under test based on the memory mapping relationship.

[0114] In one embodiment, the memory partition to be tested includes a first memory partition to be tested with read-only user-mode permissions and a second memory partition to be tested with read-write user-mode permissions;

[0115] The memory self-test module 2 is specifically used for:

[0116] Based on the memory mapping relationship, a preset first self-test strategy is used to perform a memory self-test on the first memory partition to be tested.

[0117] Based on the memory mapping relationship, a preset second self-test strategy is used to perform a memory self-test on the second memory partition to be tested.

[0118] In one embodiment, the memory self-test device further includes:

[0119] The memory binding module is used to lock the memory mapping relationship between the virtual memory address and the physical memory binding of the memory partition under test using a preset memory locking function.

[0120] In one embodiment, the memory self-test device further includes:

[0121] The partition identification module is used to identify user-mode permissions of each memory partition using a preset identification function, and to identify the memory partition with readable user-mode permissions as the memory partition to be tested.

[0122] In one embodiment, the memory partition under test with read-only user-mode permissions includes a code segment; the memory partition under test with read-write user-mode permissions includes one or more of the heap, data segment, and stack.

[0123] In one embodiment, the self-test strategy includes the MD5 checksum and the Abraham memory read / write test.

[0124] It is understood that the above-described device embodiments correspond to the method embodiments of this application. The memory self-test device provided in the embodiments of this application can implement the memory self-test method provided in any one of the method embodiments of this application.

[0125] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device may include a processor 410, a communication interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other through the communication bus 440. The processor 410 can call a computer program in the memory 430 to execute the steps of a memory self-test method, such as: obtaining the memory mapping relationship between the virtual memory address and physical memory of the memory partition under test using predefined compiler variables; and performing a memory self-test on the memory partition under test using a self-test strategy that matches the user-mode permissions of the memory partition under test based on the memory mapping relationship.

[0126] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0127] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the steps of the memory self-testing method provided in the above embodiments, such as: obtaining the memory mapping relationship between the virtual memory address and physical memory of the memory partition under test using predefined compiler variables; and performing a memory self-test on the memory partition under test using a self-testing strategy that matches the user-mode permissions of the memory partition under test based on the memory mapping relationship.

[0128] On the other hand, embodiments of this application also provide a processor-readable storage medium storing a computer program for causing a processor to execute the steps of the methods provided in the above embodiments, such as: obtaining the memory mapping relationship between the virtual memory address and physical memory of the memory partition under test using predefined compiler variables; and performing a memory self-test on the memory partition under test based on the memory mapping relationship using a self-testing strategy that matches the user-mode permissions of the memory partition under test.

[0129] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

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

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

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

Claims

1. A memory self-test method, characterized in that, include: The memory mapping relationship between the virtual memory address and the physical memory binding of the memory partition under test is obtained using predefined compiler variables; Based on the memory mapping relationship, a self-testing strategy matching the user-mode permissions of the memory partition under test is used to perform a memory self-test on the memory partition under test. The user-mode permissions are either read-only permissions or read-write permissions; The step of performing a memory self-test on the memory partition under test based on the memory mapping relationship and using a self-testing strategy that matches the user-mode permissions of the memory partition under test includes: When the user-mode permission of the memory partition under test is identified as read-only, a preset first self-test strategy is used to perform a memory self-test on the memory partition under test based on the memory mapping relationship. When the user-mode permissions of the memory partition under test are identified as read and write permissions, a preset second self-test strategy is used to perform a memory self-test on the memory partition under test based on the memory mapping relationship. The first self-test strategy includes the MD5 checksum method; the second self-test strategy includes the Abraham memory read / write test method.

2. The memory self-test method according to claim 1, characterized in that, The memory partition to be tested includes a first memory partition to be tested with read-only user-mode permissions and a second memory partition to be tested with read-write user-mode permissions. The step of performing a memory self-test on the memory partition under test based on the memory mapping relationship and using a self-testing strategy that matches the user-mode permissions of the memory partition under test includes: Based on the memory mapping relationship, a preset first self-test strategy is used to perform a memory self-test on the first memory partition to be tested. Based on the memory mapping relationship, a preset second self-test strategy is used to perform a memory self-test on the second memory partition to be tested.

3. The memory self-test method according to claim 1, characterized in that, Before obtaining the memory mapping relationship between the virtual memory address and physical memory binding of the memory partition under test using predefined compiler variables, the following steps are also included: The memory mapping relationship between the virtual memory address and the physical memory of the memory partition under test is locked using a preset memory locking function.

4. The memory self-test method according to claim 1, characterized in that, Before obtaining the memory mapping relationship between the virtual memory address and physical memory binding of the memory partition under test using predefined compiler variables, the following steps are also included: The user-mode permissions of each memory partition are identified using a preset recognition function, and the memory partition with readable user-mode permissions is identified as the memory partition to be tested.

5. The memory self-test method according to claim 2 or 3, characterized in that, The memory partition under test with read-only user-mode permissions includes the code segment area; the memory partition under test with read-write user-mode permissions includes one or more of the heap area, data segment area, and stack area.

6. A memory self-test device, characterized in that, include: The address acquisition module is used to obtain the memory mapping relationship between the virtual memory address and the physical memory binding of the memory partition under test using predefined compiler variables; The memory self-test module is used to perform a memory self-test on the memory partition under test based on the memory mapping relationship and using a self-test strategy that matches the user-mode permissions of the memory partition under test. The user-mode permissions are either read-only permissions or read-write permissions; The memory self-test module is specifically used for: when the user-mode permission of the memory partition under test is identified as read-only, performing a memory self-test on the memory partition under test based on the memory mapping relationship and using a preset first self-test strategy; when the user-mode permission of the memory partition under test is identified as read-write, performing a memory self-test on the memory partition under test based on the memory mapping relationship and using a preset second self-test strategy. The first self-test strategy includes the MD5 checksum method; the second self-test strategy includes the Abraham memory read / write test method.

7. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the memory self-test method according to any one of claims 1 to 5.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the memory self-test method according to any one of claims 1 to 5.

Images