Software security protection method and device based on memory access control list

Abstract

The application provides a software security protection method and device based on a memory access control list, wherein the method comprises the following steps: obtaining a current memory operation generated by a memory access instruction of a target program running; matching the current memory operation based on a pre-stored memory access control list to obtain a memory operation matching result; and determining whether to execute or block the current memory operation according to the memory operation matching result. The method can realize real-time monitoring of the memory access instruction by filtering the current memory operation through the memory access control list, and the hardware is relatively light, no additional runtime performance overhead is introduced during monitoring, and only some low significant bits need to provide range matching support, so that the hardware overhead is greatly reduced, and different types of vulnerabilities can be alleviated.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software security, and in particular to a software security protection method and device based on a memory access control list. BACKGROUND

[0002] Software vulnerabilities are one of the most significant security threats faced by computer systems. These vulnerabilities include not only the most popular memory corruption vulnerabilities, but also non-memory corruption vulnerabilities such as command injection and logic errors. Whether it is a memory corruption vulnerability or a non-memory corruption vulnerability, these vulnerabilities may lead to information leakage, arbitrary code execution, privilege escalation, or unauthorized access, etc. after being exploited.

[0003] In response to this, researchers have proposed many protection schemes from various aspects to mitigate these vulnerabilities, which are either based on pure software or assisted by hardware.

[0004] Among them, the first type of protection scheme fundamentally eliminates the root cause of a specific type of vulnerability, such as spatial and temporal memory safety schemes for memory corruption vulnerabilities. In order to overcome the design complexity and high overhead of the first type of protection scheme, the second type of protection scheme efficiently detects and blocks specific popular attack types or exploitation means, such as control flow integrity schemes for control flow hijacking attacks. Other protection schemes limit the ability of vulnerabilities by guaranteeing that certain security invariants are not violated, such as process isolation mechanisms and software clipping schemes, etc.

[0005] A small part of the above protection schemes have been widely deployed in real-world systems due to their efficiency and effectiveness. However, these protection schemes only focus on specific attack types caused by memory corruption vulnerabilities, such as stack canaries for stack buffer overflows and Intel CET (Control-flow Enforcement Technology) for control flow hijacking attacks, and cannot mitigate other types of attacks or protect non-memory corruption vulnerabilities.

[0006] Further, most of the schemes described above require source code of the software to be hardened for code instrumentation and code transformation, so they cannot handle binary executable files. Although some schemes can handle binary executable files, static disassembly and accurate binary code rewriting are not easy and are still open problems. At the same time, dynamic binary code rewriting will introduce non-negligible performance overhead.

[0007] Unlike the schemes described above that can only mitigate fixed types of vulnerabilities, monitors are a flexible and programmable scheme that can be used to implement a variety of security policies, usually monitoring processes while they are executing.

[0008] Researchers have proposed many monitor schemes. Software-based monitors usually monopolize a dedicated general-purpose processor core to analyze collected information and make decisions. Some commercial processors also provide related hardware features to accelerate the collection of runtime information, such as Intel PT (Processor Trace) and ARM CoreSight. In addition, many hardware-assisted techniques have been proposed to filter collected information, thereby reducing the amount of collected information that needs to be processed. However, when a general-purpose processor core is monopolized by a monitor, it cannot perform other normal tasks. Therefore, the overhead introduced by such monitors is quite significant in terms of total CPU time and chip area.

[0009] Other monitors are mainly based on hardware, and there are several typical architectural designs.

[0010] The first type of design associates each memory word with a tag as metadata, propagates and computes tags according to a configured policy, and finally makes decisions. Specific examples of this type of design include Harmoni and PUMP. As a memory-tag-based monitor, the storage and management of tags inevitably introduce non-negligible hardware and performance overhead according to the size of the tags. Some schemes in this type of design require modified components that even run through the entire computer architecture, from memory to registers.

[0011] The second type of design integrates reconfigurable structures (i.e., FPGAs, Field-Programmable Gate Arrays) into the system-on-chip, uses programmable logic in the FPGA to analyze collected program runtime behavior information, and finally makes decisions. A typical design in this type of design is FlexCore. Since the clock frequency of the FPGA is much lower than that of a high-performance modern processor core, when the FPGA cannot handle the large amount of collected information, it will block the execution of the processor core, thereby introducing a large performance overhead. Reconfiguring the FPGA is also relatively slow, and will also introduce a large performance overhead when switching process contexts.

[0012] The last design integrates the coprocessor into the system on chip, and uses the coprocessor to analyze the collected information and finally make a decision. PHMon is the most advanced design in this category. Similar to the second category, due to the low performance of the coprocessor relative to the general processor core (otherwise, the coprocessor will occupy a larger chip area), this design also introduces a large performance overhead when the coprocessor cannot handle the collected information. Reprogramming the coprocessor during process context switching also introduces a non-negligible performance overhead.

[0013] An important property of a monitor is whether it can support real-time monitoring. Specifically, for example, a monitor that collects and analyzes program execution traces or commit logs usually does not support real-time monitoring. This is because program execution traces and commit logs are only generated by the processor core after the execution of the instruction of interest is completed. In this case, malicious side effects generated by the executed instructions can have occurred before the monitor detects any abnormal behavior and generates an exception to terminate the process. For example, an I / O request to some critical device can have been issued, or a network packet carrying some sensitive information can have been sent. In other words, the exception generated by the monitor is asynchronous, rather than real-time.

[0014] In summary, how to solve the problem that the monitor scheme in the prior art software security protection method has a high hardware and / or performance overhead and does not support real-time monitoring is an important topic in the computer field that needs to be solved urgently. SUMMARY

[0015] The present application provides a software security protection method and device based on a memory access control list, which overcomes the defects of the prior art software security protection method, that is, the monitor scheme has a high hardware and / or performance overhead and does not support real-time monitoring. The present application does not introduce any runtime performance overhead during monitoring, can greatly reduce hardware overhead, and can also alleviate different types of vulnerabilities.

[0016] In one aspect, the present application provides a software security protection method based on a memory access control list, comprising: obtaining a current memory operation generated by a target program runtime memory access instruction; matching the current memory operation based on a pre-stored memory access control list to obtain a memory operation matching result; and determining whether to execute the current memory operation or prevent the current memory operation according to the memory operation matching result.

[0017] Further, the current memory operation includes a plurality of fields, and the plurality of fields at least include an instruction address of issuing the memory operation, a memory operation type, a memory address pointed by the memory operation, and memory content accessed by the memory operation; correspondingly, the memory access control list includes a plurality of memory access rules, and each memory access rule includes expected values of the plurality of fields, a mask for matching, and an action for execution, and the action is to allow execution of the memory operation or to prevent execution of the memory operation.

[0018] Further, the current memory operation includes a plurality of fields, and the plurality of fields at least include an instruction address of issuing the memory operation, a memory operation type, a memory address pointed by the memory operation, and memory content accessed by the memory operation; correspondingly, the memory access control list includes a plurality of memory access rules, and each memory access rule includes expected values of the plurality of fields, a mask for matching, and an action for execution, and the action is to allow execution of the memory operation or to prevent execution of the memory operation.

[0019] Further, the current memory operation includes a plurality of fields, and the plurality of fields at least include an instruction address of issuing the memory operation, a memory operation type, a memory address pointed by the memory operation, and memory content accessed by the memory operation; correspondingly, the memory access control list includes a plurality of memory access rules, and each memory access rule includes expected values of the plurality of fields, a mask for matching, and an action for execution, and the action is to allow execution of the memory operation or to prevent execution of the memory operation.

[0020] Further, for each thread of the process, a global state register is maintained; correspondingly, the current memory operation includes a plurality of fields, and the plurality of fields at least include an instruction address of issuing the memory operation, a memory operation type, a memory address pointed by the memory operation, memory content accessed by the memory operation, and a current state of the state register; the memory access control list includes a plurality of memory access rules, and each memory access rule includes expected values of the plurality of fields, a mask for matching, and an action for execution, and the action is to allow execution of the memory operation or to prevent execution of the memory operation.

[0021] Further, the memory access instruction includes a memory access instruction in a RISC-V instruction set.

[0022] In a second aspect, the present application provides a software security protection device based on a memory access control list, comprising: a current memory operation acquisition module, configured to acquire a current memory operation generated by a memory access instruction during runtime of a target program; a current memory operation matching module, configured to match the current memory operation based on a pre-stored memory access control list to obtain a memory operation matching result; and a current memory operation execution module, configured to determine whether to execute or block the current memory operation according to the memory operation matching result.

[0023] In a third aspect, the present application further provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the software security protection method based on a memory access control list according to any one of the above aspects.

[0024] In a fourth aspect, the present application further provides a non-transitory computer readable storage medium, having a computer program stored thereon, wherein the computer program is executable by a processor to implement the software security protection method based on a memory access control list according to any one of the above aspects.

[0025] The present application further provides a computer program product, comprising a computer program, wherein the computer program is executable by a processor to implement the software security protection method based on a memory access control list according to any one of the above aspects.

[0026] The software security protection method based on a memory access control list provided by the present application acquires a current memory operation generated by a memory access instruction during runtime of a target program, matches the current memory operation based on a pre-stored memory access control list to obtain a memory operation matching result, and then determines whether to execute or block the current memory operation according to the memory operation matching result. This method monitors the memory access instruction in real time by filtering the current memory operation through the memory access control list, and is relatively lightweight in hardware, does not introduce any runtime performance overhead during monitoring, and only needs to provide range matching support for some low significant bits, thereby greatly reducing hardware overhead and relieving different types of vulnerabilities. BRIEF DESCRIPTION OF DRAWINGS

[0027] In order to more clearly illustrate the technical solutions in the present application or the prior art, the following will briefly introduce the drawings needed in the embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0028] Figure 1is a flowchart of a software security protection method based on a memory access control list provided by an embodiment of the present application.

[0029] Figure 2 is a framework diagram of a software security protection method based on a memory access control list provided by an embodiment of the present application.

[0030] Figure 3 is a whole flowchart of a software security protection method based on a memory access control list provided by an embodiment of the present application.

[0031] Figure 4 is a structure diagram of a software security protection device based on a memory access control list provided by an embodiment of the present application.

[0032] Figure 5 is a physical structure diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0033] In order to make the objectives, technical solutions and advantages of the present application clearer, the technical solutions in the present application will be described clearly and completely below with reference to the drawings in the present application. Obviously, the described embodiments are some embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present application.

[0034] It should be noted that the monitor scheme in the prior art software security protection method technology has a high hardware and / or performance overhead, and does not support real-time monitoring. In order to solve this problem, the present application proposes a new monitor scheme, i.e. a software security protection method based on a memory access control list.

[0035] Before describing the software security protection method based on a memory access control list provided by the present application, the following briefly explains the reason why the memory access instruction is taken as a real-time monitoring target.

[0036] Specifically, the present application first investigates different types of instructions in the instruction set architecture. Specifically, the present application mainly focuses on the RISC-V instruction set. Since the RISC-V instruction set is representative, the present application can be easily extended to other instruction set architectures. Among them, the security check of system call and breakpoint is carefully completed by the operating system kernel. At the same time, user-mode applications are not allowed to perform privileged operations. Therefore, the present application only needs to investigate the remaining instruction types.

[0037] In the sense of side effects, ALU (Arithmetic Logic Unit) operations only perform computations, while branches, direct jumps, and direct calls only transfer control flow to a pre-defined fixed location. Therefore, these instructions have almost no side effects and are safe.

[0038] Since indirect jumps and calls can transfer control flow to a runtime-determined location, they are common targets of control-flow hijacking attacks. However, the targets of these control-flow transfers are usually read from memory by a preceding memory-access instruction in the program. Memory-access instructions can read or modify the content of memory, and thus can have persistent side effects throughout the lifetime of a process. In underlying software, such as operating system kernels or user-mode device drivers, these instructions can even access peripherals and have an impact on the physical world. Moreover, if the result of an ALU operation is used later, the program will eventually use a memory-access instruction to write this result into memory. Therefore, memory-access instructions are crucial targets for effective monitoring.

[0039] In the sense of performance, since ALU operations, branches, jumps, and calls are executed very fast in high-performance processor cores, usually requiring only a delay of 0-1 clock cycles, a monitor cannot make a decision about these instructions and their operands in such a short time. Therefore, these instruction classes are not suitable for real-time monitoring. In contrast, even with TLBs and caches to speed up, memory-access instructions usually take more clock cycles to complete, providing sufficient time for a monitor scheme to analyze these instructions and make a decision while they are executing but before their side effects occur. Therefore, memory-access instructions are convenient targets for efficient and real-time monitoring.

[0040] In summary, for an effective, efficient, and real-time monitor scheme, memory-access instructions are crucial and convenient targets. The monitor scheme provided by the present application takes memory-access instructions as monitoring targets.

[0041] A software security protection method based on a memory access control list, Figure 1 A flowchart of the software security protection method based on a memory access control list provided by the embodiment of the present application is shown.

[0042] As Figure 1As shown, the method comprises steps S110-S130, which will be described in detail below.

[0043] S110, obtaining a current memory operation generated by a memory access instruction of a target program.

[0044] It can be understood that when the target program is executed by a processor core, each memory access instruction in the target program will generate a memory operation, i.e., the current memory operation.

[0045] The target program includes any program currently running.

[0046] The memory access instruction includes but is not limited to a memory read instruction, a memory write instruction, a swap instruction, a conditional store instruction, and an atomic operation instruction.

[0047] The memory read instruction is used to read data from the memory and copy it to a register or other storage unit, the memory write instruction is used to write data in the register or other storage unit to a certain address in the memory, the swap instruction is used to directly exchange data between the memory location and the register without having to be loaded into the register first and then stored back, the conditional store instruction is used to store data into the memory only when a certain condition is met, and the atomic operation instruction is used to ensure that the access to the shared resource is mutually exclusive in a multi-threaded environment.

[0048] The current memory operation includes a plurality of fields, and the plurality of fields at least include an instruction address of the memory operation, a memory operation type, a memory address pointed by the memory operation, and memory content accessed by the memory operation. The memory operation type includes but is not limited to a memory read and a memory write.

[0049] It should be noted that the instruction address and the memory address in the current memory operation are both virtual addresses.

[0050] On the basis of obtaining the current memory operation generated by the memory access instruction of the target program in step S110, further, step S120 is executed.

[0051] S120, based on a pre-stored memory access control list, matching the current memory operation to obtain a memory operation matching result.

[0052] It can be understood that after each memory operation generated by the memory access instruction in the target program, in a normal case, these memory operations will go to the first level and possibly lower level data TLB for address translation and permission check, and then go to the first level and possibly lower level data cache to access the content in the memory.

[0053] Unlike the usual approach, this embodiment makes some improvements to the process. Specifically, while these memory operations are going to the first-level and possibly lower-level data TLB for address translation and permission checks, a pre-stored memory access control list is used to check / filter each memory operation going to the TLB and cache.

[0054] In detail, taking memory operations as input, a pre-stored memory access control list is matched to determine which memory operations can access the memory they need and which memory operations cannot access the memory they need.

[0055] Specifically, in this step, the current memory operation is taken as input, and the memory access rules in the pre-stored memory access control list are used for matching to obtain the memory operation matching result.

[0056] The memory access control list stores several memory access rules. These rules include the expected values ​​of the fields covered by the current memory operation and a mask used for matching. These values ​​and the mask determine the set of allowed values ​​for a match. Furthermore, each memory access rule includes an action to be taken, which can either allow or block the current memory operation.

[0057] There are two scenarios for the memory operation matching result: matching a rule or not matching a rule. This embodiment has different processing methods for these two different scenarios, which can be found in step S130.

[0058] S130, based on the memory operation matching result, determine whether to execute the current memory operation or block the current memory operation.

[0059] Specifically, if the memory operation matching result matches the rule, the current memory operation can be executed directly according to the action contained in the matched memory access rule, that is, the current memory operation can be allowed or blocked.

[0060] If the memory operation matching result does not match a rule, the current memory operation is executed according to the default action, that is, the current memory operation is allowed or blocked. For example, in a specific embodiment, the pre-configured default action is "allow the current memory operation".

[0061] Specifically, when the current memory operation is blocked by the memory access control list, the processor core will generate / return an exception to terminate the current process, thereby blocking the ongoing attack.

[0062] In this embodiment, the current memory operations generated by memory access instructions during the target program's runtime are obtained, and the current memory operations are matched against a pre-stored memory access control list to obtain the memory operation matching result. Then, based on the memory operation matching result, it is determined whether to execute or block the current memory operation. This method monitors memory access instructions in real time by filtering current memory operations using a memory access control list. It is lightweight in hardware implementation, does not introduce any additional runtime performance overhead during monitoring, and only requires range matching support for certain least significant bits, greatly reducing hardware overhead and mitigating different types of vulnerabilities.

[0063] Based on the above embodiments, the process of checking / filtering / matching the current memory operation using the memory access control list will be described in detail below.

[0064] Based on a pre-stored memory access control list, the current memory operation is matched to obtain the memory operation matching result, including: matching several fields contained in the current memory operation with several memory access rules in the memory access control list using values ​​and masks to obtain the memory operation matching result; wherein, the memory operation matching result is either a match or no match.

[0065] It is easy to understand that the current memory operation includes several fields, including but not limited to the address of the instruction that issued the memory operation, the type of memory operation, the memory address that the memory operation points to, and the memory content accessed by the memory operation.

[0066] Correspondingly, the memory access control list includes the concepts of subject, object, and operation performed by the subject on the object. In this embodiment, the subject is a memory operation or an instruction that generates a memory operation, the object is the memory location being accessed and its contents, and the operation is a memory read or memory write operation.

[0067] In other words, the memory access control list stores information corresponding to the various fields involved in the current memory operation. Specifically, the memory access control list includes several memory access rules, each of which includes the expected values ​​for several fields, a mask for matching, and an action to be performed, which either allows or blocks the memory operation.

[0068] It is worth mentioning that, since this embodiment filters memory access control lists before the current memory operation goes to the TLB, the physical address is not yet ready. Therefore, this embodiment chooses to use virtual addresses to represent memory access instructions and memory locations to achieve good compatibility and performance.

[0069] It should also be noted that some memory access rules in the memory access control list can be written and stored in advance before the program starts running, or they can be modified and adjusted during program execution; no specific restrictions are made here.

[0070] After pre-storing the memory access control list, this embodiment monitors memory access instructions in real time. Specifically, it first acquires the current memory operation, then inputs it into the memory access control list. The current memory operation is matched against several memory access rules in the list using a value and mask approach. Several fields contained in the current memory operation are matched against several memory access rules in the list. If a match is found, the memory operation is considered a match; otherwise, it is considered a mismatch.

[0071] Matching is performed using a value and a mask. The value represents the actual data to be checked, which can be any information that can be represented in binary, such as instruction addresses, memory operation types, memory addresses, or memory contents. The mask indicates which bits are important and which can be ignored. The mask typically consists of a series of "0"s and "1"s, where "1" indicates that the corresponding bit needs to be checked and "0" indicates that the corresponding bit can be ignored. Both the value and the mask are predefined and stored in a memory access control list.

[0072] In a specific embodiment, if the value corresponding to a certain memory access rule is 0011 and the mask is 1010, then as long as the current memory operation corresponds to any one of the binary representations "0010", "0011", "0110", and "0111", it can be considered a match; otherwise, it is not a match.

[0073] It should also be noted that this embodiment uses the memory content to be accessed by the current memory operation as the matching field, which can greatly improve the flexibility of the solution implementation, that is, perform different actions on the same memory access instruction when the actual data is different.

[0074] It is worth mentioning that, since the code or data with related functions are usually located in corresponding contiguous memory regions, this invention also provides range matching support for instruction addresses and memory addresses, which is convenient for users and can reduce the number of rules. However, although mask matching is easy to implement in hardware using pure logic or TCAM, range matching is slightly more expensive. Fortunately, since the code or data with related functions are usually located in the same function or object file... In memory objects, which are typically relatively small, this invention only needs to provide range matching support for certain least significant bits, which will greatly reduce hardware overhead.

[0075] In this embodiment, the memory operation is matched with several rules in the memory access control list using values ​​and masks to obtain the memory operation matching result. Based on this result, it is determined whether to execute or block the current memory operation. This method monitors memory access instructions in real time by filtering current memory operations using the memory access control list. It is lightweight in hardware implementation, introduces no additional runtime performance overhead during monitoring, and only requires range matching support for certain least significant bits, greatly reducing hardware overhead and mitigating various types of vulnerabilities.

[0076] Based on the above embodiments, the process of determining whether to execute the current memory operation or prevent the current memory operation based on the memory operation matching result will be described in detail below.

[0077] Based on the memory operation matching result, determine whether to execute or block the current memory operation, including: if the memory operation matching result matches a rule, determine whether to execute or block the current memory operation according to the action contained in the matched target rule; if the memory operation matching result does not match a rule, execute according to the default action; wherein, the default action is to allow the execution of the current memory operation or block the current memory operation and return an exception to terminate the current process.

[0078] It's easy to understand that if the current memory operation matches a rule in the memory access control list, the current memory operation is executed directly according to the matching memory access rule (target rule). That is, if the target rule allows the current memory operation, then the current memory operation is allowed to proceed normally; if the target rule blocks the current memory operation, then an exception is generated to terminate the current process, thereby blocking the ongoing attack.

[0079] If the current memory operation fails to match a rule in the memory access control list, the next action is determined based on the default action. If the default action is to allow the current memory operation, it will be allowed to execute even if it does not match any rules. This strategy is suitable for relatively lenient security environments or scenarios where most operations are trusted by default. If the default action is to block the current memory operation, it will be blocked if it does not match a rule, potentially triggering an exception and possibly terminating the current process. This strategy is more stringent and suitable for environments requiring high security.

[0080] For example, in one specific embodiment, the pre-stored memory access control list includes the following memory access rules: Rules 1 to 3, the default action is to block the current memory operation and return an exception.

[0081] Rule 1: Instruction address range 0x100000~0x200000, memory address range 0x100000000~0x200000000, memory read or memory write operations are allowed.

[0082] Rule 2: Instruction address range 0x200000~0x300000, memory address range 0x200000000~0x300000000, memory read or memory write operations are allowed.

[0083] Rule 3: Memory address range 0xE00000000~0xF00000000, memory read or write operations are allowed.

[0084] In one scenario, the current memory operation is as follows: the instruction address is 0x100480, and the data at address 0x100000080 is read. The current memory operation is matched with memory access rules 1 to 3 using a value and mask method. If memory access rule 1 is matched, the current memory operation is allowed to be executed, and the data at address 0x100000080 is read.

[0085] In another scenario, the current memory operation is: instruction address 0x2005C0, write data at address 0x100000090. The current memory operation is matched with memory access rules 1 to 3 using a value and mask method. If no rule is matched, the current memory operation is blocked, the write operation is blocked, an exception is returned, and the current process is terminated.

[0086] In this embodiment, if the memory operation matching result matches a rule, the current memory operation is determined to be executed or blocked according to the action contained in the matched target rule. If the memory operation matching result does not match a rule, a default action is executed. The default action is to allow the execution of the current memory operation or block the current memory operation and return an exception to terminate the current process. This method monitors memory access instructions in real time by filtering the current memory operation through a memory access control list. It is lightweight in hardware implementation, does not introduce any additional runtime performance overhead during monitoring, and only needs to provide range matching support for certain low-significant bits, greatly reducing hardware overhead and mitigating different types of vulnerabilities.

[0087] Based on the above embodiments, the following will further describe in detail the process of stateful rule matching.

[0088] It is easy to understand that this embodiment also uses memory access control lists to filter unsafe current memory operations, but by performing rule matching in a stateful manner, better filtering results can be achieved, which can further improve software security.

[0089] To achieve this, existing memory tag-based monitors associate each memory word with a tag as metadata and maintain the tag as actions are performed. However, the storage and management of tags inevitably introduces significant hardware and performance overhead, and may require modifications to components throughout the entire computer architecture.

[0090] In contrast, this embodiment maintains a global status register for each thread's memory access rules for the access control list. Specifically, this embodiment incorporates the current state of the status register into the memory access rule matching process, and updates the status register according to the memory access rules when executing actions.

[0091] Unlike incrementing a status register by a specific number or transitioning it to a specific state, in this embodiment, updating the status register simultaneously clears and sets certain bits. Combined with the mask used for memory access rule matching, this feature makes each bit in the status register independent of the others. In other words, each memory access rule can independently use a portion of the status bits. Therefore, as long as memory access rules from different security policies use different portions of the status bits, they can be easily stored together in the access control list of this invention.

[0092] Furthermore, if two update operations in the status register modify different status bits, it is safe to swap these two update operations. This simplifies the implementation of processor cores, especially high-performance out-of-order execution processor cores. Ultimately, this status register enables this embodiment to match memory operation sequences, thereby allowing this embodiment to track the internal state and context of the monitored thread, such as the function call stack, and thus making the filtering process more accurate, expressive, and stateful.

[0093] The current state of the status register is added to the memory access rule matching process. Thus, the current memory operation includes several fields, which include at least the address of the instruction that issued the memory operation, the type of memory operation, the memory address pointed to by the memory operation, the memory content accessed by the memory operation, and the current state of the status register.

[0094] Accordingly, the memory access control list includes several memory access rules. Each memory access rule includes several fields with expected values, a mask for matching, and an action to be performed, which is to allow or block memory operations.

[0095] In this embodiment, by incorporating the current state of the status register into the memory access rule matching process, the internal state and context of the monitored thread can be tracked, thereby making the filtering process more accurate, expressive, and stateful, and further improving software security.

[0096] In some embodiments, Figure 2 This diagram illustrates the framework of the software security protection method based on memory access control lists provided in an embodiment of the present invention.

[0097] like Figure 2 As shown, when a target program is executed by a processor core, each memory access instruction in the target program will generate a memory operation. Typically, these memory operations will proceed to the first-level and possibly lower-level data TLBs for address translation and permission checks, and then to the first-level and possibly lower-level data caches to access the contents of memory.

[0098] The present invention extends this process slightly by using a memory access control list (MAR) to examine each memory operation heading to the TLB and cache. The MAR includes a series of memory access rules that take the current state of the status register and the operands of the memory operation as input, determining which memory operations can access the memory they need and which cannot. When a memory operation is blocked by the MAR, the processor core generates an exception to terminate the corresponding process, thereby blocking an ongoing attack.

[0099] In some embodiments, Figure 3 This diagram illustrates the overall process of the software security protection method based on memory access control lists provided in this embodiment of the invention.

[0100] like Figure 3 As shown, the processor core is first slightly modified to add the matching and checking logic of this invention, such as TCAM, next to the existing TLB and PTW. The inputs to this logic are the current state of the status register and the current memory operation; the output is whether the memory operation is allowed to access the required memory, and a status update signal fed back to the status register. Then, if the memory page permission check passes and this invention allows the memory operation, the memory operation will be executed in the normal manner. Otherwise, the processor core will generate an exception to notify the operating system kernel.

[0101] Secondly, this invention modifies the operating system kernel to add support for the invention, thereby providing an API for setting rules for user-mode applications, maintaining rules for processes, and handling exceptions generated by hardware supporting the invention. Finally, this invention provides users with a utility program that allows them to configure rules for applications requiring protection using the APIs provided by the operating system kernel.

[0102] Specifically, each memory access rule in the memory access control list can be represented by a string, and the utility can parse these rule strings. In each rule, all fields used for matching—operation type, instruction address, accessed memory address, data being written, and the current value of the status register—are optional and masked. If the user omits a field, the utility treats its mask as all zeros, causing that field to match any value. In particular, the instruction address and accessed memory address support range matching for a subset of the least significant bits, the specific number of bits depending on the implementation.

[0103] In some other embodiments, minor modifications to the processor core are required to add logic to the present invention, modifications to the operating system kernel are needed to add support for the present invention, and a utility program needs to be developed for the user. Specifically, this embodiment implements the prototype system of the present invention on an FPGA development board based on the open-source RISC-V BOOM processor core and Linux kernel.

[0104] In one specific embodiment, a detailed description is provided for TCAM simulation on an FPGA.

[0105] Considering that hardware access control lists are typically implemented using TCAM, this embodiment also uses TCAM to implement the matching and checking logic of this invention in the processor core. However, the FPGA used in this embodiment does not have native TCAM primitives. Therefore, this embodiment chooses to use shift registers to simulate TCAM on the FPGA. This method is a common approach. This embodiment discovers that two SRL16E primitives, namely two 16-bit shift registers, can be placed in the same LUTRAM (Look-Up Table Random Access Memory) primitive, thereby efficiently simulating a 4-bit wide × 2-entry deep TCAM.

[0106] Specifically, an SRL16E can be shifted in 16 bits, one bit per clock cycle, and has a 4-bit wide address input from which the user can read any bit. Therefore, for any 4-bit wide TCAM entry, this embodiment uses the entry's value and mask to pre-calculate the matching result for each 4-bit input (there are 16 possibilities), and stores the calculated result in an SRL16E. Then, the SRL16E can output whether an input matches the TCAM entry for a given input. This embodiment then cascades multiple SRL16Es to form a wider and deeper TCAM. When an input matches multiple entries, this embodiment uses a priority encoder to select the entry with the highest priority, i.e., the entry with the lowest address.

[0107] This embodiment also implements range matching for the SRL16E-based TCAM described above to support the rules of this invention. In this implementation, each 4-bit wide range matching entry has a lower bound and an upper bound, requiring 4 SRL16Es. For the lower bound, one SRL16E is used to store whether the input is greater than or equal to the lower bound, i.e., whether it is within the boundary. Simultaneously, another SRL16E is used to store whether the input is equal to the lower bound. The first SRL16E typically outputs the final matching result when possible. However, since the matching result is uncertain when only the most significant bit of the input is equal to the lower bound, this embodiment requires a second SRL16E during cascading. In this case, this embodiment needs to compare the least significant bit of the input and the lower bound. Matching the upper bound is similar.

[0108] Finally, in this embodiment, a conventional memory is connected to the aforementioned TCAM to store the actions of the rules of this invention.

[0109] In another specific embodiment, modifications to the processor core are described in detail.

[0110] This embodiment modifies the processor core to integrate a TCAM, adds the matching and checking logic of the present invention, introduces a status register and its update logic, and provides an interface to the software through the CSR register to manage the rules of the present invention.

[0111] Specifically, the processor core used in this embodiment is based on the RISC-V BOOM core, supporting a 64-bit RISC-V instruction set architecture with Sv39 virtual memory (i.e., 39-bit virtual addresses). Note that in a rule, the operation type, instruction address (whose least significant bit is fixed at 0), accessed memory address, written data content, and the current value of the status register occupy 1, 38, 39, 64, and 16 bits respectively. This embodiment first instantiates a 158-bit wide TCAM, where the instruction address and the least significant 16 bits of the accessed memory address, totaling 32 bits, support range matching. Subsequently, this embodiment integrates this TCAM into the processor core.

[0112] Secondly, this embodiment uses input micro-operations and memory write queue entries from the LSU (Load / Store Unit, memory access unit, in the lsu.scala file) in the processor core to form the input for TCAM matching. A memory read operation will generate a memory read micro-operation, and the information in the memory read micro-operation will be used as the input to TCAM. However, a memory write operation will generate two micro-operations, one for calculating the address and the other for calculating the data to be written. If the calculation of one micro-operation is completed before the other, the processor core will save its result to the memory write queue, and then perform matching in TCAM when the address and data are ready.

[0113] Then, TCAM outputs the action and status update information for the matched rules. If no matching rule exists in TCAM, this invention will allow the memory operation by default. If the matched rule prevents the memory operation, this invention will generate an access fault exception and cancel the operation. The processor core will record this exception in the ROB (Re-Order Buffer) and generate it during the corresponding instruction commit. If the matched rule allows the memory operation, this invention will store the status update information in the memory read queue or memory write queue.

[0114] Finally, this embodiment adds a status register to the processor core and updates the status register based on the information in the memory read queue or memory write queue when the corresponding instruction is submitted.

[0115] It is worth noting that this embodiment does not support any form of renaming of the status register to reduce additional hardware and performance overhead. In this embodiment, although delaying the status update until instruction submission may cause the invention to use outdated status values ​​when matching rules, this embodiment assumes that in practice, the distance between the memory operations of interest will be far enough that they will not be affected by this characteristic.

[0116] To provide an interface for software to manage the rules of this invention, this embodiment introduces a series of CSR registers in the processor core and connects them to the TCAM. These CSR registers can only be accessed by S-mode code (i.e., the operating system kernel). User-mode applications should access them through the operating system kernel. Among these CSR registers, there are eight staging registers: aclInsnAddr, aclInsnAddrMask, aclMemAddr, aclMemAddrMask, aclMemData, aclMemDataMask, aclStateAndMask, and aclAction, used to temporarily store the rules that need to be written.

[0117] In addition, aclIndex is used to store the index of the rules that need to be written and acts as a trigger. Once aclIndex is written, TCAM begins its update process and writes the rule to the entry located at the corresponding index (i.e., address). Finally, aclState is directly mapped to the status register for software access.

[0118] To write a rule into the TCAM, the user needs to write to eight temporary registers. Furthermore, during context switching, the operating system kernel needs to write the entire access control list (ACTS) with several rules into the TCAM, requiring even more writes to the temporary registers. However, the existing CSR implementation in the RISC-V BOOM core flushes the entire pipeline before and after each CSR instruction execution, resulting in a significant latency (approximately 20 clock cycles) for a single CSR instruction and making the usage in this embodiment inefficient. Since existing code does not have this access pattern, it is unaffected by this characteristic.

[0119] To optimize the usage of this embodiment, it first detects any instructions writing to the temporary CSR register in the instruction decoding unit and prevents these instructions from flushing the pipeline. Then, in the execution unit, since the instruction may still be in the predictive execution phase, unlike directly modifying the CSR register, this embodiment saves the new value of the CSR register to the ROB. Subsequently, when the corresponding instruction is committed, this embodiment writes the saved value back to the CSR register. Ultimately, instructions writing to the temporary CSR register will be as fast as ALU instructions.

[0120] In another specific embodiment, operating system kernel support is described in detail.

[0121] Modifications are made to the Linux kernel to provide system calls for user space to manage the rules of this invention, maintain rules and status registers for processes, and switch rules and status registers during process context switching. It is worth noting that when this invention blocks a memory operation, the access error exception generated by the processor core can be recognized and handled by the kernel. In this case, the kernel will terminate the process with the exception.

[0122] Specifically, this embodiment modifies the prctl() system call to add several new functional options. These new options enable the caller process and other processes to read and set the rules and priorities of this invention. In particular, for prctl() calls that manipulate rules for other processes, this embodiment follows the permission check of ptrace(), specifically ptrace_may_access(), to verify the legitimacy of the call, thus ensuring that the modifications in this embodiment do not introduce new security issues.

[0123] This embodiment then maintains a linked list for each process (or more specifically, each address space, i.e., each mm_struct structure) to store the rules configured in the access control list. This embodiment ensures that the linked list is kept ordered according to the priority of the rules within it, and that its lifespan is the same as the lifespan of the corresponding address space.

[0124] Each time the `prctl()` call modifies the linked list or the kernel performs a context switch, the kernel writes the rules to the hardware via the CSR register. The index used by the kernel when operating the hardware of this invention is the rule's position in the linked list, not the priority configured via `prctl()`. It is worth noting that although the priority number in the hardware, i.e., the index, may differ from the configured priority, the relative priority relationships between rules will remain consistent.

[0125] Furthermore, this embodiment reserves two highest-priority rules for the kernel in the hardware. Then, this embodiment configures these two rules to allow kernel code to arbitrarily access the entire virtual memory space, thereby preventing user-space users from configuring malicious rules for the kernel and launching denial-of-service attacks.

[0126] Previous research has observed that only a small number of processes possess potential vulnerabilities and therefore require protection. For this invention, this means that only a small number of processes will have non-empty access control lists (ACCAs). Therefore, this embodiment first stores a pointer in the kernel to the memory ACCAs currently configured in the hardware. Whenever the kernel switches the context to a new process with a non-empty ACCAs, this embodiment writes the ACCAs into the hardware and updates the pointer. Then, when the kernel switches the context from the current process to a new process with an empty ACCAs, this embodiment only needs to configure the highest priority rule to allow the new process to access the entire virtual memory space, without clearing the entire hardware ACCAs. Subsequently, when the kernel switches the context back to the previous process with a non-empty ACCAs, this embodiment checks if the ACCAs pointer stored in the kernel matches that process. If it matches, this embodiment only needs to restore the highest priority rule, without rewriting the entire ACCAs into the hardware, because only that highest priority rule was previously overwritten by a process with an empty ACCAs. Otherwise, this indicates that the hardware access control list has been overwritten by another process, and this optimization cannot be performed in this embodiment.

[0127] Furthermore, this embodiment can also utilize certain bits in the status register to store an address space identifier for each rule in the hardware, and use this identifier to identify different rules for different processes, similar to the address space identifier in the TLB. In this way, multiple different processes can simultaneously share the same access control list hardware.

[0128] In other embodiments, user-mode utilities are described in detail.

[0129] This embodiment provides users with a utility program to flexibly configure the rules of this invention for applications. This utility program supports launching a new process to execute a new binary executable file with the rules of this invention loaded, and also supports configuring rules for an existing process.

[0130] Specifically, to configure rules, the utility first parses the input rule file, where each line represents a rule string. Then, the utility configures the highest priority rule with a single `prctl()` call, allowing the corresponding process to access the entire virtual memory space, effectively disabling all subsequent rules. This step is necessary to prevent erroneous actions from incompletely configured rules in the hardware.

[0131] The utility then configures all rules except the highest priority rule. Finally, it configures the highest priority rule to the desired value. Thus, this embodiment allows the rules of the present invention to be configured for new or existing processes without interrupting execution.

[0132] Corresponding to the software security protection method based on memory access control lists described in the above embodiments, the present invention also provides a software security protection device based on memory access control lists, specifically, Figure 4 A schematic diagram of the structure of the software security protection device based on memory access control lists provided in an embodiment of the present invention is shown.

[0133] like Figure 4 As shown, the device includes: a current memory operation acquisition module 410, used to acquire the current memory operation generated by the memory access instruction during the runtime of the target program; a current memory operation matching module 420, used to match the current memory operation based on a pre-stored memory access control list to obtain a memory operation matching result; and a current memory operation execution module 430, used to determine whether to execute the current memory operation or block the current memory operation based on the memory operation matching result.

[0134] In this embodiment, the current memory operation acquisition module 410 acquires the current memory operations generated by the memory access instructions during the target program's runtime. The current memory operation matching module 420 matches the current memory operations based on a pre-stored memory access control list to obtain the memory operation matching result. Then, the current memory operation execution module 430 determines whether to execute or block the current memory operation based on the memory operation matching result. This device monitors memory access instructions in real time by filtering current memory operations using a memory access control list. It is lightweight in hardware implementation, does not introduce any additional runtime performance overhead during monitoring, and only requires range matching support for certain low-significant bits, greatly reducing hardware overhead and mitigating different types of vulnerabilities.

[0135] It should be noted that the software security protection device based on memory access control lists provided in this embodiment can be referred to in correspondence with the software security protection methods based on memory access control lists described in the above embodiments, and will not be repeated here.

[0136] Figure 5 A schematic diagram of the physical structure of an electronic device is shown. (For example...) Figure 5 As shown, the electronic device may include a processor 510, a communications interface 520, a memory 530, and a communication bus 540, wherein the processor 510, communications interface 520, and memory 530 communicate with each other via the communication bus 540. The processor 510 can invoke logical instructions in the memory 530 to execute a software security protection method based on a memory access control list. This method includes: obtaining the current memory operation generated by memory access instructions during the runtime of the target program; matching the current memory operation based on a pre-stored memory access control list to obtain a memory operation matching result; and determining whether to execute or block the current memory operation based on the memory operation matching result.

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

[0138] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the software security protection method based on memory access control lists provided by the above methods. The method includes: obtaining the current memory operation generated by the memory access instructions during the runtime of the target program; matching the current memory operation based on a pre-stored memory access control list to obtain a memory operation matching result; and determining whether to execute the current memory operation or block the current memory operation based on the memory operation matching result.

[0139] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the software security protection method based on a memory access control list provided by the above methods. The method includes: obtaining the current memory operation generated by memory access instructions during the runtime of the target program; matching the current memory operation based on a pre-stored memory access control list to obtain a memory operation matching result; and determining whether to execute the current memory operation or block the current memory operation based on the memory operation matching result.

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

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

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

Claims

1. A software security protection method based on memory access control lists, characterized in that, include: Obtain the current memory operations generated by memory access instructions during the target program's runtime; The current memory operation includes several fields, which at least include the address of the instruction that issued the memory operation, the type of memory operation, the memory address pointed to by the memory operation, and the memory content accessed by the memory operation. While the current memory operation is moving to the first-level and lower-level data TLB for address translation and permission checks, the current memory operation is matched based on a pre-stored memory access control list to obtain a memory operation matching result. The memory access control list includes several memory access rules, and each memory access rule includes the expected values ​​of the several fields, a mask for matching, and an action for execution, which is to allow or block the memory operation. Based on the memory operation matching results, determine whether to execute the current memory operation or block the current memory operation.

2. The software security protection method based on memory access control lists according to claim 1, characterized in that, The pre-stored memory access control list is used to match the current memory operation to obtain a memory operation matching result, including: The fields contained in the current memory operation are matched with several memory access rules in the memory access control list using values ​​and masks to obtain the memory operation matching result. The memory operation matching result is either a match with the rule or a non-match with the rule.

3. The software security protection method based on memory access control lists according to claim 2, characterized in that, The step of determining whether to execute the current memory operation or block the current memory operation based on the memory operation matching result includes: If the memory operation matching result matches a rule, determine whether to execute the current memory operation or block the current memory operation according to the action contained in the matched target rule; If the memory operation matching result is that no rule is matched, the default action will be executed. The default action is to allow the current memory operation or block the current memory operation and return an exception to terminate the current process.

4. The software security protection method based on memory access control lists according to claim 1, characterized in that, For each thread of a process, a global status register is maintained; Accordingly, the current memory operation includes several fields, which at least include the address of the instruction that issued the memory operation, the type of memory operation, the memory address pointed to by the memory operation, the memory content accessed by the memory operation, and the current state of the status register. The memory access control list includes several memory access rules. Each memory access rule includes the expected values ​​of the several fields, a mask for matching, and an action to be performed, which is to allow or block memory operations.

5. The software security protection method based on memory access control lists according to any one of claims 1 to 4, characterized in that, The memory access instructions include memory access instructions from the RISC-V instruction set.

6. A software security protection device based on memory access control lists, characterized in that, include: The current memory operation acquisition module is used to acquire the current memory operations generated by memory access instructions during the runtime of the target program. The current memory operation includes several fields, which at least include the address of the instruction that issued the memory operation, the type of memory operation, the memory address pointed to by the memory operation, and the memory content accessed by the memory operation. The current memory operation matching module is used to match the current memory operation based on a pre-stored memory access control list while the current memory operation is performing address translation and permission checks in the first-level and lower-level data TLBs to obtain a memory operation matching result. The memory access control list includes several memory access rules, and each memory access rule includes the expected values ​​of the several fields, a mask for matching, and an action for execution, wherein the action is to allow the execution of the memory operation or to block the memory operation. The current memory operation execution module is used to determine whether to execute the current memory operation or block the current memory operation based on the memory operation matching result.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the software security protection method based on memory access control lists as described in any one of claims 1 to 5.

8. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the software security protection method based on memory access control lists as described in any one of claims 1 to 5.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the software security protection method based on memory access control lists as described in any one of claims 1 to 5.

Images