Memory vulnerability repairing method, computer device and readable storage medium

Abstract

The invention 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, if the exception type is exception of a memory protection unit, obtaining information of a fault address recorded by a fault address register; if the exception type is breakpoint exception, inquiring information of a breakpoint address triggering the breakpoint exception; querying address information of the repair function from the vulnerability modification mapping table; obtaining a first vulnerability type of a vulnerability corresponding to the current abnormal condition, if the first vulnerability type is a function-level vulnerability, extracting a function parameter from a push register, and calling a repair function; if the first vulnerability type is an instruction-level vulnerability, analyzing a vulnerability instruction and calling a repair function; and executing the called repair function. The invention further provides a computer device and a readable storage medium for implementing the method. According to the method, bug repair is realized by multiplexing the original memory protection unit and the breakpoint module of the processor.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vulnerability repair of memory, in particular to a vulnerability repair method of memory and a computer device and a computer readable storage medium for implementing the method. BACKGROUND

[0002] Embedded systems and various chips widely use read-only memories (ROMs), which have the advantage of not losing data when power is off. The ROMs are usually used as key carriers for solidifying programs and core data. Once the code stored in the ROM is burned, it cannot be modified, thus ensuring the stability of the system foundation and ensuring that the code of the system cannot be tampered with to affect the operation of the system.

[0003] However, the feature that the code of the ROM cannot be modified can cause fatal defects. If the code stored in the ROM is incorrect, especially if the code of the underlying basic functions is incorrect, since the code of the ROM cannot be corrected, the problematic code needs to be discarded, and the associated code on the path related to the problematic code may also need to be discarded, which can cause the core functions of the system to fail or even the entire system to be paralyzed. For example, if the boot program, hardware initialization, and other underlying functions have vulnerabilities, all upper-level modules that depend on these functions cannot work. The traditional solution needs to avoid risks through hardware redundancy or overall firmware update, but this processing method is costly and has poor flexibility. Therefore, how to dynamically repair the solidified code errors without modifying the physical storage of the ROM has become a core problem that needs to be solved urgently.

[0004] The existing processing methods mainly include the following three kinds: The first is a static reserved function repair method. A function table and a callback pointer are pre-grouped and planned during the development stage of the ROM. The functions are divided into multiple different groups according to the preset rules, and an independent function table and a number are configured for each group. When repairing the ROM, the corresponding function table is found according to the group number, copied to the specified storage area to generate a new table and update the access address, and finally the function replacement is realized through the pointer redirection of the random memory. However, this method relies on the static preset during the development stage and has poor adaptability to undefined vulnerabilities or dynamic scenarios. In addition, in the case where potential vulnerabilities cannot be predicted, a large number of callback pointers need to be reserved, resulting in a sharp increase in the space occupation of the ROM, a significant reduction in the proportion of effective code, and a serious impact on the storage efficiency of the ROM.

[0005] The second way is to use a dedicated hardware comparison type breakpoint repair, which needs to design independent program counter address comparison circuit and control logic, capture the "repaired program address" stored in the breakpoint interrupt register in the hardware layer, and compare it with the program counter of the central processor in real time. Once the address matches, the interrupt is triggered to prevent the execution of the problematic code, and the repair logic is called through the preset mapping relationship. However, this way needs to deploy additional dedicated comparison hardware, which increases the complexity of chip design and leads to an increase in the production cost of the chip. In addition, the repair process of this way depends on the fixed mapping table, and it is difficult to cope with dynamic scenarios such as address reuse in a multi-task environment, and the problems of hardware redundancy and adaptability are prominent.

[0006] The third way is to use a single architecture memory protection unit interception type repair scheme, which needs to use the data access protection mechanism of the memory protection unit to set the problematic function address as "central processor unreadable area". When the program accesses the problematic function, the memory protection unit interrupt is triggered, and the patch logic is executed by jumping to the interrupt handling program. However, this way is only suitable for ARM architecture and is not compatible with other mainstream architectures. Moreover, the memory protection unit is configured as static locking, which cannot dynamically switch the protection strategy according to the scene, and cannot realize accurate interception combined with the original breakpoint function of the processor. Therefore, there are obvious short boards in the scope of application and repair efficiency. SUMMARY

[0007] The first object of the present application is to provide a memory vulnerability repair method that realizes accurate vulnerability code interception and repair combined with the memory protection unit and the breakpoint function of the processor.

[0008] The second object of the present application is to provide a computer device that realizes the memory vulnerability repair method.

[0009] The third object of the present application is to provide a readable storage medium that realizes the memory vulnerability repair method.

[0010] To achieve the first object of the present application, the memory vulnerability repair method provided by the present application includes obtaining the exception type corresponding to the hardware exception trigger information. If the exception type is a memory protection unit exception, the information of the fault address recorded by the fault address register is obtained. If the exception type is a breakpoint exception, the information of the breakpoint address triggering the breakpoint exception is queried. According to the fault address or the breakpoint address, the address information of the repair function is queried from the vulnerability modification mapping table. The first vulnerability type of the current exception situation is obtained. If the first vulnerability type is a function-level vulnerability, the function parameters are extracted from the stack register, and the repair function is called. If the first vulnerability type is an instruction-level vulnerability, the vulnerability instruction is analyzed and the repair function is called. The called repair function is executed.

[0011] As can be seen from the above scheme, the application uses the memory protection unit and the breakpoint module of the original processor to realize the vulnerability interception and repair, identifies the first vulnerability type of the vulnerability function, repairs the vulnerability through the memory protection unit for the function-level vulnerability, and repairs the vulnerability through the breakpoint module for the instruction-level vulnerability. Since the memory protection unit and the breakpoint module are both original modules of the processor, the application uses the memory protection unit and the breakpoint module of the original processor to repair the vulnerability without the need to increase additional modules or use complex algorithm processing, thereby reducing the cost of vulnerability interception and repair.

[0012] In addition, the application distinguishes between function-level vulnerabilities and instruction-level vulnerabilities, repairs the two types of vulnerabilities in different ways, respectively realizes the interception of the two different types of vulnerabilities through the configuration of the memory protection unit and the breakpoint address matching of the breakpoint module, is more accurate in vulnerability interception, and satisfies the real-time performance of instruction-level vulnerability repair.

[0013] A preferred scheme is to obtain new vulnerability registration information, obtain the second vulnerability type of the newly registered vulnerability, and if the newly registered vulnerability is a function-level vulnerability, configure the address range of the vulnerability function of the function-level vulnerability as non-executable through the memory protection unit; if the newly registered vulnerability is an instruction-level vulnerability, write the address of the vulnerability instruction of the instruction-level vulnerability into the breakpoint register through the breakpoint module.

[0014] As can be seen, when registering a new vulnerability, different types of vulnerabilities are distinguished, the memory protection unit is used to configure the vulnerability function for function-level vulnerabilities, and the breakpoint module is used to configure the vulnerability function for instruction-level vulnerabilities. This way can ensure that the two different types of vulnerabilities can be accurately intercepted in the future and can satisfy the real-time performance of repair.

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

[0016] As can be seen, for the two different architecture processors of ARM and RISC-V, corresponding processing methods are used respectively, which can realize the configuration of the address range of the vulnerability function of the function-level vulnerability without increasing additional modules.

[0017] 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.

[0018] 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.

[0019] 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.

[0020] 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.

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] Further, if the address range of the newly registered function-level vulnerability is continuous with the address range of the existing function-level vulnerability, and the address range of the newly registered function-level vulnerability and the address range of the existing function-level vulnerability are both configured as non-executable, the newly registered function-level vulnerability and the existing function-level vulnerability are merged into one entry.

[0026] Therefore, by merging the newly registered vulnerability and the existing vulnerability that meet the requirements, the number of entries recorded by the memory protection unit can be reduced, so that the memory protection unit can configure more vulnerability functions and fully utilize the resources of the memory protection unit.

[0027] To achieve the second purpose, the computer device provided by the present application includes a processor and a memory, and the memory stores a computer program, which implements each step of the vulnerability repair method of the memory when executed by the processor.

[0028] To achieve the third purpose, the readable storage medium provided by the present application stores a computer program, which implements each step of the vulnerability repair method of the memory when executed by the processor. BRIEF DESCRIPTION OF DRAWINGS

[0029] Figure 1 is a flowchart of an embodiment of the vulnerability repair method of the memory of the present application.

[0030] Figure 2 is the first part of the flowchart of registering a new vulnerability in an embodiment of the vulnerability repair method of the memory of the present application.

[0031] Figure 3 is the second part of the flowchart of registering a new vulnerability in an embodiment of the vulnerability repair method of the memory of the present application.

[0032] The present application will be further described below in conjunction with the drawings and embodiments. DETAILED DESCRIPTION

[0033] The vulnerability repair method of the memory of the present application is mainly used for repairing the vulnerability of the code stored in the read-only memory (ROM), and the interception and repair of the vulnerability function are realized by using the native memory protection unit and breakpoint module of the ARM processor or RISC-V processor, so as to realize low-cost and accurate interception and repair of the vulnerability function. The method of the present application can be implemented on a computer device having a processor and a memory, and the memory is the readable storage medium of the present application, and the computer program is stored on the memory, and each step of the vulnerability repair method of the memory is implemented when the computer program is executed by the processor.

[0034] Embodiment of the vulnerability repair method of the memory: The embodiment can be applied in a chip based on an ARM architecture or a RISC-V architecture processor. Since the ARM architecture or the RISC-V architecture processor is originally integrated with a memory protection unit and a breakpoint module, the embodiment uses the original memory protection unit and the breakpoint module of the processor to intercept and repair the vulnerability, so that the repair of the vulnerability is realized without adding additional devices or modules to the chip.

[0035] In the ARM architecture, the memory protection unit is called MPU (Memory Protection Unit), which can support 2 to 16 protection entries. The address range is configured by the region base address register (MPU_RBAR) and the region attribute register (MPU_RASR) of the memory protection unit, and the XN bit (eXecute Never) of the region attribute register is used to prohibit the execution of instructions, so it can be used to set the non-executable range of the vulnerability function. In the RISC-V architecture, the memory protection unit is called PMP (Physical Memory Protection), which supports 4 to 16 protection entries. The protection range of the memory is defined by the attribute configuration register (pmpcfg0-pmpcfg3) and the address register (pmpaddr0-pmpaddr15). Among them, the execution permission bit (pmpcfg[n].X) can be set to 0 to prohibit the execution of instructions.

[0036] In the ARM architecture, the breakpoint module is called FPB (Flash Patch and Breakpoint Unit), which includes a global control register (FP_CTRL), a remapping base address register (FP_REMAP), and a comparator configuration register (FP_COMPn), where n is 0 to 5, that is, there are 5 comparator configuration registers. In the RISC-V architecture, the breakpoint module is called Trigger Module. The trigger module of the processor of the RISC-V architecture realizes the interception of the instruction-level vulnerability through the register selection instruction (tselect), the control configuration data (tdata1), and the breakpoint address (tdata2).

[0037] Referring to Figure 1 , the embodiment first performs step S11 to obtain hardware exception triggering information. For example, when the program executed by the processor runs to the vulnerability code, the hardware automatically triggers an exception, that is, the hardware exception triggering information is formed, and the exception service function is entered.

[0038] Then, step S12 is performed to determine whether the hardware exception trigger information triggering the current exception is a memory protection unit exception or a breakpoint exception, that is, the type of exception corresponding to the hardware exception trigger information needs to be obtained. If the type of exception is a memory protection unit exception, step S13 is performed to obtain the information of the fault address recorded by the fault address register. If the processor is of the ARM architecture, the processor memory management fault address register (MMFAR) obtains the address of violation, that is, the address of fault, and the fault status register (MMFSR) confirms that the program currently exists an execution permission violation. If the processor is of the RISC-V architecture, the address of fault is obtained through the trap value register (mtval), and the trap cause register (mcause) identifies it as "load / store fault".

[0039] If step S12 confirms that the type of current exception is a breakpoint exception, step S14 is performed. If the processor is of the ARM architecture, the address triggering the breakpoint exception is reversely queried through the comparator configuration register (FP_COMPn), and the breakpoint event is marked by the debug fault status register (HFSR). If the processor is of the RISC-V architecture, the address of breakpoint is read by identifying the data of tdata2, and the current exception is identified as "breakpoint trap" through the trap cause register (mcause).

[0040] Through steps S13 and S14, the fault address triggering the exception or the breakpoint address can be obtained. Then, step S15 is performed to query the address information of the repair function corresponding to the exception from the vulnerability repair mapping table. Since the newly discovered vulnerability needs to be registered when the vulnerability is discovered, and the mapping relationship between the vulnerability function and the repair function needs to be established after the vulnerability is registered, the vulnerability repair mapping table needs to be constructed, which records the mapping relationship between each vulnerability function and the corresponding repair function. Since the vulnerability repair mapping table is constructed in advance, the address information of the repair function can be obtained by querying the vulnerability repair mapping table in step S15. In this way, once the program runs to the address corresponding to the vulnerability function, the vulnerability function will not be executed, but will be jumped to execute the repair function.

[0041] Then, step S16 is performed to determine the first vulnerability type that triggered the exception. Specifically, the first vulnerability type that triggered the exception is obtained, and it is determined whether the current vulnerability is a function-level vulnerability or an instruction-level vulnerability. Different interception configurations are used for function-level vulnerabilities and instruction-level vulnerabilities in this embodiment. Since the interception of function-level vulnerabilities has the characteristics of a large area and low real-time performance, in the interception strategy, the memory protection unit is used to configure the address range of the vulnerability function in the read-only memory as “non-executable”. For example, for a processor of ARM architecture, the region base register (MPU_RBAR) can be set as the start address of the vulnerability function, the region attribute register (MPU_RASR) can be configured as the length of the vulnerability function, and the XN bit can be set as 1, that is, the address corresponding to the vulnerability function is set as non-executable. If the processor is of RISC-V architecture, the address range of the vulnerability function is defined through the address register, the value of the attribute configuration register X is configured as 0, indicating that the code at the address corresponding to the vulnerability function is prohibited from execution, and the boundary address mode is set.

[0042] The interception of instruction-level vulnerabilities has the characteristics of precision and high real-time performance, and the interception strategy is to write the address of the vulnerability instruction into the breakpoint register through the breakpoint module. For example, for a processor of ARM architecture, the address of the vulnerability instruction is set through the comparator configuration register, and the enable bit and the replacement mode are set. Since the instructions processed by the processor of ARM architecture are divided into 16-bit instructions and 32-bit instructions, if the vulnerability function is a low half byte, the replacement mode is to replace the low half byte, if the vulnerability function is a high half byte, the replacement mode is to replace the high half byte, and if the vulnerability function is an entire byte, the replacement mode is to replace the entire byte. For a processor of RISC-V architecture, the breakpoint register index information is obtained, and the address of the vulnerability instruction is written in the field corresponding to the breakpoint address. The enable bit and the trigger parameter are set in the control configuration data.

[0043] Based on the above differences, the repair methods for function-level vulnerabilities and instruction-level vulnerabilities are also different. If the current vulnerability is a function-level vulnerability, step S17 is performed to extract the function parameters from the stack register and call the repair function. If the processor is of ARM architecture, the function parameters are extracted from the values of the automatically stacked R0 to R3 registers, which can comply with the ATPCS calling convention. If the processor is of RISC-V architecture, the parameters are extracted from the stack in the manually stacked parameter register at the exception entry.

[0044] If the current vulnerability is an instruction-level vulnerability, step S18 is performed to analyze the vulnerability instruction and call the repair function. Specifically, for instruction-level vulnerabilities, no parameter passing is required, and the operation code and operand of the vulnerability instruction are directly analyzed, such as 32-bit instruction encoding for ARM architecture or 16 / 32-bit instruction format for RISC-V architecture, and a refined repair function is called, such as instruction replacement, conditional jump correction, etc.

[0045] Finally, step S19 is performed to execute the called repair function. If it is an ARM architecture processor, the value of the program counter saved in the stack is modified to the next execution address of the vulnerability function, the branch instruction with state switching is executed, and the stack frame is popped to restore execution. If it is a RISC-V architecture processor, the safe return address is written into the machine exception program counter (mepc), the machine mode return instruction (MRET) is executed, and the execution flow is restored.

[0046] The embodiment distinguishes between different types of vulnerabilities and adopts different recovery measures accordingly. The hardware resources used are all memory protection units and breakpoint modules that are originally integrated in ARM architecture or RISC-V architecture processors, so that the vulnerability can be intercepted and recovered without the need to add additional hardware resources, reducing the cost of vulnerability recovery.

[0047] Generally, vulnerabilities in read-only memory are discovered manually. Once a vulnerability is discovered, the new vulnerability needs to be registered. The registration process of a new vulnerability is introduced below. Figure 2 and Figure 3 First, step S21 is performed to obtain the registration information of the new vulnerability, such as the address of the code corresponding to the vulnerability determined by the developer after discovering the new vulnerability. Then, step S22 is performed to determine the second vulnerability type of the newly registered vulnerability, i.e., to determine whether the vulnerability is a function-level vulnerability or an instruction-level vulnerability. For function-level vulnerabilities, the memory protection unit is preferred for vulnerability function configuration, and for instruction-level vulnerabilities, the breakpoint module is preferred for vulnerability function configuration.

[0048] If the result of step S22 is false, indicating that the vulnerability is an instruction-level vulnerability, step S23 is performed to write the address of the vulnerability instruction into the breakpoint register. As previously introduced, if it is an ARM architecture processor, step S23 sets the instruction address of the vulnerability function through the comparison register of the breakpoint module and sets the replacement mode of the instruction address of the vulnerability function. If it is a RISC-V architecture processor, the index information of the breakpoint register is obtained, the address of the vulnerability instruction is set as the breakpoint address recorded in the breakpoint register, and the enable bit and trigger parameter are set.

[0049] If the result of step S22 is yes, indicating that the current vulnerability is a function-level vulnerability, step S24 is performed to determine whether the entry resources of the memory protection unit are sufficient. Since the number of protection entries of the memory protection unit is limited, if the number of current function-level vulnerabilities is large, exceeding the number of protection entries of the memory protection unit, vulnerability merging or time division multiplexing is required to configure a part of the vulnerabilities to the scenario buffer. If the result of step S24 is yes, indicating that the number of protection entries of the memory protection unit is greater than or equal to the total number of current function-level vulnerabilities, step S25 is performed to configure the address range of the vulnerability function of the newly registered function-level vulnerability as non-executable by the memory protection unit. As previously described, for a processor of ARM architecture, the region base register of the memory protection unit is set to the start address of the vulnerability function, and the length of the vulnerability function is set, and the address range corresponding to the vulnerability function is set as non-executable in the region attribute register of the memory protection unit. For a processor of RISC-V architecture, the address range of the vulnerability function is set by the address register, and the address range corresponding to the vulnerability function is set as non-executable.

[0050] If the result of step S24 is no, indicating that the number of protection entries of the memory protection unit is less than the total number of current function-level vulnerabilities, step S26 is performed to obtain the merging strategy of multiple vulnerability functions. In this embodiment, whether multiple function-level vulnerabilities can be merged needs to consider the following factors: first, whether the addresses corresponding to the multiple vulnerability functions are consecutive addresses, i.e., whether there is a gap between the addresses corresponding to the multiple vulnerability functions. For example, the address of the first vulnerability function is 0x8000 to 0x8010, and the address of the second vulnerability function is 0x8010 to 0x8020, so the addresses of the two functions are consecutive. Second, whether the permissions corresponding to the multiple vulnerability functions to be merged are consistent. If the permissions corresponding to the multiple vulnerability functions are all configured as “non-executable”, it is considered that the permissions corresponding to the multiple vulnerability functions are consistent. Finally, it is determined whether the alignment constraints of the multiple vulnerability functions meet the requirements. For example, under ARM architecture, the multiple vulnerability functions need to meet the requirement of 32-byte alignment, and under RISC-V architecture, the multiple vulnerability functions need to meet the requirement of natural alignment power mode.

[0051] After obtaining the merging strategy of the plurality of vulnerability functions, it is necessary to judge whether the vulnerability functions meet the merging requirements one by one. Specifically, first, step S27 is executed to judge whether the address of the newly registered vulnerability function is continuous with the address of the existing vulnerability function. If not, step S30 is executed to configure each function-level vulnerability in a scene time division multiplexing manner. If the address of the newly registered vulnerability function is continuous with the address of the existing vulnerability function, step S28 is executed to further judge whether the access permission of the newly registered vulnerability is consistent with the access permission of the existing vulnerability. If not, step S30 is executed. If yes, step S29 is further executed to judge whether the vulnerability function of the newly registered vulnerability meets the alignment constraint requirement. If not, step S30 is executed. If yes, step S31 is executed to generate a merging entry to merge the plurality of vulnerabilities in one protection entry. The protection entry needs to record the addresses of the plurality of vulnerabilities to be merged. Moreover, when the merging entry is generated, the function boundary symbol table generated in the compiling stage is needed to ensure that the merging area does not contain non-vulnerability code, so as to avoid the error interception during the subsequent execution of the code.

[0052] After entering the scene time division multiplexing, step S32 is executed to identify the ID of the current scene. The memory protection unit is configured to configure the protection entry of the active vulnerability function of the current scene, and step S33 is executed to save the configuration information of the vulnerability function of the non-active scene to the scene cache area of the Always-On RAM.

[0053] During the subsequent running, if the current scene changes, scene switching needs to be performed to update the storage of the configuration information of each function-level vulnerability. For example, for the processor of ARM architecture, the data synchronization barrier (Data Synchronization Barrier) and the instruction synchronization barrier (Instruction Synchronization Barrier) are used to realize the switching of each vulnerability-level function. For the processor of RISC-V architecture, the synchronization instruction (FENCE.I) is used to refresh the configuration information of each function-level vulnerability to ensure the effectiveness of the new configuration information.

[0054] After step S33 is executed, step S34 is executed to load the configuration information of the target scene, that is, to load the configuration information of each function-level vulnerability in the current running scene, and then step S35 is executed to update the configuration information stored in each register. Thus, the dynamic resource allocation of the function-level vulnerability is completed.

[0055] It can be seen that according to the number and distribution characteristics of the function-level vulnerabilities, the resources of the memory protection unit and the breakpoint module are dynamically managed, when the number of the function-level vulnerabilities is less than or equal to the number of the protection entries of the memory protection unit, all the function-level vulnerabilities are configured as non-executable by the memory protection unit at one time, and the problem of scene switching does not need to be considered in subsequent running. When the number of the function-level vulnerabilities is greater than the number of the protection entries of the memory protection unit, the function-level vulnerabilities that are not active in the current scene are allocated to the scene cache area according to the current scene flexibly, and the configuration of each function-level vulnerability is flexibly switched according to the switching of the current scene in the subsequent running process.

[0056] If the newly registered function-level vulnerability meets the merging condition with the existing function-level vulnerability, after the merging in step S31 is performed, step S36 is performed to release the redundant entries, that is, the protection entries of the memory protection unit that are originally occupied are released, so as to avoid occupying the protection entries of the memory protection unit. The released protection entries can be used to configure other function-level vulnerabilities, so that the protection entries of the memory protection unit are fully utilized.

[0057] Finally, step S36 is performed to determine the required resources of the newly registered vulnerability according to the previous steps, for example, whether to occupy the protection entries of the memory protection unit or to be allocated to the scene cache area, and the corresponding resources are allocated to the newly registered vulnerability according to the determined hardware resources, so that the newly registered vulnerability is configured on the corresponding resources.

[0058] The memory protection unit and the breakpoint module of the processor in the ARM architecture or the RISC-V architecture are used to repair the vulnerabilities of the read-only memory, without the need to increase additional hardware costs, and the repair of the vulnerability function can be realized at low cost. In addition, when repairing the vulnerabilities, the ARM architecture and the RISC-V architecture are strictly followed, and the hardware resources of the ARM architecture and the RISC-V architecture can be fully utilized.

[0059] The present application distinguishes between different types of vulnerabilities, and the function-level vulnerabilities are preferentially configured by the memory protection unit, and the instruction-level vulnerabilities are preferentially configured by the breakpoint module, so as to realize hierarchical interception of different types of vulnerabilities. Since the real-time requirements of the two types of vulnerabilities for repair are different, and the precision requirements are also different, the hierarchical interception can improve the accuracy of vulnerability interception, and also ensure that the real-time requirements of different types of vulnerabilities are met.

[0060] Finally, for function-level vulnerabilities, in the case of insufficient protection entry quantity of the memory protection unit, through scene time-sharing reuse and boundary-safe entry merging processing mode, various memory hardware resources can be fully utilized, so that the vulnerability interception and repair are more flexible and efficient, and more number of vulnerabilities can be intercepted and repaired under the condition of limited resources.

[0061] Computer device embodiment: The computer device of the embodiment can be various types of computer devices, such as a desktop computer, a notebook computer, a data processing server, etc., and 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 information processing method, and the processor implements each step of the above memory vulnerability repair method when executing the computer program.

[0062] For example, the computer program can be divided into one or more modules, and the one or more modules are stored in the memory and executed by the processor to complete each module of the present application. The one or more modules can be a series of computer program instruction segments capable of completing a specific function, which are used to describe the execution process of the computer program in the terminal device.

[0063] The processor of the present application can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The processor is the control center of the terminal device, and connects each part of the entire terminal device through various interfaces and lines.

[0064] The memory can be used to store computer programs and / or modules, and the processor realizes various functions of the terminal device by running or executing the computer programs and / or modules stored in the memory, and calling data stored in the memory. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, at least one application program required by a function, etc.; and the data storage area can store data created according to the use of the mobile phone, etc. In addition, the memory can include a high-speed random access memory, and can also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0065] Storage medium embodiment: The computer program stored by the computer device, if realized in the form of a software function unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on such understanding, all or part of the processes in the above-mentioned embodiment methods can also be completed by a computer program instructing related hardware, and the computer program can be stored in a computer-readable storage medium. When the processor executes the computer program, each step of the above-mentioned memory vulnerability repair method can be realized.

[0066] The computer program includes computer program code, which can be in the form of source code, object code, executable files or some intermediate forms, etc. The computer-readable medium can include any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content included in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0067] Finally, it should be emphasized that the above is only the preferred embodiment of the present application, and is not used to limit the present application. For those skilled in the art, the present application can have various changes and modifications, and any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. A method for vulnerability remediation of a memory, characterized in that, The method comprises: obtaining an exception type corresponding to the hardware exception trigger information, and if the exception type is a memory protection unit exception, obtaining information of a fault address recorded by a fault address register; if the exception type is a breakpoint exception, obtaining information of a breakpoint address triggering the breakpoint exception; obtaining address information of a repair function from a vulnerability modification mapping table according to the fault address or the breakpoint address; obtaining a first vulnerability type of a vulnerability corresponding to a current exception, if the first vulnerability type is a function-level vulnerability, extracting function parameters from a 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; executing the called repair function.

2. The vulnerability remediation method of memory according to claim 1, wherein, The method further comprises: obtaining a second vulnerability type of new vulnerability registration information, if the second vulnerability type is a function-level vulnerability, configuring an address range of a vulnerability function of the function-level vulnerability as non-executable through a memory protection unit, and if the second vulnerability type is an instruction-level vulnerability, writing an address of a vulnerability instruction of the instruction-level vulnerability into a breakpoint register through a breakpoint module.

3. The vulnerability remediation method of memory according to claim 2, wherein, Further comprising: configuring the address range of the vulnerability function of the function-level vulnerability as non-executable through the memory protection unit comprises: setting a region base register of the memory protection unit as a start address of the vulnerability function, setting a length of the vulnerability function, and setting the address range corresponding to the vulnerability function as non-executable in a region attribute register of the memory protection unit; or setting the address range of the vulnerability function through an address register, and setting the address range corresponding to the vulnerability function as non-executable.

4. The vulnerability repair method of the memory according to claim 2, wherein: writing the address of the vulnerability instruction of the instruction-level vulnerability into the breakpoint register through the breakpoint module comprises: setting an instruction address of the vulnerability function through a comparison register of the breakpoint module, and setting a replacement mode of the instruction address of the vulnerability function; or obtaining index information of the breakpoint register, setting the address of the vulnerability instruction as a breakpoint address recorded by the breakpoint register, and setting an enable bit and a trigger parameter.

5. The vulnerability repair method of the memory according to any one of claims 2 to 4, wherein: if it is confirmed that the newly registered vulnerability is a function-level vulnerability, before configuring the address range of the vulnerability function of the function-level vulnerability as non-executable through the memory protection unit, it is confirmed that a total number of all function-level vulnerabilities does not exceed an upper limit of entries recorded by the memory protection unit.

6. The vulnerability repair method of the memory according to claim 5, wherein: if the total number of all function-level vulnerabilities exceeds the upper limit of entries recorded by the memory protection unit, storing configuration information of active function-level vulnerabilities of a current scenario through the memory protection unit, and storing configuration information of function-level vulnerabilities of an inactive scenario in a scenario cache area of a random access memory.

7. The vulnerability repair method of the memory according to claim 6, wherein: if a scenario currently running changes, updating storage of the configuration information of each function-level vulnerability through a synchronization instruction.

8. The vulnerability repair method of the memory according to claim 6, wherein: If the address range of the newly registered function-level vulnerability is continuous with the address range of the existing function-level vulnerability, and the address range of the newly registered function-level vulnerability and the address range of the existing function-level vulnerability are both configured as non-executable, the newly registered function-level vulnerability and the existing function-level vulnerability are merged into one entry.

9. Computer means, characterized in that The computer program is executed by the processor to implement the steps of the memory vulnerability repair method of any one of claims 1 to 8.

10. A readable storage medium, having stored thereon a computer program, characterized in that: The computer program is executed by the processor to implement the steps of the memory vulnerability repair method of any one of claims 1 to 8.

Images