Memory access control list-based software security protection method and apparatus

Abstract

The present application provides a memory access control list-based software security protection method and apparatus. The method comprises: acquiring a current memory operation generated by a memory access instruction at a runtime of a target program; based on a pre-stored memory access control list, performing matching on the current memory operation to obtain a memory operation matching result; and, based on the memory operation matching result, determining whether to execute the current memory operation or prevent the current memory operation. According to the method, the memory access instruction is monitored in real time by using the memory access control list for filtering the current memory operation, the hardware implementation is relatively lightweight, no additional overhead of runtime performance is introduced during monitoring, and range matching support needs to be provided only for certain less significant bits, thereby greatly reducing the hardware overhead, and also alleviating different types of vulnerabilities.

Description

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

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese patent application No. 202411440022X, filed on October 15, 2024, entitled "Software Security Protection Method and Apparatus Based on Memory Access Control List", which is incorporated herein by reference in its entirety. Technical Field

[0003] This application relates to the field of software security technology, and in particular to a software security protection method and apparatus based on memory access control lists. Background Technology

[0004] Software vulnerabilities are among the most significant security threats facing computer systems. These vulnerabilities include not only the most prevalent memory corruption vulnerabilities, but also non-memory corruption vulnerabilities such as command injection and logical errors. Whether memory corruption or non-memory corruption vulnerabilities, exploiting them can lead to adverse consequences such as information leakage, arbitrary code execution, privilege escalation, or unauthorized access.

[0005] In response, researchers have proposed numerous protective measures to mitigate these vulnerabilities, some based on pure software and others assisted by hardware.

[0006] The first type of protection scheme fundamentally eliminates the root cause of specific types of vulnerabilities, such as space and time-series memory safety schemes for memory corruption vulnerabilities. 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 methods, such as control flow integrity schemes for control flow hijacking attacks. Other protection schemes limit the vulnerability's capabilities by ensuring that specific security invariants are not violated, such as in-process isolation mechanisms and software pruning schemes.

[0007] A small portion of the aforementioned protection solutions have been widely deployed in real-world systems due to their efficiency and effectiveness. However, these solutions focus only on specific attack types caused by memory corruption vulnerabilities, such as stack canaries targeting stack buffer overflows and Intel CET (Control-flow Enforcement Technology) targeting control flow hijacking attacks. They do not mitigate other types of attacks or protect against non-memory corruption vulnerabilities.

[0008] Furthermore, most of the solutions described above require code instrumentation and transformation based on the source code of the software to be hardened, thus making them unable to handle binary executables. While some solutions can handle binary executables, static disassembly and precise binary code rewriting are not easy and remain open problems. Meanwhile, dynamic binary code rewriting introduces a significant performance overhead.

[0009] Unlike the solutions mentioned above that can only mitigate fixed types of vulnerabilities, monitors are a flexible and programmable solution that can be used to implement a wide variety of security strategies, typically monitoring processes while they are running.

[0010] Researchers have proposed numerous monitoring solutions. Software-based monitors typically dedicate a dedicated general-purpose processor core to analyze collected information and make decisions. Some commercial processors also offer hardware features to accelerate the collection of runtime information, such as Intel PT (Processor Trace) and ARM CoreSight. Additionally, many hardware-assisted techniques have been proposed to filter collected information, thereby reducing the volume of data that needs to be processed. Nevertheless, when a general-purpose processor core is occupied by a monitor, it cannot perform other normal tasks. Therefore, in terms of total CPU time and chip area, the overhead introduced by such monitors is quite significant.

[0011] Other monitors are primarily hardware-based, and they exhibit several typical architectural designs.

[0012] The first type of design associates each memory word with a tag as metadata, propagating and calculating the tag according to a configured strategy to ultimately make a decision. Specific examples of this type of design include Harmoni and PUMP. As a memory tag-based monitor, the storage and management of tags, depending on their size, inevitably introduces significant hardware and performance overhead. Some solutions in this type of design require modifications to components that span the entire computer architecture, from memory to registers.

[0013] The second type of design integrates a reconfigurable structure (i.e., FPGA, Field-Programmable Gate Array) into the system-on-a-chip. It utilizes the programmable logic within the FPGA to analyze collected runtime behavior information and ultimately make decisions. A typical example of this type of design is FlexCore. Because the clock frequency of an FPGA is much lower than that of a high-performance modern processor core, when the FPGA cannot process the large amount of collected information, it will block the execution of the processor core, thus introducing significant performance overhead. Reconfiguring the FPGA is also relatively slow, and process context switching also introduces significant performance overhead.

[0014] The last design integrates the coprocessor into the system-on-a-chip, using it to analyze the collected information and ultimately make decisions. PHMon is the most advanced design in this category. Similar to the second type of design, because the coprocessor's performance is relatively low compared to general-purpose processor cores (otherwise, the coprocessor would occupy a larger chip area), this type of design also introduces significant performance overhead when the coprocessor cannot process the collected information. Reprogramming the coprocessor during process context switching also introduces a non-negligible performance overhead.

[0015] A key attribute of a monitor is its ability to support real-time monitoring. Specifically, monitors that collect and analyze program execution traces or commit logs typically do not support real-time monitoring. This is because program execution traces and commit logs are generated by the processor core only after the instructions of interest have completed execution. In this case, malicious side effects from executed instructions may have already occurred before the monitor detects any anomalous behavior and generates an exception to terminate the process. For example, I / O requests to critical devices may have been issued, or network packets carrying sensitive information may have been sent. In other words, the exceptions generated by the monitor are asynchronous, not real-time.

[0016] In conclusion, how to address the issue that existing software security protection methods and technologies suffer from high hardware and / or performance overhead in monitoring solutions, and do not support real-time monitoring, is an important issue that urgently needs to be addressed in the computer field. Summary of the Invention

[0017] This application provides a software security protection method and apparatus based on memory access control lists, which overcomes the shortcomings of existing software security protection methods and technologies, such as the high hardware and / or performance overhead of the monitoring scheme and the lack of support for real-time monitoring. It does not introduce any runtime performance overhead during monitoring, can greatly reduce hardware overhead, and can also mitigate different types of vulnerabilities.

[0018] On the one hand, this application provides a software security protection method based on a memory access control list, including: obtaining the current memory operation generated by the memory access instruction 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.

[0019] Furthermore, 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; correspondingly, the memory access control list includes several memory access rules, each memory access rule including the expected value of the several fields, a mask for matching, and an action for execution, wherein the action is to allow the memory operation or to block the memory operation.

[0020] Furthermore, the process of matching the current memory operation based on the pre-stored memory access control list to obtain a memory operation matching result includes: matching several fields contained in the current memory operation with several memory access rules in the memory access control list using a value and mask method to obtain a memory operation matching result; wherein, the memory operation matching result is either a match with a rule or a non-match with a rule.

[0021] Further, determining whether to execute or block the current memory operation based on the memory operation matching result includes: if the memory operation matching result matches a rule, determining 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, executing 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.

[0022] Furthermore, for each thread of the process, a global status register is maintained; correspondingly, 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 status of the status register; the memory access control list includes several memory access rules, each memory access rule includes the expected value of the several fields, a mask for matching, and an action for execution, which is to allow the memory operation or block the memory operation.

[0023] Furthermore, the memory access instructions include memory access instructions from the RISC-V instruction set.

[0024] Secondly, this application provides a software security protection device based on a memory access control list, comprising: a current memory operation acquisition module, used to acquire the current memory operation generated by memory access instructions during the runtime of a target program; a current memory operation matching module, 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, used to determine whether to execute the current memory operation or block the current memory operation based on the memory operation matching result.

[0025] Thirdly, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the software security protection method based on memory access control lists as described above.

[0026] Fourthly, this application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the software security protection method based on memory access control lists as described above.

[0027] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the software security protection method based on memory access control lists as described above.

[0028] The software security protection method based on memory access control lists provided in this application obtains the current memory operations generated by memory access instructions during the runtime of the target program, and matches the current memory operations against a pre-stored memory access control list to obtain the memory operation matching result. Then, based on the memory operation matching result, it determines whether to execute or block the current memory operation. This method monitors memory access instructions in real time by filtering current memory operations using memory access control lists. 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. Attached Figure Description

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

[0030] Figure 1 is a flowchart illustrating the software security protection method based on memory access control lists provided in an embodiment of this application.

[0031] Figure 2 is a schematic diagram of the framework of the software security protection method based on memory access control list provided in the embodiments of this application.

[0032] Figure 3 is a schematic diagram of the overall process of the software security protection method based on memory access control list provided in the embodiments of this application.

[0033] Figure 4 is a schematic diagram of the structure of a software security protection device based on a memory access control list provided in an embodiment of this application.

[0034] Figure 5 is a schematic diagram of the physical structure of the electronic device provided in an embodiment of this application. Detailed Implementation

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

[0036] It should be noted that existing software security protection methods and technologies have high hardware and / or performance overhead and do not support real-time monitoring. To solve this problem, this application proposes a new monitoring scheme, namely a software security protection method based on memory access control lists.

[0037] Before describing the software security protection method based on memory access control lists provided in this application, the following briefly explains why memory access instructions are used as real-time monitoring targets.

[0038] Specifically, this application first examines different types of instructions in instruction set architectures. More specifically, this application focuses on the RISC-V instruction set. Because the RISC-V instruction set is representative, this application can be easily extended to other instruction set architectures. The safety checks for system calls and breakpoints are carefully performed by the operating system kernel. Meanwhile, user-mode applications are not allowed to perform privileged operations. Therefore, this application only needs to examine the remaining instruction types.

[0039] In the sense of side effects, ALU (Arithmetic Logic Unit) operations only perform computations, while branches, direct jumps, and direct calls simply transfer control flow to predefined fixed locations. Therefore, these instructions have almost no side effects and are safe.

[0040] Indirect jumps and function calls are common targets of control flow hijacking attacks because they can transfer control flow to locations determined at runtime. However, these control flow transfers are typically achieved by memory-access instructions preceding the program. Memory-access instructions can read or modify memory contents, thus producing persistent side effects throughout the process's lifetime. In low-level software, such as the operating system kernel or user-space device drivers, these instructions can even access peripherals and affect the physical world. Furthermore, if the results of ALU operations are to be used later, the program will eventually use memory-access instructions to write these results back into memory. Therefore, memory-access instructions are crucial targets for effective surveillance.

[0041] In terms of monitoring performance, ALU operations, branches, jumps, and function calls execute very quickly in high-performance processor cores, typically requiring only 0 to 1 clock cycle latency. Therefore, monitors cannot make decisions about these instructions and their operands within such a short timeframe. Consequently, these instruction categories are unsuitable for real-time monitoring. Conversely, even with TLB and caching for acceleration, memory access instructions generally require more clock cycles to complete. This provides monitors with ample time to analyze these instructions and make decisions while they are executing, but before their side effects occur. Therefore, memory access instructions are a convenient target for efficient and real-time monitoring.

[0042] In general, memory access instructions are a crucial and convenient target for an effective, efficient, and real-time monitoring solution. The monitoring solution provided in this application uses memory access instructions as its monitoring target.

[0043] Regarding the software security protection method based on memory access control lists, Figure 1 shows a flowchart of the software security protection method based on memory access control lists provided in the embodiments of this application.

[0044] As shown in Figure 1, the method includes steps S110-S130, and steps S110-S130 and related steps will be described in detail below.

[0045] S110: Obtain the current memory operation generated by the memory access instructions during the runtime of the target program.

[0046] It is understandable that when a 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.

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

[0048] Memory access instructions include, but are not limited to, memory read instructions, memory write instructions, swap instructions, conditional store instructions, and atomic operation instructions.

[0049] Memory read instructions are used to read data from memory and copy it to registers or other storage units. Memory write instructions are used to write data from registers or other storage units to a specific address in memory. Swap instructions are used to directly exchange data between memory locations and registers without first loading it into a register and then storing it back. Conditional store instructions are used to store data into memory only when specific conditions are met. Atomic operation instructions are used to ensure that access to shared resources is mutually exclusive in a multi-threaded environment.

[0050] 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 to which the memory operation points, and the memory content accessed by the memory operation. The type of memory operation includes, but is not limited to, memory read and memory write.

[0051] It should be noted that both instruction addresses and memory addresses in the current memory operations use virtual addresses.

[0052] Based on obtaining the current memory operation generated by the memory access instruction during the runtime of the target program in step S110, step S120 is further executed.

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

[0054] Understandably, after each memory access instruction in the target program generates a memory operation, these memory operations will typically go to the first-level and possibly lower-level data TLBs for address translation and permission checks, and then go to the first-level and possibly lower-level data caches to access the contents in memory.

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

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

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

[0058] 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 values ​​allowed for a match. Furthermore, each memory access rule includes an action to be taken, which can either allow or block the current memory operation.

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

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

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

[0062] 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".

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

[0064] In this embodiment, the current memory operations generated by the 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.

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

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

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

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

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

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

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

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

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

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

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

[0076] It is worth mentioning that, since the code or data with relevant functions are usually located in corresponding contiguous memory regions, this application also provides range matching support for instruction addresses and memory addresses to facilitate user use and reduce the number of rules. However, while 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 relevant functions are usually located in the same function, object file (i.e., *.o file), or memory object, and their size is usually relatively small, this application only needs to provide range matching support for certain least significant bits, which will greatly reduce hardware overhead.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0093] 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 application.

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

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

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

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

[0098] In some embodiments, Figure 2 illustrates a framework diagram of the software security protection method based on memory access control lists provided in this application.

[0099] As shown in Figure 2, 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 access the contents of memory from the first-level and possibly lower-level data caches.

[0100] This application slightly extends this process by using a memory access control list (MAR) to examine each memory operation heading towards 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.

[0101] In some embodiments, Figure 3 illustrates the overall flowchart of the software security protection method based on memory access control lists provided in this application.

[0102] As shown in Figure 3, the processor core is first slightly modified to add the matching and checking logic of this application, 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 application 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.

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

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

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

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

[0107] 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 application 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 finds that two SRL16E primitives, namely two 16-bit shift registers, can be laid out in the same LUTRAM (Look-Up Table Random Access Memory) primitive, thereby efficiently simulating a 4-bit wide × 2-entry deep TCAM.

[0108] 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 (16 possibilities), and stores the calculated result in an SRL16E. Subsequently, the SRL16E can output whether an input matches the TCAM entry. Then, this embodiment 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.

[0109] This embodiment also implements range matching for the SRL16E-based TCAM to support the rules of this application. 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.

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

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

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

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

[0114] 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 this 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.

[0115] Then, TCAM outputs the action and status update information for the matched rules. If no matching rule exists in TCAM, this application will allow the memory operation by default. If the matched rule prevents the memory operation, this application 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 the exception when the corresponding instruction is committed. If the matched rule allows the memory operation, this application will store the status update information in the memory read queue or memory write queue.

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

[0117] 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 application to use outdated status values ​​when matching rules, this embodiment believes that in practice, the memory operations of interest will be far enough apart to be unaffected by this characteristic.

[0118] To provide an interface for software to manage the rules of this application, 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, namely aclInsnAddr, aclInsnAddrMask, aclMemAddr, aclMemAddrMask, aclMemData, aclMemDataMask, aclStateAndMask, and aclAction, used to temporarily store the rules that need to be written.

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

[0120] 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, existing CSR implementations in the RISC-VBOOM core flush 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.

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

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

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

[0124] 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 their priorities of this application. In particular, for prctl() calls that manipulate rules for other processes, this embodiment follows the permission check of ptrace(), specifically ptrace_may_access(), to check the legitimacy of the call, thus ensuring that the modifications in this embodiment do not introduce new security issues.

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

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

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

[0128] Previous research has observed that only a small number of processes possess potential vulnerabilities and therefore require protection. For this application, this means that only a small number of processes will have non-empty access control lists (Access Control Lists). Therefore, this embodiment first stores a pointer in the kernel to the memory access control list currently configured in the hardware. Whenever the kernel switches the context to a new process with a non-empty access control list, this embodiment writes the access control list 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 memory access control list, 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 memory access control list. Subsequently, when the kernel switches the context back to the previous process with a non-empty access control list, this embodiment checks whether the access control list 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 access control list into the hardware, because only that highest priority rule was previously overwritten by a process with an empty access control list. Otherwise, this indicates that the hardware access control list has been overwritten by another process, and this optimization cannot be performed in this embodiment.

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

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

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

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

[0133] Subsequently, the utility configures all rules except the highest priority rule. Finally, the utility configures the highest priority rule to the desired value. Thus, this embodiment can configure the rules of this application for new or existing processes without interrupting execution.

[0134] Corresponding to the software security protection method based on memory access control lists described in the above embodiments, this application also provides a software security protection device based on memory access control lists. Specifically, Figure 4 shows a schematic diagram of the structure of the software security protection device based on memory access control lists provided in the embodiments of this application.

[0135] As shown in Figure 4, 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.

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

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

[0138] Figure 5 shows a schematic diagram of the physical structure of an electronic device. As shown in Figure 5, the electronic device may include: a processor 510, a communication interface 520, a memory 530, and a communication bus 540, wherein the processor 510, the communication interface 520, and the memory 530 communicate with each other through the communication bus 540. The processor 510 can call 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 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] 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 this application, in essence, or the part that contributes to the prior art, or a portion 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 this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0140] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can 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 of the target program during runtime; 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.

[0141] In another aspect, this application also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program is implemented to perform 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 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.

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

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

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

Claims

1. A software security protection method based on memory access control lists, comprising: Obtain the current memory operations generated by memory access instructions during the target program's runtime; Based on a pre-stored memory access control list, the current memory operation is matched to obtain the memory operation matching result; 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, wherein, 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. Accordingly, 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 for execution, which is to allow memory operations or prevent memory operations.

3. The software security protection method based on a memory access control list according to claim 2, wherein, 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.

4. The software security protection method based on a memory access control list according to claim 3, wherein, 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.

5. The software security protection method based on a memory access control list according to claim 1, wherein, 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.

6. The software security protection method based on a memory access control list according to any one of claims 1 to 5, wherein, The memory access instructions include memory access instructions from the RISC-V instruction set.

7. A software security protection device based on a memory access control list, comprising: 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 matching module is used to match the current memory operation based on a pre-stored memory access control list to obtain the memory operation matching result; 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.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the software security protection method based on a memory access control list as described in any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the software security protection method based on a memory access control list as described in any one of claims 1 to 6.

10. A computer program product comprising a computer program that, when executed by a processor, implements the software security protection method based on a memory access control list as described in any one of claims 1 to 6.

Images