Memory vulnerability repair method, computer device and readable storage medium

Abstract

The application provides a vulnerability repair method of a memory, a computer device and a readable storage medium. The method comprises the following steps: obtaining an exception type corresponding to hardware exception trigger information, such as memory protection unit exception; obtaining information of a fault address recorded by a fault address register; when the exception type is a breakpoint exception, querying information of a breakpoint address triggering the breakpoint exception; querying address information of a repair function from a vulnerability modification mapping table; obtaining a first vulnerability type of a vulnerability corresponding to a current exception condition, such as a function-level vulnerability; extracting function parameters from a stack register and calling the repair function when the first vulnerability type is the function-level vulnerability; analyzing a vulnerability instruction and calling the repair function when the first vulnerability type is an instruction-level vulnerability; and executing the called repair function. The application also provides a computer device and a readable storage medium for implementing the above method. The application implements vulnerability repair by reusing a memory protection unit and a breakpoint module of an original processor.

Description

Technical Field

[0001] This invention relates to the field of memory vulnerability repair technology, specifically, to a memory vulnerability repair method and a computer device and computer-readable storage medium for implementing this method. Background Technology

[0002] Embedded systems and various chips widely use read-only memory (ROM). ROM has the advantage of not losing data when power is off. It is usually used as a key carrier for hard-coded programs and core data. Once the code stored in ROM is burned, it cannot be modified. Therefore, it can ensure the basic stability of the system and ensure that the system code will not be tampered with and affect the operation of the system.

[0003] However, the immutability of code in read-only memory (ROM) presents a fatal flaw. If the code stored in ROM is faulty, especially the underlying fundamental functions, the inability to correct it necessitates discarding the problematic code. Related code along the faulty path may also need to be discarded, leading to the failure of core system functions or even complete system paralysis. For example, vulnerabilities in low-level functions such as the bootloader and hardware initialization can render all upper-level modules that depend on these functions inoperable. Traditional solutions require hardware redundancy or complete firmware updates to mitigate this risk, but these approaches are costly and lack flexibility. Therefore, dynamically fixing errors in embedded code without modifying the physical storage of ROM has become a critical and urgent problem to solve.

[0004] The existing processing methods mainly include the following three:

[0005] The first method is static pre-reserved function repair. This involves pre-grouping function tables and callback pointers during the read-only memory (ROM) development phase, dividing functions into multiple groups according to preset rules, and configuring an independent function table and number for each group. When repairing ROM, the corresponding function table is found based on the group number, copied to a designated storage area to generate a new table, and the access address is updated. Finally, function replacement is achieved through pointer redirection in the random access memory (RAM). However, this method relies on static presets during development and has poor adaptability to undefined vulnerabilities or dynamic scenarios. Furthermore, in situations where potential vulnerabilities cannot be predicted, a large number of callback pointers need to be reserved, leading to a surge in ROM space usage, a significant reduction in the proportion of effective code, and severely impacting ROM storage efficiency.

[0006] The second approach is to use proprietary hardware comparison-based breakpoint repair. This method requires designing a separate program counter address comparison circuit and control logic. At the hardware level, it captures the "address of the program to be repaired" stored in the breakpoint interrupt register and compares it in real-time with the central processing unit's program counter. Once an address match is found, an interrupt is forcibly triggered to prevent the execution of the problematic code, and the repair logic is invoked through a preset mapping relationship. However, this method requires additional proprietary comparison hardware, increasing chip design complexity and leading to higher chip manufacturing costs. Furthermore, this repair process relies on a fixed mapping table, making it difficult to handle dynamic scenarios such as address reuse in multi-tasking environments, resulting in significant hardware redundancy and insufficient adaptability.

[0007] The third approach is a single-architecture memory protection unit (MPU) interception-based repair solution. This method utilizes the MPU's data access protection mechanism to set the address of the problematic function to a "CPU-unreadable region." When the program accesses the problematic function, an interrupt is triggered in the MPU, jumping to the interrupt handler to execute the patch logic. However, this method is only compatible with the ARM architecture and not with other mainstream architectures. Furthermore, the MPU is statically locked, making it impossible to dynamically switch protection strategies based on the scenario. It also lacks the ability to combine with the processor's native breakpoint functionality for precise interception, resulting in significant shortcomings in both applicability and repair efficiency. Summary of the Invention

[0008] The primary objective of this invention is to provide a memory vulnerability repair method that combines a processor's memory protection unit with breakpoint functionality to achieve precise interception and repair of vulnerable code.

[0009] A second objective of the present invention is to provide a computer device for implementing the above-described method for fixing vulnerabilities in memory.

[0010] A third objective of this invention is to provide a readable storage medium for implementing the aforementioned method for fixing vulnerabilities in a memory.

[0011] To achieve the first objective of this invention, the memory vulnerability repair method provided by this invention includes: obtaining the exception type corresponding to the hardware exception triggering information; for example, if the exception type is a memory protection unit exception, obtaining the fault address information recorded in the fault address register; if the exception type is a breakpoint exception, querying the breakpoint address information that triggered the breakpoint exception; querying the address information of the repair function from the vulnerability modification mapping table according to the fault address or breakpoint address; obtaining the first vulnerability type of the vulnerability corresponding to the current exception situation; if the first vulnerability type is a function-level vulnerability, extracting the function parameters from the stack register and calling the repair function; if the first vulnerability type is an instruction-level vulnerability, analyzing the vulnerability instruction and calling the repair function; and executing the called repair function.

[0012] As can be seen from the above scheme, this invention utilizes the processor's native memory protection unit and breakpoint module to achieve vulnerability interception and repair. By identifying the first vulnerability type of the vulnerable function, function-level vulnerabilities are repaired using the memory protection unit, while instruction-level vulnerabilities are repaired using the breakpoint module. Since both the memory protection unit and the breakpoint module are native processor modules, this invention, by reusing the processor's native memory protection unit and breakpoint module for vulnerability repair, does not require adding additional modules or employing complex algorithms, thus reducing the cost of vulnerability interception and repair.

[0013] Furthermore, since this invention distinguishes between function-level vulnerabilities and instruction-level vulnerabilities, and uses different methods to repair the two types of vulnerabilities respectively, it achieves the interception of the two different types of vulnerabilities by configuring the memory protection unit and matching the breakpoint address of the breakpoint module. The vulnerability interception is more accurate, and the real-time performance of instruction-level vulnerability repair is also met.

[0014] A preferred approach is to obtain the registration information of the new vulnerability and its second vulnerability type. For example, if the newly registered vulnerability is a function-level vulnerability, the address range of the vulnerable function of the function-level vulnerability is configured to be non-executable through the memory protection unit; if the newly registered vulnerability is an instruction-level vulnerability, the address of the vulnerable instruction of the instruction-level vulnerability is written to the breakpoint register through the breakpoint module.

[0015] Therefore, when registering new vulnerabilities, differentiating between different types of vulnerabilities—for function-level vulnerabilities, prioritizing the use of memory protection units for configuring vulnerable functions, and for instruction-level vulnerabilities, prioritizing the use of breakpoint modules for configuring vulnerable functions—ensures that both types of vulnerabilities can be accurately intercepted subsequently, and that real-time remediation is possible.

[0016] A preferred approach is to configure the address range of the vulnerable function of the function-level vulnerability to be non-executable through the memory protection unit, including: setting the region base address register of the memory protection unit to the starting address of the vulnerable function, setting the length of the vulnerable function, and setting the address range corresponding to the vulnerable function to be non-executable in the region attribute register of the memory protection unit; or setting the address range of the vulnerable function through the address register and setting the address range corresponding to the vulnerable function to be non-executable.

[0017] Therefore, by adopting corresponding processing methods for processors with different architectures such as ARM and RISC-V, it is possible to configure the address range of vulnerable functions for function-level vulnerabilities without adding extra modules.

[0018] A further approach is to write the address of the vulnerable instruction of the instruction-level vulnerability into the breakpoint register through the breakpoint module. This includes: setting the instruction address of the vulnerable function through the comparison register of the breakpoint module and setting the replacement mode of the instruction address of the vulnerable function; or obtaining the index information of the breakpoint register, setting the address of the vulnerable instruction to the breakpoint address recorded in the breakpoint register, and setting the enable bit and trigger parameters.

[0019] Therefore, when writing to the vulnerable instruction address of the instruction-level vulnerability, the native registers of ARM and RISC-V are used respectively for the two different architectures, without the need to add external devices or modules, thus avoiding increasing the cost of vulnerability repair.

[0020] A further approach is to, if it is confirmed that a newly registered vulnerability is a function-level vulnerability, before configuring the address range of the vulnerable function of the function-level vulnerability to be non-executable through the memory protection unit, confirm that the total number of all function-level vulnerabilities does not exceed the upper limit of entries recorded by the memory protection unit.

[0021] Therefore, as long as the total number of all function-level vulnerabilities does not exceed the upper limit of the entries recorded in the memory protection unit, all function-level vulnerabilities can be configured in the memory protection unit at once to ensure the uniformity of the configuration.

[0022] A further approach is to store the configuration information of active vulnerability-level functions in the current scenario through the memory protection unit if the total number of all function-level vulnerabilities exceeds the upper limit of entries recorded by the memory protection unit, and store the configuration information of function-level vulnerabilities in inactive scenarios in the scenario cache of random access memory.

[0023] Therefore, when the total number of all function-level vulnerabilities exceeds the upper limit of entries recorded by the memory protection unit, the configuration information of function-level vulnerabilities in inactive scenarios is stored in the scenario cache of random access memory. In subsequent processing, time-division multiplexing is used to dynamically adjust the information according to the scenario situation to meet the usage requirements of different scenarios.

[0024] A further approach is to update the storage of configuration information for each function-level vulnerability via synchronization instructions when the current operating scenario changes.

[0025] Therefore, it can be seen that when switching scenarios, the configuration updates of each function-level vulnerability can be achieved through synchronization instructions, which can flexibly and quickly realize the configuration updates of vulnerability functions during scenario switching.

[0026] A further proposed approach is to merge the address range of a newly registered function-level vulnerability into a single entry if the address range of the newly registered function-level vulnerability is continuous with the address range of an existing function-level vulnerability, and both the address ranges of the newly registered function-level vulnerability and the address ranges of the existing function-level vulnerability are configured as non-executable.

[0027] Therefore, by merging newly registered vulnerabilities and existing vulnerabilities that meet the requirements, the number of entries occupied by the memory protection unit can be reduced, thereby enabling the memory protection unit to configure more vulnerability functions and make full use of the memory protection unit's resources.

[0028] To achieve the second objective described above, the computer device provided by the present invention includes a processor and a memory, the memory storing a computer program, and when the computer program is executed by the processor, it implements the various steps of the aforementioned memory vulnerability repair method.

[0029] To achieve the third objective described above, the present invention provides a readable storage medium storing a computer program, which, when executed by a processor, implements the various steps of the aforementioned memory vulnerability repair method. Attached Figure Description

[0030] Figure 1 This is a flowchart of an embodiment of the memory vulnerability repair method of the present invention.

[0031] Figure 2 This is the first part of the flowchart for registering a new vulnerability in an embodiment of the vulnerability repair method for the memory of the present invention.

[0032] Figure 3 This is the second part of the flowchart for registering a new vulnerability in an embodiment of the vulnerability repair method for the memory of the present invention.

[0033] The present invention will be further described below with reference to the accompanying drawings and embodiments. Detailed Implementation

[0034] The memory vulnerability repair method of this invention is mainly used to repair vulnerabilities in code stored in read-only memory (ROM). It utilizes the native memory protection unit and breakpoint module of ARM or RISC-V processors to intercept and repair vulnerable functions, thereby achieving low-cost and accurate interception and repair of vulnerable functions. The method of this invention can be implemented on a computer device having a processor and a memory, which is the readable storage medium of this invention. The memory stores a computer program, and when the computer program is executed by the processor, it represents the various steps of the aforementioned memory vulnerability repair method.

[0035] Example of a method for patching vulnerabilities in memory:

[0036] This embodiment can be applied to chips based on ARM or RISC-V architecture processors. Since ARM or RISC-V architecture processors natively integrate memory protection units and breakpoint modules, this embodiment utilizes the processor's native memory protection units and breakpoint modules to intercept and repair vulnerabilities, achieving vulnerability repair without adding additional devices or modules to the chip.

[0037] In the ARM architecture, the memory protection unit is called the MPU (Memory Protection Unit), which supports 2 to 16 protection entries. The address range is configured through the region base address register (MPU_RBAR) and the region attribute register (MPU_RASR). The XN bit (eXecute Never) of the region attribute register is used to disable instruction execution, thus setting the non-executable range of vulnerable functions. In the RISC-V architecture, the memory protection unit is called the PMP (Physical Memory Protection), which supports 4 to 16 protection entries. The memory protection range is defined through the attribute configuration registers (pmpcfg0-pmpcfg3) and the address registers (pmpaddr0-pmpaddr15). The execute permission bit (pmpcfg[n].X) can be set to 0 to disable instruction execution.

[0038] In the ARM architecture, the breakpoint module is called the FPB (Flash Patch and Breakpoint Unit), which includes a global control register (FP_CTRL), a remapped base address register (FP_REMAP), and a comparator configuration register (FP_COMPn), where n takes a value from 0 to 5, meaning there are a total of 5 comparator configuration registers. In the RISC-V architecture, the breakpoint module is called the Trigger Module. The trigger module in the RISC-V processor uses register select instructions (tselect), control configuration data (tdata1), and breakpoint addresses (tdata2) to intercept instruction-level vulnerabilities.

[0039] See Figure 1 In this embodiment, step S11 is executed first to obtain hardware exception triggering information. For example, when the program executed by the processor runs to the vulnerable code, the hardware automatically triggers an exception, that is, hardware exception triggering information is generated and the exception service function is entered.

[0040] Then, step S12 is executed to determine whether the hardware exception triggering information is a memory protection unit exception or a breakpoint exception. This requires obtaining the exception type corresponding to the hardware exception triggering information. If the exception type is a memory protection unit exception, step S13 is executed to obtain the fault address information recorded in the fault address register. For ARM architecture processors, the processor memory management fault address register (MMFAR) is used to obtain the violation address, i.e., the fault address, and the fault status register (MMFSR) confirms that the program currently has a violation of execution permissions. For RISC-V architecture processors, the fault address is obtained through the trap value register (mtval), and the trap cause register (mcause) identifies it as a "load / store fault".

[0041] If step S12 confirms that the current exception type is a breakpoint exception, then step S14 is executed. For ARM architecture processors, the address triggering the breakpoint exception is looked up in reverse using the comparator configuration register (FP_COMPn), and the breakpoint event is marked by the debug fault status register (HFSR). For RISC-V architecture processors, the breakpoint address is read by identifying the data in tdata2, and the current exception condition is identified as a "breakpoint trap" using the trap cause register (mcause).

[0042] Steps S13 and S14 obtain the fault address or breakpoint address that triggered the exception. Then, step S15 is executed to query the address information of the corresponding repair function from the vulnerability repair mapping table. Since newly discovered vulnerabilities need to be registered upon discovery, and a mapping relationship needs to be established between the vulnerable function and the repair function after registration, a vulnerability repair mapping table needs to be constructed. This table records the mapping relationship between each vulnerable function and its corresponding repair function. Because the vulnerability repair mapping table is pre-built, step S15 obtains the address information of the repair function by querying the vulnerability repair mapping table. Thus, once the program runs to the address corresponding to the vulnerable function, it will not execute the vulnerable function but will jump to execute the repair function.

[0043] Then, step S16 is executed to determine the first vulnerability type that triggered the exception. Specifically, it is necessary to obtain the first vulnerability type that triggered the exception and determine whether the current vulnerability is a function-level vulnerability or an instruction-level vulnerability. This embodiment uses different interception configurations for function-level and instruction-level vulnerabilities. Since the interception of function-level vulnerabilities has the characteristics of large area and low real-time performance, the interception strategy configures the address range of the vulnerable function in the read-only memory as "non-executable" through the memory protection unit. For example, for ARM architecture processors, the region base address register (MPU_RBAR) can be set to the starting address of the vulnerable function, the region attribute register (MPU_RASR) can be configured to the length of the vulnerable function, and the XN bit can be set to 1, that is, the address corresponding to the vulnerable function can be set as non-executable. If it is a RISC-V architecture processor, the address range of the vulnerable function is defined through the address register, the attribute configuration register is configured with X as 0, indicating that the code at the address corresponding to the vulnerable function is prohibited from execution, and the boundary address mode is set.

[0044] Interception of instruction-level vulnerabilities is characterized by precision and high real-time performance. The interception strategy involves writing the address of the vulnerable instruction into the breakpoint register using a breakpoint module. For example, for ARM architecture processors, the address of the vulnerable instruction is set through the comparator configuration register, along with the enable bit and replacement mode. Since ARM architecture processors process both 16-bit and 32-bit instructions, the replacement mode will vary depending on the vulnerability: if the vulnerable function is a lower nibble, the replacement mode will replace the lower nibble; if it's a higher nibble, the replacement mode will replace the higher nibble; and if the vulnerable function is a whole byte, the replacement mode will replace the entire byte. For RISC-V architecture processors, the breakpoint register index information needs to be obtained, and the address of the vulnerable instruction needs to be written into the field corresponding to the breakpoint address. The enable bit and trigger parameters need to be set in the control configuration data.

[0045] Based on the differences mentioned above, the methods for fixing function-level vulnerabilities and instruction-level vulnerabilities also differ. If the current vulnerability is a function-level vulnerability, then step S17 is executed, which retrieves the function parameters from the push registers and calls the fix function. For ARM architecture processors, the function parameters are retrieved from the automatically pushed values ​​of registers R0 to R3, a method that conforms to the ATPCS calling convention. For RISC-V architecture processors, the manually pushed parameter registers are read at the exception entry point, and the parameters are retrieved from the stack.

[0046] If the current vulnerability is an instruction-level vulnerability, then step S18 is executed to analyze the vulnerable instruction and call the remediation function. Specifically, for instruction-level vulnerabilities, no parameter passing is required; the opcode and operands of the vulnerable instruction are directly analyzed. For example, for 32-bit instruction encoding of the ARM architecture or 16 / 32-bit instruction format of the RISC-V architecture, a refined remediation function is called, such as instruction substitution, conditional jump correction, etc.

[0047] Finally, step S19 is executed, which calls the repair function. If the processor is based on an ARM architecture, the value of the program counter stored on the stack is modified to the address of the next execution instruction of the vulnerable function. The branch instruction with state switching is executed, and the stack frame is popped to resume execution. If the processor is based on a RISC-V architecture, the safe return address is written to the machine exception program counter (mepc), the machine mode return instruction (MRET) is executed, and the execution flow is resumed.

[0048] This embodiment distinguishes between different types of vulnerabilities and adopts different recovery measures accordingly. Furthermore, the hardware resources used are memory protection units and breakpoint modules natively integrated into processors with ARM or RISC-V architectures. Therefore, it can achieve vulnerability interception and recovery without adding extra hardware resources to the chip, thus reducing the cost of vulnerability recovery.

[0049] Typically, read-only memory (ROM) vulnerabilities are discovered manually. Once a vulnerability is found in the code, it needs to be registered. The following section combines... Figure 2 and Figure 3 The registration process for a new vulnerability is described below. First, step S21 is executed to obtain the registration information for the new vulnerability. For example, after a developer discovers a new vulnerability, the address of the code corresponding to that vulnerability is determined. Then, step S22 is executed to determine the second vulnerability type of the newly registered vulnerability, that is, whether the vulnerability is a function-level vulnerability or an instruction-level vulnerability. For function-level vulnerabilities, memory protection units are prioritized for configuring the vulnerable function; for instruction-level vulnerabilities, breakpoint modules are prioritized for configuring the vulnerable function.

[0050] If the judgment result of step S22 is negative, it indicates that the vulnerability is an instruction-level vulnerability. Then, step S23 is executed, in which the address of the vulnerable instruction is written to the breakpoint register through the breakpoint module. As mentioned earlier, if it is an ARM architecture processor, step S23 sets the instruction address of the vulnerable function through the comparison register of the breakpoint module and sets the replacement mode of the instruction address of the vulnerable function. If it is a RISC-V architecture processor, the index information of the breakpoint register is obtained, the address of the vulnerable instruction is set to the breakpoint address recorded in the breakpoint register, and the enable bit and trigger parameters are set.

[0051] If the result of step S22 is yes, it indicates that the current vulnerability is a function-level vulnerability. Then, step S24 is executed to determine if the memory protection unit has sufficient entry resources. Since the number of protection entries in the memory protection unit is limited, if the number of current function-level vulnerabilities is large, exceeding the number of protection entries in the memory protection unit, vulnerability merging or time-division multiplexing is required to configure some vulnerabilities in the scenario buffer. If the result of step S24 is yes, it indicates that the number of protection entries in the memory protection unit is greater than or equal to the total number of current function-level vulnerabilities. Therefore, step S25 is executed to configure the address range of the newly registered function-level vulnerability's vulnerable function as non-executable through the memory protection unit. As mentioned earlier, for ARM architecture processors, the region base address register of the memory protection unit is set to the starting address of the vulnerable function, and the length of the vulnerable function is set. The address range corresponding to the vulnerable function is set as non-executable in the region attribute register of the memory protection unit. For RISC-V architecture processors, the address range of the vulnerable function is set through the address register, and the address range corresponding to the vulnerable function is set as non-executable.

[0052] If the judgment result of step S24 is negative, it means that the number of protection entries in the memory protection unit is less than the total number of current function-level vulnerabilities. Step S26 is then executed to obtain the merging strategy for multiple vulnerable functions. In this embodiment, whether multiple function-level vulnerabilities can be merged depends on the following factors: First, whether the addresses corresponding to the multiple vulnerable functions are consecutive addresses, i.e., whether there are gaps between the addresses of the multiple vulnerable functions. For example, if the address of the first vulnerable function is 0x8000 to 0x8010 and the address of the second vulnerable function is 0x8010 to 0x8020, then the addresses of these two functions are consecutive. Second, whether the permissions corresponding to the multiple vulnerable functions to be merged are consistent. If the permissions corresponding to the multiple vulnerable functions are all configured as "non-executable," then the permissions corresponding to these multiple vulnerable functions are considered consistent. Finally, it is determined whether the alignment constraints of the multiple vulnerable functions meet the requirements. For example, under the ARM architecture, multiple vulnerable functions need to meet the 32-byte alignment requirement; under the RISC-V architecture, multiple vulnerable functions need to meet the natural alignment power mode requirement.

[0053] After obtaining the merging strategy for multiple vulnerable functions, it is necessary to determine whether each vulnerable function meets the merging requirements. Specifically, first, step S27 is executed to determine whether the address of the newly registered vulnerable function is continuous with the address of an existing vulnerable function. If they are not continuous, step S30 is executed to configure each function-level vulnerability using a scenario-based time-division multiplexing approach. If the address of the newly registered vulnerable function is continuous with the address of an existing vulnerable function, step S28 is executed to further determine whether the access permissions of the newly registered vulnerability are consistent with those of the existing vulnerabilities. If they are inconsistent, step S30 is executed. If they are consistent, step S29 is also executed to determine whether the vulnerable function of the newly registered vulnerability meets the alignment constraint requirements of the existing vulnerability functions. If they do not meet the requirement, step S30 is executed. If they do meet the requirement, step S31 is executed to generate a merging entry, merging multiple vulnerabilities that can be merged into a single protection entry. This protection entry needs to record the addresses of the multiple vulnerabilities to be merged. Furthermore, when generating the merging entry, the function boundary symbol table generated during the compilation stage needs to be used to ensure that the merged region does not contain non-vulnerable code, avoiding erroneous interception during subsequent code execution.

[0054] After entering the scene time-division multiplexing, step S32 needs to be executed to identify the ID of the current scene, configure the protection entries for the active vulnerability functions in the current scene through the memory protection unit, and execute step S33. For the vulnerability functions in the inactive scene, the configuration information of the vulnerability functions is saved to the scene cache area of ​​Always-On RAM.

[0055] During subsequent operation, if the current scenario changes, a scenario switch is required. This involves updating the storage of configuration information for each function-level vulnerability using synchronization instructions. For example, for ARM architecture processors, data synchronization barriers and instruction synchronization barriers are used to switch between vulnerability-level functions. For RISC-V architecture processors, synchronization instructions (FENCE.I) are used to refresh the configuration information for each function-level vulnerability, ensuring that the new configuration information takes effect.

[0056] After executing step S33, step S34 needs to be executed to load the configuration information of the target scenario, that is, to load the configuration information of each function-level vulnerability in the currently running scenario. Then, step S35 is executed to update the configuration information stored in each register. At this point, the dynamic resource allocation for function-level vulnerabilities is completed.

[0057] As can be seen, this embodiment dynamically manages the resources of the memory protection unit and the breakpoint module based on the number and distribution characteristics of function-level vulnerabilities. When the number of function-level vulnerabilities is less than or equal to the number of protection entries in the memory protection unit, all function-level vulnerabilities are configured as non-executable at once through the memory protection unit, and there is no need to consider the scenario switching issue during subsequent runtime. When the number of function-level vulnerabilities exceeds the number of protection entries in the memory protection unit, it is necessary to flexibly allocate inactive function-level vulnerabilities in the current scenario to the scenario cache area according to the current scenario situation, and flexibly switch the configuration of each function-level vulnerability according to the current scenario switching during subsequent runtime.

[0058] If a newly registered function-level vulnerability is eligible to be merged with an existing function-level vulnerability, after merging in step S31, step S36 will be executed, which will release redundant entries. This means releasing the protection entries of the memory protection unit that were originally occupied, thereby avoiding the occupation of the protection entries of the memory protection unit. The released protection entries can be used to configure other function-level vulnerabilities, thereby making full use of the protection entries of the memory protection unit.

[0059] Finally, step S36 is executed, which determines the resources required for the newly registered vulnerability based on the previous steps, such as whether it occupies the protection entry of the memory protection unit or is allocated to the scene cache area. Based on the determined hardware resources, the corresponding resources are allocated to the newly registered vulnerability, thereby configuring the newly registered vulnerability on the corresponding resources.

[0060] This invention utilizes the native memory protection unit and breakpoint module of ARM or RISC-V architecture processors to fix read-only memory vulnerabilities, eliminating the need for additional hardware costs and enabling low-cost fixes of vulnerable functions. Furthermore, this invention strictly adheres to the specifications of ARM and RISC-V architectures during vulnerability repair, fully leveraging their hardware resources.

[0061] This invention differentiates between vulnerability types, prioritizing the use of memory protection units for function-level vulnerabilities and breakpoint modules for instruction-level vulnerabilities, thereby achieving tiered interception of different vulnerability types. Since the real-time and precision requirements for patching differ between the two vulnerability types, this tiered interception approach improves the accuracy of vulnerability interception while ensuring that the real-time requirements of different vulnerability types are met.

[0062] Finally, for function-level vulnerabilities, when the number of protection entries in the memory protection unit is insufficient, the hardware resources of various memory can be fully utilized by using scenario time-sharing multiplexing and boundary security entry merging processing methods, making the interception and repair of vulnerabilities more flexible and efficient, and achieving the interception and repair of a larger number of vulnerabilities under limited resource conditions.

[0063] Computer device embodiment:

[0064] The computer device in this embodiment can be various types of computer devices, such as desktop computers, laptops, data processing servers, etc. The computer device has a processor, a memory, and a computer program stored in the memory and executable on the processor, such as an information processing program for implementing the above-described information processing method. When the processor executes the computer program, it implements each step of the above-described memory vulnerability repair method.

[0065] For example, a computer program can be divided into one or more modules, one or more of which are stored in memory and executed by a processor to complete the various modules of the present invention. One or more modules can be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in a terminal device.

[0066] The processor referred to in this invention can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the terminal device, connecting various parts of the terminal device through various interfaces and lines.

[0067] Memory can be used to store computer programs and / or modules. The processor implements various functions of the terminal device by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function, etc.; the data storage area may store data created based on the use of the mobile phone, etc. In addition, memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital cards (SD cards), flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0068] Storage medium examples:

[0069] If a computer program stored in a computer device is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the various steps of the above-described memory vulnerability repair method.

[0070] Computer programs include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Computer-readable media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in computer-readable media can be appropriately added to or subtracted according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0071] Finally, it should be emphasized that the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for patching vulnerabilities in a memory, characterized in that, include: Obtain the exception type corresponding to the hardware exception trigger information. If the exception type is a memory protection unit exception, obtain the fault address information recorded in the fault address register. If the exception type is a breakpoint exception, then query the information of the breakpoint address that triggered the breakpoint exception; Based on the fault address or the breakpoint address, query the address information of the repair function from the vulnerability modification mapping table; Obtain the first vulnerability type corresponding to the current abnormal situation. If the first vulnerability type is a function-level vulnerability, extract the function parameters from the stack register and call the repair function. If the first vulnerability type is an instruction-level vulnerability, analyze the vulnerable instruction and call the repair function. Execute the called repair function; Obtain the second vulnerability type from the new vulnerability registration information. If the second vulnerability type is a function-level vulnerability, configure the address range of the vulnerable function of that function-level vulnerability to be non-executable through the memory protection unit, including: Set the region base address register of the memory protection unit to the starting address of the vulnerable function, set the length of the vulnerable function, and set the address range corresponding to the vulnerable function to non-executable in the region attribute register of the memory protection unit; or The address range of the vulnerable function is set by the address register, and the address range corresponding to the vulnerable function is set to be non-executable.

2. The memory vulnerability repair method according to claim 1, characterized in that, The method also includes: After obtaining the new vulnerability registration information and the second vulnerability type, if the second vulnerability type is an instruction-level vulnerability, the address of the vulnerability instruction of the instruction-level vulnerability is written to the breakpoint register through the breakpoint module.

3. The memory vulnerability repair method according to claim 2, characterized in that: Writing the address of the vulnerable instruction of an instruction-level vulnerability to the breakpoint register using the breakpoint module includes: The instruction address of the vulnerable function is set through the comparison register of the breakpoint module, and the replacement mode of the instruction address of the vulnerable function is set; or Obtain the index information of the breakpoint register, set the address of the vulnerable instruction to the breakpoint address recorded in the breakpoint register, and set the enable bit and trigger parameters.

4. The memory vulnerability repair method according to claim 2 or 3, characterized in that: If a newly registered vulnerability is confirmed to be a function-level vulnerability, before configuring the address range of the vulnerable function of the function-level vulnerability to be non-executable through the memory protection unit, confirm that the total number of all function-level vulnerabilities does not exceed the upper limit of entries recorded by the memory protection unit.

5. The memory vulnerability repair method according to claim 4, characterized in that: If the total number of all function-level vulnerabilities exceeds the upper limit of entries recorded by the memory protection unit, the configuration information of active vulnerability-level functions in the current scenario is stored in the memory protection unit, and the configuration information of function-level vulnerabilities in inactive scenarios is stored in the scenario cache area of ​​the random access memory.

6. The memory vulnerability repair method according to claim 5, characterized in that: If the current operating scenario changes, the storage of configuration information for each function-level vulnerability is updated via synchronization instructions.

7. The memory vulnerability repair method according to claim 5, characterized in that: If the address range of a newly registered function-level vulnerability is continuous with the address range of an existing function-level vulnerability, and both the address ranges of the newly registered function-level vulnerability and the address ranges of the existing function-level vulnerability are configured as non-executable, then the newly registered function-level vulnerability and the existing function-level vulnerability will be merged into one entry.

8. A computer device, characterized in that, It includes a processor and a memory, the memory storing a computer program, which, when executed by the processor, implements the steps of the memory vulnerability repair method as described in any one of claims 1 to 7.

9. A readable storage medium having a computer program stored thereon, characterized in that: When a computer program is executed by a processor, it implements the steps of the memory vulnerability repair method as described in any one of claims 1 to 7.

Images