Pointer integrity protection method and apparatus, device, and storage medium

Abstract

Embodiments of the present application provide a pointer integrity protection method and device, equipment and a storage medium. The method can protect the memory region where the target code pointer is located when the target code pointer is created. When the target code pointer is used to access memory, the memory region where the target code pointer is located is checked for pointer integrity by a hardware checking unit. If tampering with the target code pointer occurs, a PMP exception handling process is triggered. Thus, a solution for architecture-related pointer integrity or control flow integrity is provided, the original hardware design is maximally reused, the hardware automatically checks the runtime pointer integrity, is more secure and effective than a software solution, has lower overhead, and can overcome the problem that hardware solutions in related technologies only support 64-bit systems or have high processing overhead, that is, the number of bits of the computer system is not limited, and both 32-bit and 64-bit systems can be supported.

Description

Technical Field

[0001] This application relates to the field of software protection technology, and in particular to a pointer integrity protection method, apparatus, device, and storage medium. Background Technology

[0002] The rapid development of smart terminals has brought great convenience to our lives, but correspondingly, software security issues are also increasing. Among these, memory security is the most significant threat to software security vulnerabilities. Because programming languages ​​such as C and C++ use pointers that can directly access arbitrary memory and lack pointer access checks, system software written in them (firmware, operating system kernels, compilers, etc.) is subject to widespread memory security threats. Strategies for protecting pointer integrity in C / C++ software are crucial for addressing C / C++ memory security threats. Pointer integrity protection technology is a common memory security protection method used to prevent the tampering and reuse of stack return addresses and function pointers due to memory corruption.

[0003] In pointer integrity solutions, canary is a purely software defense mechanism for stack return address integrity, used to block ROP attacks caused by stack buffer overflows.

[0004] However, stack protection schemes based on canary are purely software-based techniques with relatively weak protection capabilities. Attackers can dump the value of the canary from memory based on its relative position, thereby bypassing, leaking, and brute-forcing it. They can even hijack the control flow of the __stack_chk_fail exception handling function, rendering the canary's checking mechanism ineffective.

[0005] Solutions to pointer integrity also include hardware solutions, such as ARMv8 Pointer Authentication Code (PAC) and Intel's processor tracing technology. However, ARMv8 pointer authentication code only supports 64-bit systems, and Intel's processor tracing technology is more used for offline analysis. Decoding and restoring accurate control flow information is costly and not suitable for runtime control flow integrity checks. Summary of the Invention

[0006] The pointer integrity protection method provided in this application embodiment can provide a new hardware primitive and maximize the use of the original hardware circuit, thereby providing a hardware solution for architecture-related pointer integrity or control flow integrity, maximizing the reuse of the original hardware design, providing automatic hardware checks for pointer integrity at runtime, which is safer, more effective and less expensive than software solutions, and can overcome the problem that hardware solutions in related technologies only support 64-bit systems or have high processing overhead, that is, it does not limit the number of computer system bits and can support both 32-bit and 64-bit systems at the same time.

[0007] In a first aspect, embodiments of this application provide a pointer integrity protection method, which is applied to a memory device having a user-configurable privileged register, including: when a target code pointer is created, packing the memory region where the target code pointer is located for protection; when the target code pointer is used for memory access, performing a pointer integrity check on the memory region where the target code pointer is located through a hardware checking unit, and if tampering with the target code pointer is found, triggering a PMP exception handling process.

[0008] Furthermore, before applying a packer to the memory region where the target code pointer is located when the target code pointer is created, the method further includes: expanding at least two user-configurable privileged registers in the memory device to provide the memory device with user-configurable privileged registers; wherein the at least two user-configurable privileged registers include at least one user-mode PMP address register and one user-mode PMP configuration register.

[0009] Furthermore, the step of protecting the memory region where the target code pointer is located during the creation of the target code pointer includes: protecting the memory region where the target code pointer is located with a hardware red zone by instrumenting instructions that configure the at least two user-configurable privileged registers during the creation of the target code pointer, wherein the hardware red zone is a protection area defined by the at least two user-configurable privileged registers.

[0010] Furthermore, after the hardware inspection unit performs a pointer integrity check on the memory region where the target code pointer is located, if it is determined that no tampering operation has occurred with the target code pointer, the packing protection on the memory region where the target code pointer is located is released when the life cycle of the target code pointer ends.

[0011] Furthermore, the target code pointer includes a return address or a function pointer in the stack frame.

[0012] Furthermore, when the target code pointer is the return address in the stack frame, in the scenario of recursive calls, after the packing protection of the new stack N+1 is released, the packing protection of the return address in the old stack N is restored, wherein the new stack N+1 and the old stack N are adjacent stacks.

[0013] Secondly, embodiments of this application also provide a memory device, which includes a processor and a memory, wherein the memory is used to store at least one instruction, which, when loaded and executed by the processor, implements the pointer integrity protection method provided in the first aspect.

[0014] Thirdly, embodiments of this application also provide a chip that may include the memory device provided in the second aspect.

[0015] Fourthly, embodiments of this application also provide an electronic device, which may include the memory device provided in the second aspect or the chip provided in the third aspect.

[0016] Fifthly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the pointer integrity protection method provided in the first aspect.

[0017] In a sixth aspect, embodiments of this application also provide a computer program product, including a computer program or instructions, wherein the computer program or instructions, when processed, implement the pointer integrity protection method provided in the first aspect.

[0018] The above technical solution involves protecting the memory region containing the target code pointer by adding a protective layer during its creation. When accessing memory using the target code pointer, a hardware inspection unit performs a pointer integrity check on the memory region. If any tampering with the target code pointer is detected, a PMP exception handling process is triggered to ensure the integrity of the target code pointer. This method provides a hardware solution for architecture-related pointer integrity or control flow integrity, maximizing the reuse of existing hardware designs and providing automatic hardware checks for runtime pointer integrity. It is more secure, effective, and less expensive than software solutions, and overcomes the limitations of related hardware solutions that only support 64-bit systems or have high processing overhead. In other words, it does not limit the computer system's bitness and can support both 32-bit and 64-bit systems simultaneously. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of 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.

[0020] Figure 1 This is a schematic diagram of the software defense mechanism of canary in related technologies;

[0021] Figure 2a This is a schematic diagram of the encoding format of PAC in a 64-bit pointer in related technologies;

[0022] Figure 2b This is a schematic diagram of the PAC generation strategy in related technologies;

[0023] Figure 3 This is a schematic diagram of the PAC integrity protection mechanism in related technologies;

[0024] Figure 4 This is a schematic diagram of Intel's IPT tracing technology in related technologies;

[0025] Figure 5 This is a schematic diagram of the RISC-V PMP region in related technologies;

[0026] Figure 6 A schematic diagram of the hardware red zone monitored by the PMP inspection unit provided in another embodiment of this application;

[0027] Figure 7 A flowchart illustrating a pointer integrity protection method provided in one embodiment of this application;

[0028] Figure 8a A schematic diagram comparing the stack return address protection method provided in one embodiment of this application with stack return address protection methods in related technologies;

[0029] Figure 8b A schematic diagram illustrating stack return address protection in a recursive call scenario provided in another embodiment of this application;

[0030] Figure 9 This is a schematic diagram of the structure of a memory device provided in another embodiment of this application. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. 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.

[0032] Among software security issues, memory safety is currently the most significant threat posed by software security vulnerabilities. According to statistics, since 2015, 70% of security vulnerabilities in some browsers have been memory safety issues, causing huge potential economic losses to internet users.

[0033] In related technologies, pointer integrity protection is a means of memory security protection. Because programming languages ​​such as C and C++ use pointers that can directly access arbitrary memory and lack pointer access checks, system software written in them (firmware, operating system kernels, compilers, etc.) is subject to widespread memory security threats, such as buffer overflow vulnerabilities leading to the modification of the stack return address and triggering ROP attacks. Pointer integrity protection technology is used to prevent the modification and reuse of stack return addresses and function pointers due to memory corruption.

[0034] Pointer integrity solutions can be categorized into software and hardware solutions. Canary is a purely software-based defense mechanism for stack return address integrity, used to block ROP attacks caused by stack buffer overflows. The canary mechanism has been integrated into mainstream compilers such as GCC / LLVM and can be enabled via the fstack-protector-all compilation option, which is a basic requirement for trustworthy code in companies.

[0035] Figure 1 This is a schematic diagram of the software defense mechanism of canary in related technologies, such as... Figure 1 As shown, firstly, intermediate code instructions are inserted in the function call prologue, that is, when the stack frame is created, a large random number is inserted after the return address of the stack frame and the old stack pointer. Finally, a check instruction is inserted at the end of the function call to check whether the canary value in the stack frame has been modified. If it has been modified, the __stack_chk_fail exception handling function in the glibc library is entered.

[0036] Canary-based stack protection is a purely software-based technique with relatively weak protection capabilities. Attackers can dump the canary value from memory based on its relative position, thereby bypassing, leaking, and brute-forcing it. They can even hijack the control flow of the __stack_chk_fail exception handling function, rendering the canary's checking mechanism ineffective.

[0037] Hardware solutions for pointer integrity can include ARMv8's Pointer Authentication Code (PAC) technology and Intel's Processor Tracing technology. PAC, introduced in ARMv8.3-A in 2016, is a hardware primitive used for checking the integrity of code and data pointers. By designing new instructions such as pacia and autia on AArch64, a verification code is stored when the pointer is created, and verification and recovery are performed when the pointer is used, thus achieving runtime integrity protection.

[0038] Figure 2a This is a schematic diagram illustrating the encoding format of PAC in a 64-bit pointer in related technologies. Figure 2a This is a schematic diagram of the PAC generation strategy in related technologies, such as... Figure 2a and Figure 2b As shown, since the 64-bit pointer in the existing ARM (Advanced RISC Machines) processor 64-bit platform has high-order padding bits, these can be used to store some metadata information, such as PAC verification codes. The PAC code is used to identify the uniqueness of the pointer and is calculated by hashing the pointer value, context information (such as the current stack pointer value), and the hardware-derived key value.

[0039] Figure 3 This is a schematic diagram of the PAC integrity protection mechanism in related technologies, such as... Figure 3 As shown, in the ARM architecture, the Link Register (LR) is used to store the return address. First, the LR pointer is tagged by the pacia instruction. In the function call prologue, the newly generated return address is pushed onto the stack frame by the str LR instruction. If a buffer overflow occurs during function execution, the PAC value of the return address in the stack frame obtained by ldr LR will change. When the autia instruction is executed for matching check, it will be detected by the hardware unit.

[0040] Figure 4 This is a schematic diagram of Intel's IPT tracing technology in related technologies, such as... Figure 4As shown, Intel Processor Trace (IPT) technology is a hardware security feature introduced in Intel Core M and 5th generation Intel processors (2015). It is used to record real-time control flow information of program execution in the background in the form of packets. Its design goal is to be suitable for offline analysis, such as software troubleshooting. Due to the high overhead of decoding and restoring control flow information, it is not suitable for real-time inspection at runtime.

[0041] Based on the aforementioned hardware solution for pointer integrity, the PAC only supports 64-bit systems. This is because only with spare high-order bits in a 64-bit pointer can the PAC verification code be stored, and attackers can perform replay attacks to guess the PAC value and maliciously deceive the PAC check. Intel's IPT technology is more often used for offline analysis; decoding and restoring precise control flow information is costly and not suitable for runtime control flow integrity checks.

[0042] In some system architectures, only software protection for canary functions is provided, and the aforementioned hardware solutions for pointer integrity cannot be applied (a lack of pointer integrity hardware protection is present). For example, this might be a 32-bit system or a system unsuitable for runtime control flow integrity checks. In other words, system architectures like RISC-V typically only provide software protection for canary functions, lacking hardware security primitives for pointer integrity. Because hardware solutions are strongly architecture-dependent, it is difficult to smoothly migrate hardware designs from one architecture to another.

[0043] To overcome the above-mentioned technical problems, one embodiment of this application provides a pointer integrity protection method, which can add at least two user-configurable Physical Memory Protection (PMP) registers, including at least a user-mode PMP address register and a user-mode PMP configuration register. By delegating the capabilities of these at least two user-configurable registers to the user privilege level, user-configurability is achieved, thereby providing a user-configurable, fine-grained integrity protection strategy for code pointers within the user process space.

[0044] The pointer integrity protection method provided in this application involves PMP (Physical Memory Protection Unit). The RISC-V standard provides a hardware security primitive for physical memory protection—PMP—which achieves physical memory isolation by restricting access permissions from the U / S low privilege level to the M privilege level. The design of PMP is analogous to the ARM microprocessor (Memory Protection Unit, MPU) mechanism. Figure 5 This is a schematic diagram of the RISC-V PMP region in related technologies, such as... Figure 5As shown in the figure, it is implemented by adding a privileged mode register (hereinafter referred to as the privilege register) to define a PMP area, and using the hardware check unit running on the SOC to implement real-time access permission control for the PMP area.

[0045] A PMP area is controlled by two control and status registers (CSRs), and the two CSRs include a configuration register (pmpcfg) and an address register (pmpaddr). The pmpcfg configuration register is used to set read / write / execution permissions, and the pmpaddr address register is used to set the starting address. As shown in Table 1, the existing RISC-V supports 16 PMP areas, which are composed of 4 PMP configuration registers (pmpcfg0~pmpcfg3) and 16 pmp address registers (pmpaddr0~pmpaddr15), and are mapped in the 12-bit CSR address space (0x3A0~0x3BF). The [11:10] bits of the CSR represent four read / write permissions of readable, writable, unreadable and unwritable, and readable and unwritable. The [9:8] bits represent the access mode of the lowest privilege level allowed. RISC-V currently supports 3 privilege modes, specifically the user mode (U mode), the supervisor mode (S mode) and the machine mode (M mode).

[0046] Table 1

[0047]

[0048] Among them, the format of the configuration register (pmpcfg) is shown in Table 2:

[0049] Table 2

[0050]

[0051] Among them, R, W, and X correspond to read, write, and execute permissions respectively. For example, the value of 1 indicates that there is this permission, and the value of 0 indicates that there is no permission.

[0052] In addition, A represents the alignment method of the PMP area: 00 means not enabled, 01 means aligned according to the previous pmp address register, that is, pmpaddri−1 ≤ y<pmpaddri; 10 means 4-byte alignment, and 11 means alignment according to the power-of-2 byte.

[0053] The minimum of the PMP area of RISC-V supports 4-byte alignment. This fine-grained hardware security primitive can be used for the integrity protection of code pointers in bytes.

[0054] The pointer integrity protection method provided in this application embodiment offers a novel hardware security primitive based on the aforementioned PMP, maximizing the reuse of existing hardware circuitry and providing an architecture-dependent hardware solution for pointer integrity or control flow integrity. Specifically, at least two user-configurable PMP registers (referred to as uPMPs) can be added to provide a user-configurable, fine-grained integrity protection strategy for code pointers within the user process space. It should be noted that for a single process, one set (i.e., two) of PMP registers is sufficient to protect the stack return address; however, if the target code pointer is a function pointer, at least two PMP registers are required.

[0055] Regarding the addition of at least two user-configurable PMP registers, in the standard machine mode PMP-related CSR address register, bits [9:8] indicate that the lowest privilege level can access the CSR. By adding two address spaces, such as 0x006 and 0x007, two new registers pmpucfg and pmpuaddr are expanded, which together are called a set of uPMPs.

[0056] Among them, pmpucfg is the configuration register of the user-configurable uPMP. In one implementation, the basic format of pmpucfg can be the same as the standard pmpcfg. Its 32-bit format is shown in Table 3, where only pmp0ucfg is enabled, and the other pmp1ucfg~pmp3ucfg are reserved for extension.

[0057] Table 3

[0058]

[0059] Among them, the structure of the enabled pmp0ucfg is the same as the standard format, occupying one byte in size, as shown in Table 4. pmp0ucfg contains data bits such as L, A, X, W, and L.

[0060] Table 4

[0061]

[0062] The meaning and values ​​of the A field in pmp0ucfg are shown in Table 5:

[0063] Table 5

[0064]

[0065] The A field of pmp0ucfg indicates the alignment of uPMP, where 00 indicates that it is disabled; 01 indicates that a 4-byte read-only region with memory address [pmpuaddr, pmpuaddr+4] is defined; 10 indicates that a 8-byte read-only region with memory address [pmpuaddr, pmpuaddr+7] is defined; and 11 indicates that it is reserved.

[0066] The aforementioned read-only regions of length 4 bytes [pmpuaddr, pmpuaddr+4] or 8 bytes [pmpuaddr, pmpuaddr+7] can undergo integrity checks by the corresponding hardware PMP Checker to prevent the code pointers stored within these regions from being illegally tampered with. Here, "tampering" refers to an act that violates integrity; it is a cryptographic term indicating a malicious act; in other words, it signifies the intentional or malicious rewriting of the code pointers stored within the corresponding region. Figure 6 A schematic diagram of the hardware red zone monitored by the PMP inspection unit is provided in another embodiment of this application, as shown below. Figure 6 As shown, pointers 1 and 2 in the dashed box 61 represent the memory area protected by the uPMP configuration; other objects are not protected.

[0067] Figure 7 A flowchart illustrating a pointer integrity protection method provided in one embodiment of this application is shown below. Figure 7 As shown, the method includes:

[0068] Step 701: When the target code pointer is created, the memory area where the target code pointer is located is protected by a packer;

[0069] Step 702: During program execution, the memory access address of each memory access instruction is checked. When the memory access address from the address bus matches the memory region where the target code region is located, the uPMP hardware check strategy is implemented to determine whether the memory access action violates the configuration permissions of the uPMP configuration register. If the configuration permissions of the uPMP configuration register are violated, step 703 is executed. If the configuration permissions of the uPMP configuration register are not violated, step 704 is executed.

[0070] Step 703: Trigger the PMP exception handling process.

[0071] Step 704: The program continues to execute, and when the lifetime of the target code pointer ends, the packer protection on the memory region where the target code pointer is located is released.

[0072] In the specific implementation of step 701, when code pointers such as the stack return address are created, the memory area where the code pointer is located can be protected by the hardware red zone defined by uPMP by compiling intermediate code and instrumenting uPMP instructions.

[0073] In the specific implementation of step 702, when the target code pointer is used to access memory, if the address from the address bus matches the memory region where the target code pointer is located, and if a write operation is performed on that memory region, i.e. the current instruction is a store instruction, then a malicious write to the stack return address occurs. At this time, the program triggers a hardware exception and executes step 703. If it is determined that the integrity of the target code pointer has not been damaged, then execute step 704.

[0074] In the specific implementation of step 703, if it is determined that the integrity of the target code pointer has been compromised, for example, if the CPU is found to be performing a write (W) operation on the target code pointer in the memory region, the PMP exception handling process is triggered to prevent the target code pointer from being tampered with.

[0075] In the specific implementation of step 704, if it is determined that the integrity of the target code pointer has not been violated, the program continues to execute. For example, the CPU continues to perform read (R) operations on the target code pointer of that memory region. When the lifetime of the target code pointer ends, an instruction to unconfigure uPMP is instrumented at compile time to eliminate the scope of the hardware red zone. The hardware red zone protection capability is released with the destruction of the code pointer, and then waits for the next code pointer creation.

[0076] In one implementation, the return address in the stack frame can be protected for integrity.

[0077] Figure 8a This is a schematic diagram comparing a stack return address protection method provided in one embodiment of this application with stack return address protection methods in related technologies, as shown below. Figure 8a As shown, process 81 is a process for protecting the stack return address based on the canary protection mechanism in related technologies, and process 82 is a process for protecting the stack return address by means of hardware self-detection provided in the embodiments of this application.

[0078] In process 81, when a buffer overflow occurs in local variables, the canary value and return address will be overwritten consecutively. When the function call ends and the stack frame is released to check the canary value, it will find that the value is different from the original value (the original value is stored in a unified common area and obtained through register offset), which will trigger an exception.

[0079] Compared to process 81, in process 82 provided in this embodiment, uPMP protection code is inserted at any time after the return address is pushed onto the stack. The pmpuaddr and pmpucfg privileged registers are configured using a control state register write (CSR-W) instruction to ensure that the hardware red zone precisely covers the entire memory region where the return address is located. During function execution, before a buffer overflow occurs in local variables and an attempt is made to overwrite the return address, the PMP hardware check unit detects an illegal write operation from the CPU to the hardware red zone, triggering a PMP exception. If no memory corruption occurs, the corresponding csrw instruction is executed at the end of the function call to clear the uPMP-related address registers, avoiding redundant protection of already released memory regions.

[0080] Compared to process 81, process 82 provided in this application embodiment has several advantages in the implementation of integrity protection. First, it has less instrumentation code, removes some redundant instrumentation instructions, and eliminates the space overhead of the canary in the stack frame. Second, the pointer integrity check is automatically completed by hardware, which is simpler and more efficient than relying on instructions in pure software. Third, it can defend against software attacks such as canary bypass, leakage, and _stack_chk_fail hijacking. Fourth, exception handling is uniformly handled by hardware interrupt handlers, making the processing flow more unified and simpler than that of the canary handled by the library.

[0081] It should be further explained that if only one set of privileged registers for uPMP is defined, in certain scenarios (e.g., recursive calls, scenarios where multiple stacks are pushed simultaneously), without dynamic maintenance, the register resources at the logical level will be exhausted.

[0082] To address the aforementioned technical issues, the automatic maintenance of the stack pointer within the stack frame can be utilized. By combining the return address and the relative position of the stack pointer, the uPMP hardware red zone can be automatically updated based on the position of the old stack pointer.

[0083] Figure 8b This is a schematic diagram illustrating stack return address protection in a recursive call scenario provided in another embodiment of this application, as shown below. Figure 8bAs shown, there is currently stack frame N. The uPMP hardware red zone protects the return address 1 of stack frame N. When stack frame N+1 is created, the uPMP position also moves with the creation of the new stack frame, thus protecting the new return address 2. Since buffer overflows in the stack are continuous reads and writes, without considering skip-overwrite operations, protecting the integrity of return address 2 also protects the integrity of return address 1. The creation of the entire hardware red zone and... Figure 8a The creation method provided in the illustrated embodiment is the same, the difference being that when the new stack (stack frame N+1) is released, the value of the pmpuaddr register needs to be set to the old stack (stack frame N) pointer + 4. By taking advantage of the characteristic that the return address is always adjacent to the stack frame pointer, the protected position of the previous stack frame N can be automatically restored.

[0084] Regarding the protection of code pointer integrity, in another implementation, the code pointer can also protect the integrity of function pointers. For example, for the function pointer `func`, uPMP can be used for packing protection when the function pointer is assigned a value, integrity checks can be performed by the PMP checking unit when the function pointer is called, and the uPMP packing protection can be removed after the function pointer call ends.

[0085] It should be noted that during the integrity protection of function pointers, issues such as pointer propagation can lead to exhaustion of uPMP's logic-level registers.

[0086] To address the aforementioned technical issues, new instructions could be designed for creating function pointers, unifying creation and reading / writing within a single, unified area protected by uPMP hardware red zones. However, this requires further exploration and development of more suitable solutions, although uPMP provides a basic level of protection.

[0087] Figure 9 This is a schematic diagram of the structure of a memory device provided in another embodiment of this application, as shown below. Figure 9 As shown, the device may include a processor 91 and a memory 92, wherein the memory 92 is used to store at least one instruction, which is loaded and executed by the processor 91 to implement the pointer integrity protection method provided in any embodiment of this application.

[0088] This application also provides an electronic device, which may include... Figure 9 The memory device provided in the illustrated embodiment.

[0089] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the pointer integrity protection method provided in any embodiment of this application.

[0090] This application also provides a computer program product, including a computer program or instructions, which, when processed, implement the pointer integrity protection method provided in any embodiment of this application.

[0091] It is understood that the application may be a native application installed on the terminal, or it may be a web application of a browser on the terminal. This application embodiment does not limit this.

[0092] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0093] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0094] 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0095] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0096] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some 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.

[0097] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

[0098] 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 or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A pointer integrity protection method, characterized in that, The method is applied to a memory device having user-configurable privileged registers, including: When the target code pointer is created, the memory area where the target code pointer is located is protected by a packer. When accessing memory using the target code pointer, a hardware checking unit performs a pointer integrity check on the memory region where the target code pointer is located. If any tampering of the target code pointer is detected, the PMP exception handling process is triggered. Before applying a packer to the memory region where the target code pointer resides when the target code pointer is created, the following steps are also included: At least two user-configurable privileged registers are extended in the memory device to provide the memory device having user-configurable privileged registers; The at least two user-configurable privileged registers include at least one user-mode PMP address register and one user-mode PMP configuration register.

2. The method according to claim 1, characterized in that, The step of adding a packer to the memory region where the target code pointer is located when the target code pointer is created includes: When the target code pointer is created, the memory region where the target code pointer is located is protected by hardware red zones by instrumenting instructions that configure the at least two user-configurable privileged registers. The hardware red zones are the protected regions defined by the at least two user-configurable privileged registers.

3. The method according to claim 1, characterized in that, After the hardware inspection unit performs a pointer integrity check on the memory region where the target code pointer is located, if it is determined that no tampering operation has occurred with the target code pointer, the packing protection on the memory region where the target code pointer is located is released when the life cycle of the target code pointer ends.

4. The method according to any one of claims 1-2, characterized in that, The target code pointer includes the return address or function pointer in the stack frame.

5. The method according to claim 4, characterized in that, When the target code pointer is the return address in the stack frame, in a recursive call scenario, after the packing protection of the new stack N+1 is released, the packing protection of the return address in the old stack N is restored, wherein the new stack N+1 and the old stack N are adjacent stacks.

6. A memory device, characterized in that, The device includes: A processor and a memory, the memory being used to store at least one instruction, which, when loaded and executed by the processor, implements the pointer integrity protection method as described in any one of claims 1-5.

7. A chip, characterized in that, The chip includes the memory device as described in claim 6.

8. An electronic device, characterized in that, The electronic device includes the memory device of claim 6 or the chip of claim 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the pointer integrity protection method as described in any one of claims 1-5.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are processed, they implement the pointer integrity protection method as described in any one of claims 1-5.

Images