A Multi-Level Return Address Stack Management Method and System for Control Flow Integrity

Abstract

This application proposes a multi-level return address stack management method and system for control flow integrity, relating to computer technology and data processing technology. The method includes: responding to a received call instruction, querying a mapping table based on the target Security Context Identifier (SCID) of the currently executing thread to determine the target GRAS partition from multiple hierarchical return address stack GRAS partitions; obtaining the return address and hardware key, and generating a Control Flow Integrity Tag (CFI Tag) based on the return address, hardware key, and target SCID; and pushing the return address, CFI Tag, and target SCID as atomic entries into the target GRAS partition to isolate and manage the return address. This application can achieve multi-level isolation of return addresses, reduce the error matching rate of shadow stacks and RAS under complex control flows, and effectively resist advanced control flow attacks such as abnormal path hijacking and cross-privilege level attacks, achieving enhanced security isolation.

Description

Technical Field

[0001] This application relates to the fields of computer technology and data processing technology, and in particular to a multi-level return address stack management method and system for control flow integrity. Background Technology

[0002] In related technologies, the hardware return address stack (RAS) is a single-level or monolithic structure, lacking the ability to perceive and differentiate complex control flows. The RAS cannot effectively distinguish between ordinary function calls, exception or interrupt calls, switches between different privilege levels, and nested security calls at the hardware level. This flat structure fails to provide structured isolation for return addresses from different security contexts (such as user mode, kernel mode, and different threads), easily leading to address pollution within one security domain leaking into other domains, leaving opportunities for cross-privilege attacks and abnormal path hijacking. The monolithic structure presents isolation and security problems.

[0003] Return address protection schemes, such as software shadow stacks or loosely coupled hardware implementations, suffer from significant performance overhead or implementation limitations. Pure software shadow stack schemes require additional instructions and memory operations for each function call and return, introducing significant runtime overhead and memory bandwidth pressure, making them difficult to apply to performance-sensitive RISC-V processors. Traditional hardware CFI schemes are often fixed strategies, lacking flexible configuration interfaces and unable to dynamically adjust protection strength based on the security sensitivity of different code modules, resulting in unnecessary performance burdens on non-critical code. These all present performance and implementation challenges.

[0004] The lack of tight and atomic hardware coordination between the address prediction and CFI verification mechanisms in the Branch Prediction Unit (RAS) leads to timing vulnerabilities and security blind spots in the integrity verification of the return address. During the pipeline execution of the return instruction, the extraction of the RAS-predicted address and the verification of the Control-Flow Integrity (CFI) label are typically independent or asynchronous. This non-atomic operation allows attackers to potentially exploit timing windows to tamper with the address. This lack of coordination prevents multi-dimensional, ternary verification of the return address (i.e., simultaneous matching of address, CFI label, and context ID), making control flow attacks such as RAS pollution attacks difficult to defend against effectively. This may result in coordination and timing vulnerabilities between the prediction and verification mechanisms.

[0005] Processor architectures, especially RISC-V, lack a hardware-supported, efficient, and atomic Return Address Stack (RAS) state management mechanism. When the operating system performs thread switching or privilege level switching, the software manually clears or saves / restores the RAS state. This process is time-consuming and vulnerable to tampering by attackers using non-atomic operations. The lack of hardware instructions or mechanisms to quickly and safely freeze, save, and load the RAS context results in significant performance overhead with each context switch and fails to guarantee strict and reliable isolation of the return address stacks between different execution entities. Furthermore, there is a lack of hardware-supported secure context switching mechanisms. Summary of the Invention

[0006] This application aims to at least partially address one of the technical problems in the related art. The technical solution disclosed herein is as follows:

[0007] The first aspect of this application proposes a multi-level return address stack management method for control flow integrity, including:

[0008] In response to receiving a call instruction, the target GRAS partition is determined from multiple hierarchical return address stack GRAS partitions by querying the mapping table based on the target security context identifier (SCID) of the currently executing thread. The mapping table includes the mapping relationship between security context identifiers and GRAS partitions.

[0009] Obtain the return address and hardware key, and generate a Control Flow Integrity Tag (CFI Tag) based on the return address, hardware key, and target SCID;

[0010] The return address, CFI tag, and target SCID are pushed as atomic entries into the target GRAS partition to isolate and manage the return address.

[0011] In some implementations, the multiple GRAS partitions include at least a machine-mode partition, a supervisory-mode partition, and a user-mode partition, which isolate and manage the return addresses of firmware, kernel, and applications, respectively; and / or, atomic entries also include ciphertext of the return address encrypted according to a hardware key; and / or, the mapping table is dynamically configured by a configuration register or privileged instruction.

[0012] In some implementations, it also includes:

[0013] In response to receiving a return instruction, the prediction entry is popped from the target GRAS partition;

[0014] Calculate the register address corresponding to the return instruction;

[0015] Based on the CFI verification level corresponding to the target GRAS partition, the consistency verification, tag verification, and context matching of the register calculated address and the return address in the prediction entry are performed atomically within the same pipeline cycle to obtain the verification results.

[0016] In response to the verification result indicating that the verification passed, a return instruction is executed, and control flow is transferred to the target address.

[0017] In some implementations, the GRAS partition also includes an exception handling partition, which, after obtaining the verification result, further includes:

[0018] In response to the verification result indicating that the verification failed, a Control Flow Integrity (CFI) verification failure exception is triggered, and exception handling is performed in the exception handling partition.

[0019] In some implementations, exception handling is performed in the exception handling partition, including:

[0020] The return address is identified as the violation address, and the violation address, the reason for the verification failure, and the current GRAS status are stored as a violation entry in the isolation register;

[0021] Perform at least one of the following operations according to the preset security policy: restrict access to registers; log attack attempts corresponding to the call instructions; continue execution of threads after reducing the Control Flow Integrity (CFI) verification level; terminate the execution thread corresponding to the violation entry; clear or restore the affected execution thread or GRAS partition.

[0022] In some implementations, it also includes:

[0023] In response to a thread switch, the GRAS state management instructions are parsed and responded to. The GRAS state management instructions include a first GRAS state management instruction and a second GRAS state management instruction.

[0024] In response to receiving the first GRAS state management instruction, the state of the GRAS partition of the current thread is frozen in a hardware atomic operation manner, and the state of the specified GRAS partition is encrypted and saved.

[0025] In response to receiving a second GRAS state management instruction, the state of the next thread in the specified GRAS partition is decrypted and restored using a hardware atomic operation.

[0026] In some implementations, it also includes:

[0027] In response to the GRAS partition meeting the preset migration conditions, the atomic entries of the GRAS partition are migrated according to the creation time of the atomic entries of the GRAS partition;

[0028] The migration conditions are that the occupancy rate of the GRAS partition is greater than the preset occupancy rate threshold, or the recursive call depth limit is triggered.

[0029] A second aspect of this application proposes a multi-level return address stack management system for control flow integrity, including a GRAS module, a compiler module, a configuration management module, and a hardware encryption module, wherein:

[0030] The GRAS module includes multiple independent GRAS partitions, which are used to isolate and differentiate the return addresses of different GRAS partitions.

[0031] The hardware encryption module is used to store the hardware key and perform encryption and decryption operations for generating and verifying CFI Tags based on the hardware key;

[0032] The compiler module is used to insert metadata at sensitive call points during compilation, or to identify call instructions that require the use of the GRAS module;

[0033] The configuration management module is used to configure the policy management parameters of the GRAS module and manage the status of the GRAS partition during context switching.

[0034] In some implementations, the GRAS module is also used for:

[0035] In response to receiving a call instruction, the target GRAS partition is determined from multiple hierarchical return address stack GRAS partitions by querying the mapping table based on the target security context identifier (SCID) of the currently executing thread. The mapping table includes the mapping relationship between security context identifiers and GRAS partitions.

[0036] Obtain the return address and hardware key, and generate a Control Flow Integrity Tag (CFI Tag) based on the return address, hardware key, and target SCID;

[0037] The return address, CFI tag, and target SCID are pushed as atomic entries into the target GRAS partition to isolate and manage the return address.

[0038] In some implementations, the GRAS module is also used for:

[0039] In response to a processor privilege level switch or an exception signal, the operation pointer is redirected from the current GRAS partition to the target GRAS partition corresponding to the privilege level or the exception.

[0040] In response to receiving a return instruction, the prediction entry is popped from the target GRAS partition;

[0041] Based on the CFI check level corresponding to the target GRAS partition, address verification, tag verification, and context matching are performed atomically.

[0042] If the verification passes, a return transfer is executed; or, if the verification fails, a CFI verification failure exception is triggered.

[0043] In some implementations, the GRAS module further includes an atomic verification layer and a capacity management layer, wherein:

[0044] An atomic verification layer is used to store atomic entries in different GRAS partitions;

[0045] The capacity management layer stores atomic entries for GRAS partitions;

[0046] The GRAS module is also used to migrate atomic entries from the atomic verification layer to the capacity management layer when the GRAS partition meets the preset migration conditions in the atomic verification layer, based on the creation time of the atomic entries of the GRAS partition.

[0047] The migration conditions are that the occupancy rate of the GRAS partition is greater than the preset occupancy rate threshold, or the recursive call depth limit is triggered.

[0048] In some implementations, the compiler module is also used to support the generation of CFI tags; the configuration management module is also used to dynamically configure and manage mapping tables.

[0049] A third aspect of this application provides an electronic device, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the instructions to implement a multi-level return address stack management method for control flow integrity as provided in the first aspect of this application.

[0050] A fourth aspect of this application provides a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to execute the multi-level return address stack management method for control flow integrity provided in the first aspect of this application.

[0051] This application aims to propose a hierarchical return address stack (RAS) and shadow stack management mechanism for control flow integrity (CFI). Through multi-level isolation, dynamic control, trusted verification, and context switching awareness of return addresses, it overcomes the contradiction between performance and security.

[0052] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0053] Figure 1 This is a flowchart of a multi-level return address stack management method for control flow integrity according to an embodiment of this application;

[0054] Figure 2 This is a flowchart of a multi-level return address stack management method for control flow integrity according to an embodiment of this application;

[0055] Figure 3 This is a flowchart of a multi-level return address stack management method for control flow integrity according to an embodiment of this application;

[0056] Figure 4 This is a flowchart of a multi-level return address stack management method for control flow integrity according to an embodiment of this application;

[0057] Figure 5 This is a structural block diagram of a multi-level return address stack management system for control flow integrity according to an embodiment of this application;

[0058] Figure 6 This is a flowchart illustrating the hierarchical structure of GRAS according to one embodiment of this application;

[0059] Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0060] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0061] The acquisition, storage, and application of information and data involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0062] The following is an explanation of the terms used in this application.

[0063] RISC-V is an open instruction set architecture (ISA).

[0064] ROP (Return-oriented Programming) is a control flow hijacking attack technique. Attackers can manipulate the return address in the stack to make the processor jump between a series of code segments (called gadgets) ending with RET instructions, thereby achieving arbitrary logic execution without injecting new code.

[0065] The RET instruction is a key instruction in the management field used for subroutine return. Its main function is to resume the main program execution flow by manipulating the stack pointer (SP) and program counter (PC).

[0066] ROP-like (Return-Oriented Programming–like attack) is not a single attack, but a general term for a class of attack forms that are the same as or similar to the principles of ROP.

[0067] Operating System (OS) and Hypervisor: The module in the operating system (OS) responsible for virtualization support, or the kernel module that extends the operating system into a Hypervisor (virtual machine monitor).

[0068] The CFI Failure Handler is a kernel mechanism for handling failures when the compiler enables CFI checks. It is designed to detect and respond to control flow exceptions in indirect function calls to enhance system security.

[0069] Hardware atomic operations are the underlying mechanism in computer systems that ensures the indivisibility of operations in a multi-threaded / multi-core environment. They ensure that an operation is not interrupted by other processors or threads during its execution.

[0070] The following describes, with reference to the accompanying drawings, a multi-level return address stack management method and system for control flow integrity according to embodiments of this application.

[0071] Figure 1 This is a flowchart of a multi-level return address stack management method for control flow integrity according to an embodiment of this application, as follows: Figure 1 As shown, the method includes the following steps:

[0072] S101, in response to receiving a call instruction, queries a mapping table based on the target security context identifier (SCID) of the currently executing thread to determine the target GRAS partition from multiple hierarchical return address stack GRAS partitions.

[0073] Optionally, the mapping table includes a mapping between Security Context Identifiers (SCIDs) and GRAS partitions. The mapping table is dynamically configured by configuration registers or privilege level instructions.

[0074] Optionally, the multiple GRAS partitions include at least a machine-mode partition, a supervisory-mode partition, and a user-mode partition, which respectively isolate and manage the return addresses of firmware, kernel, and applications.

[0075] The GRAS proposed in this application can work together in the instruction pipeline to eliminate timing vulnerabilities and achieve a balance between security and performance.

[0076] The following describes the processing flow of the JAL instruction in this application.

[0077] The target GRAS partition is determined based on the SCID of the currently executing thread and the mapping rules in the CSR.

[0078] Specifically, the target SCID of the currently executing thread is queried in the mapping table to determine the GRAS partition identifier corresponding to the target SCID. Furthermore, the target GRAS partition is determined based on the GRAS partition identifier.

[0079] S102, obtain the return address and hardware key, and generate a control flow integrity tag (CFI Tag) based on the return address, hardware key, and target SCID.

[0080] The core of the process of obtaining the return address and hardware key is "data preparation".

[0081] The process of obtaining the return address (RA) is described below: When the processor executes a call instruction (such as JAL), the hardware will automatically write the address of the next instruction (PC+4) into the specified register (such as the x1 / ra register of RISC-V).

[0082] The following describes the process of obtaining the hardware key: The key is usually stored in a secure, isolated area inside the hardware, such as an OTP (One-Time Programmable Memory), a PUF (Physically Unclonable Function) unit, or a protected privileged CSR register. During initialization, the hardware circuit loads the key into a dedicated "shadow register," which is not visible to ordinary software and can only be accessed directly by the encryption engine (such as the CFI verification unit) via physical connections.

[0083] The CFI verification unit atomically generates a CFI tag (e.g., pointer authentication PAC) based on the return address, hardware key, and current target SCID.

[0084] The process of generating a CFI Tag is described below: Generating a Tag essentially involves performing an encryption or hash operation. The formula is: Tag = FK(RA, Context); where F represents the encryption algorithm, K represents the hardware key, RA represents the return address, and Context represents the context information (SCID in the scheme). The specific steps include: 1. Input assembly: The hardware logic concatenates RA and SCID into a bit vector. 2. Encryption calculation: The encryption engine transforms the input using the key K within 1-2 clock cycles. 3. Output truncation: To save storage space, typically only the high or low bits of the encryption result (e.g., 16 bits or 32 bits) are taken as the final CFI Tag.

[0085] S103 pushes the return address, CFI Tag, and target SCID as atomic entries into the target GRAS partition to isolate and manage the return address.

[0086] The atomic push process is described below: The hardware pushes the return address, the generated CFI Tag, and the target SCID as an atomic entry into the determined target GRAS partition, enabling strict isolation and differentiated policy management of return addresses for different security domains.

[0087] Optionally, the atomic entry may also include ciphertext obtained by encrypting the return address using a hardware key.

[0088] This application queries a mapping table based on the target Security Context Identifier (SCID) of the currently executing thread to determine the target GRAS partition from multiple hierarchical return address stack GRAS partitions. A Control Flow Integrity Tag (CFI Tag) is generated based on the return address, hardware key, and target SCID. The return address, CFI Tag, and target SCID are then pushed into the target GRAS partition as atomic entries to isolate and manage the return address. This enables multi-level isolation of the return address, reduces the error matching rate of the shadow stack and RAS under complex control flows, and effectively resists advanced control flow attacks such as ROP / ROP-like attacks, abnormal path hijacking, and cross-privilege level attacks, thus achieving enhanced security isolation.

[0089] Figure 2 This is a flowchart of a multi-level return address stack management method for control flow integrity according to an embodiment of this application, as follows: Figure 2 As shown, the method includes the following steps:

[0090] S201, in response to receiving a return instruction, pop the prediction entry from the target GRAS partition.

[0091] The following describes the processing flow of the return (JALR) instruction.

[0092] In response to receiving a return instruction, the branch prediction unit pops a prediction entry from the target GRAS partition corresponding to the current target SCID.

[0093] In the design, predicted entries and atomic entries are physically stored the same thing, but they play different roles at different stages of the pipeline. A complete entry (triple) typically includes: a return address (RA): used to redirect the front-end instruction fetch stream (PC update); a CFI tag: used for subsequent integrity checks; and an SCID: used to verify the legitimacy of the current execution context. Popping predicted entries based on the return instruction is done precisely from the corresponding GRAS logical partition according to the current privilege level (U / S / M) GRAS partition and SCID, enabling hierarchical partition popping. Furthermore, the process of popping predicted entries simultaneously pops encrypted tags and identity identifiers (SCID) for security checks, enabling security information synchronization. In this application, M, S, and U refer to Machine state, Supervisor state, and User state, respectively.

[0094] The pop process is described below. The entire process occurs during the processor's fetch or decode phase and includes the following steps: 1. Instruction Recognition: The prefetch unit identifies the current instruction as a return-like instruction. 2. Context Extraction: The hardware extracts the current privilege level state and the value of the SCID register in real time. 3. Partition Indexing: Based on the above information, the GRAS management unit locates a specific physical partition (e.g., a user-space partition) in the L1-RAS (Level 1 Atomic Check Layer). 4. Atomic Pop: The hardware reads the entry pointed to by the top of the stack pointer of this partition. The RA is directly fed back to the program counter (PC), achieving zero-latency jump prediction. The tag and SCID enter the pipeline back end with the instruction flow, ready for "ternary atomic check". 5. Pointer Update: The top of the stack pointer is decremented by 1. If the L1 partition is about to become empty, the automatic filling logic from the L2-RAS (Level 2 Capacity Management Layer) is triggered. The pop process of this application is characterized by the deep coupling of prediction and verification. This application implements atomic extraction of multi-dimensional data (RA, Tag, SCID) based on SCID indexes during the instruction fetch stage. This ensures that the predicted address carries its unforgeable "identity certificate" from the moment it enters the pipeline, thereby eliminating the possibility of predictive execution attacks (such as Spectre variants) hijacking the system using a corrupted return stack at the underlying hardware level.

[0095] S202, obtain the register address corresponding to the return instruction.

[0096] S203, based on the CFI check level corresponding to the target GRAS partition, atomically performs consistency checks, tag checks, and context matching between the register-calculated address and the return address in the prediction entry within the same pipeline cycle, and obtains the check results.

[0097] The ternary atomic verification in this application refers to the hardware verification unit atomically performing address verification, tag verification, and context matching within the same pipeline cycle. Address verification checks whether the target return address is a valid address. Tag verification recalculates and compares the displayed CFI tag using the same hardware key and the current SCID. Context matching checks whether the SCID stored in the displayed entry matches the current or expected SCID (preventing cross-thread / cross-privilege level attacks).

[0098] S204, in response to the verification result indicating that the verification passed, executes the return instruction and transfers the control flow to the target address.

[0099] If all three checks pass, a return instruction is executed, and control flow is transferred to the target address. The target address, also known as the destination address, is essentially the "return address (RA)" that has been checked and confirmed to be valid.

[0100] In the GRAS architecture pipeline, the determination of the target address follows the logic of "dual-path comparison and final confirmation." Taking path A as an example, in the prediction path (front end), while the instruction is still in the fetch stage, the branch predictor recognizes that this is a return instruction and pops an address from the top of the GRAS stack. At this point, the processor "thinks" this is the target address and begins prefetching the instruction at that address. Taking path B as an example, in the execution path (back end), when the instruction reaches the execution stage, the hardware calculates the actual jump target from the register specified by the instruction (such as x1 / ra in RISC-V). Finally, the hardware will only truly "commit" the jump when the CFI verification unit completes three checks (RA, Tag, and SCID all match) and the address calculated by path B is consistent with the address popped from path A.

[0101] At this point, the verified RA officially becomes the program counter (PC) value for the next instruction. This application ensures the absolute reliability of control flow transfer by atomically comparing the calculated jump target with the return address (RA) extracted and verified from the hardware isolated partition (GRAS). The determination of the target address does not rely on vulnerable general-purpose registers or the software stack, but is based on hardware-encrypted secure stack entries as the final decision-making basis. Only if the ternary check passes completely is the address allowed to update the program counter (PC), thereby eliminating the risk of control flow hijacking at the physical level.

[0102] S205, in response to the verification result indicating that the verification failed, triggers a Control Flow Integrity (CFI) verification failure exception and performs exception handling in the exception handling partition.

[0103] In some implementations, if any verification fails, a dedicated CFI verification failure exception (Trap) is triggered, and the process proceeds to the next step of exception handling.

[0104] Optionally, the return address is identified as the violation address, and the violation address, the reason for the verification failure, and the current GRAS status are stored as violation entries in the isolation register.

[0105] Optionally, perform at least one of the following operations according to a preset security policy: restrict access to registers; log attack attempts corresponding to the call instructions; continue thread execution after lowering the Control Flow Integrity (CFI) verification level; terminate the execution thread corresponding to the violation entry; clear or restore the affected execution thread or GRAS partition.

[0106] The exception / interruption path management mechanism of this application is described below.

[0107] When an exception or privilege level switch occurs, the hardware automatically switches the GRAS operation pointer to the dedicated GRAS partition for exceptions / kernels, while freezing the state of the user-mode GRAS partition, thus achieving automatic hardware switching. The failure of a return instruction verification is an exception, a specific exception defined in this application. Other common exceptions include: illegal instructions, privileged instruction violations, memory address alignment errors, page faults, access permission violations, arithmetic overflow / division by zero, breakpoint exceptions, environment call exceptions, etc. In the RISC-V architecture, the privilege level determines which hardware resources and instructions the software can access, divided into three privilege levels: M / S / U. Privilege switching is the process of the processor vertically jumping between these modes. There are three privilege switching paths: 1. Exception path, synchronously triggered (errors occur during instruction execution, such as verification failures); 2. Interrupt and system call path, asynchronous or actively requested (external hardware interrupts or ecall instructions (system calls)); 3. Privilege return path, instruction-driven (a return instruction executed after processing for privilege mode switching, such as MRET or SRET).

[0108] During an exception return (MRET / SRET), the hardware switches back to the user-mode GRAS partition and performs a CFI check to ensure that the return address has not been contaminated during exception handling, thus achieving a safe return. An exception return refers to the hardware switching back from machine / kernel mode to user mode after executing the MRET / SRET instructions.

[0109] The failure handling and strategy of this application can realize programmable CFI failure handling (graceful degradation). When an exception is triggered and the CFI check fails, the hardware triggers a dedicated exception vector instead of a general illegal instruction or hardware failure.

[0110] It's important to note that CFI verification and CFI Tag verification can be viewed as a whole and its parts. CFI verification refers to the entire set of behaviors related to "Control Flow Integrity Verification." Its purpose is to ensure that the program's execution path does not deviate from the predetermined "Control Flow Graph (CFG)." In the GRAS architecture, the "ternary atomic verification" as a whole belongs to CFI verification. It not only verifies the Tag but also verifies whether the target address is valid (RA verification), whether the execution context matches (SCID verification), and whether the label is correct (Tag verification). CFI Tag verification is the most crucial sub-step in CFI verification; it addresses the specific issue of whether the return address has been tampered with.

[0111] In this application, the hardware stores the violation PC address, failure reason code, and current GRAS state snapshot in a set of isolation registers, which can achieve state isolation.

[0112] The CFI failure handling in this application relies heavily on the exception-specific partition of GRAS. When the hardware detects a control flow violation, it redirects the control flow to a hardware-isolated stack space (i.e., the exception-specific partition) through an atomic privilege level switch. This design achieves physical isolation between the "protection mechanism" and the "protected object." Compared to the traditional approach of processors sharing a single return address stack, this application ensures that even in extreme cases such as ROP attacks or user stack pointer corruption, the kernel handler still has an uncontaminated hardware execution environment to perform complex policy decisions (such as terminating threads or recording snapshots). This is the hardware physical basis for implementing a "flexible security policy."

[0113] For the software processing section, the OS's CFI Failure Handler takes over control and reads information from the isolation registers. Based on the preset security policy, the Handler can perform one or more of the following operations:

[0114] Record the attack attempt and continue execution (downgrade).

[0115] Only clear or restore the affected threads / partitions.

[0116] Terminate the violating thread. This application enables high availability and configurability.

[0117] Among them, the thread that is terminated for violating the rules refers to the thread that is currently executing the JALR (return) instruction and has triggered a CFI check failure.

[0118] It's important to note that logging attack attempts and continuing execution is a "flexible security" design. In the security field, this is known as "graceful degradation" or "non-intrusive monitoring mode." In this mode, the CFI verification unit still operates: Logging: When verification fails, the hardware doesn't intercept the jump but secretly writes the violation information (such as the failed SCID, incorrect RA, expected tag vs. actual tag) to a set of write-only log registers or a specific memory audit area. Continuing execution: The processor allows the JALR instruction to update the PC using the popped address, and the program continues running as if no error occurred. Degradation: At this point, the system's security level has actually been "degraded" because the hardware no longer forcibly blocks potential risks but tolerates them in exchange for business continuity.

[0119] The downgrade here refers not only to the adjustment of the verification level, but more importantly to the system's operational state. It means that when the hardware detects an attack, the system is no longer in an "absolutely trusted state," but to ensure uninterrupted service (high availability), the OS decides to allow the task to continue running in a restricted environment instead of shutting down directly—similar to the "flexible security" design. The "record and continue execution" described in this application is not a simple software logic switch, but a "flexible defense state switching" supported by a hardware GRAS architecture. The mechanism's innovation lies in the fact that existing technologies, after verification failure, face a significant risk of kernel contamination due to the lack of partition isolation. This application utilizes a "dedicated anomaly partition" as a security foundation, ensuring that even if user-mode tasks are downgraded, the kernel's control flow remains strongly protected by the hardware partition. Dynamic decoupling of levels is achieved through "SCID binding" in the proposed level adjustment. The hardware can atomically switch from "active blocking" to "passive auditing" within nanoseconds based on the security attributes of different partitions. The recording of attack information is automatically performed by the hardware in the isolation register, preventing attackers from concealing their actions by tampering with the software log. The multi-level stack structure processor of this application can achieve "service degradation capability while maintaining hardware isolation".

[0120] This application reduces performance loss during context switching and provides highly serviceable error handling and system recovery capabilities when CFI verification fails, thereby enhancing availability and serviceability.

[0121] Figure 3 This is a flowchart of a multi-level return address stack management method for control flow integrity according to an embodiment of this application, as follows: Figure 3 As shown, the method includes the following steps:

[0122] S301, in response to the execution thread switch, parse and respond to the GRAS state management instructions, which include the first GRAS state management instruction and the second GRAS state management instruction.

[0123] The advanced state management and coordination mechanism (software and hardware interface) of this application is described below.

[0124] To achieve secure context switching and isolation, this application introduces a new RISC-V extension instruction, namely, an atomic GRAS state management instruction. The GRAS state management instruction includes a first GRAS state management instruction and a second GRAS state management instruction. In this application, the first GRAS state management instruction is CFI.GRAS.SAVE, and the second GRAS state management instruction is CFI.GRAS.LOAD.

[0125] The first GRAS state management instruction allows the OS / Hypervisor to atomically save the state of a specified GRAS partition (or the entire GRAS) to memory (such as a thread control block TCB), and the second GRAS state management instruction allows the state of a specified GRAS partition (or the entire GRAS) to be restored from memory.

[0126] There are three main triggering mechanisms for determining thread switching: 1. Explicit instruction triggering: When the hardware decoder parses the instructions CFI.GRAS.SAVE or CFI.GRAS.LOAD, the hardware is "100% certain" that a thread context switch is in progress. 2. Security Context ID (SCID) write operation triggering: The hardware monitors (snoops) the CSR register that specifically stores the SCID. 3. Privilege level switching (Trap / Exception) triggering: The processor's internal state machine monitors the Privilege Level signal. The GRAS management unit in this application can determine the occurrence of thread switching through the following event triggering mechanisms:

[0127] Instruction stream triggering: The processor pipeline uses specific state management instructions (such as CFI.GRAS.SAVE / CFI.GRAS.LOAD) as explicit synchronization signals for context transitions.

[0128] Configuration register trigger: The hardware monitors write update operations to the Security Context Identifier (SCID) register and uses them as the basis for determining security domain changes.

[0129] Privilege transition trigger: The hardware state machine tracks the privilege level switching signal and performs atomic pointer redirection between different privilege level partitions.

[0130] S302, in response to receiving the first GRAS state management instruction, freezes the state of the GRAS partition of the current thread in a hardware atomic operation manner, and encrypts and saves the state of the specified GRAS partition.

[0131] When switching threads, the OS calls CFI.GRAS.SAVE to freeze the GRAS state of the current thread.

[0132] S303, in response to receiving the second GRAS state management instruction, decrypts and restores the state of the next thread in the specified GRAS partition using a hardware atomic operation.

[0133] When switching threads, the OS calls CFI.GRAS.LOAD to restore the state of the next thread, eliminating the performance overhead of RAS warm-up while ensuring isolation.

[0134] It's important to note that in the GRAS architecture, "security context switching" and "isolation" are not instantaneous actions, but rather a continuous "state management" process. Isolation is established during instruction execution. Action: When the JAL (Call) instruction is executed, the hardware atomically acquires the current SCID and privilege level. Effect: The hardware pushes the return address onto the specific partition belonging to that context. Isolation manifested: At this point, the entry has been "marked." Even if other threads run subsequently, they cannot access this SCID-protected entry. Security context switching occurs between the "call" and "return." Switching is typically triggered by two situations: A. Hardware interrupt / exception (privilege level switch) – occurs immediately: Timing: Occurs at any clock cycle during function execution; Process: 1. The hardware detects an interrupt signal. 2. Immediate switch: The GRAS management unit senses the privilege level change (e.g., from U to M). 3. State freeze: The hardware automatically "snapshots" and isolates the stack pointer and SCID of the current user-mode partition to prevent the interrupt handler (even if the kernel is corrupted) from modifying it. 4. Activate the new partition: Enable the "abnormal dedicated partition". B. Operating system task switching (process / thread switching) – triggered by software instructions: Timing: When the OS decides to replace the current thread A with thread B; Process: 1. The OS executes a write CSR (Control and Status Register) instruction to update the SCID. 2. Switching occurs: This register write action is the physical instant of "context switching". 3. Logical isolation: As long as the SCID changes, the CFI verification unit will only see entries matching the new SCID when popping data later. Isolation verification: When the return instruction is executed. Timing: When the JALR (Return) instruction is executed; Action: The hardware attempts to pop the entry; Verification: It checks whether the SCID in the current register is equal to the SCID stored when it was pushed onto the stack. Conclusion: If illegal context tampering has occurred in the middle, the verification will fail. The security context isolation of this application is a hardware-controlled state throughout its entire lifecycle. Its key feature is that, during the execution interval between the call instruction and the return instruction, if a privilege level jump or task switch occurs in the system, the GRAS management unit will implement "in-situ freezing" and "logical extraction" of the current security domain state through hardware atomic operations. This isolation does not occur after instruction execution, but rather serves as a low-level, normalized protection mechanism, ensuring that even in complex concurrent execution environments, the return paths of different SCIDs remain in independent hardware planes that do not interfere with each other.

[0135] This application provides a hardware-aware context protection mechanism. In thread switching scenarios:

[0136] Phase 1 (Switchout): In response to the first state management instruction, the processor triggers the GRAS management unit to lock the currently active partition and starts the encrypted export function, atomically dumping the complete return stack state, including the SCID, to a protected memory area (such as TCB), thus achieving persistent storage of the current security domain state.

[0137] Phase Two (Entry): In response to the second state management instruction, the processor automatically locates the target thread's context buffer and atomically reloads the sealed state to the corresponding GRAS logical partition. During the reload process, the hardware synchronously performs integrity measurements to ensure that the loaded return path stream has not been unauthorized modified, thereby rebuilding the CFI defense boundary as soon as the task resumes execution.

[0138] Figure 4 This is a flowchart of a multi-level return address stack management method for control flow integrity according to an embodiment of this application, as follows: Figure 4 As shown, the method includes the following steps:

[0139] S401, in response to the GRAS partition meeting the preset migration conditions, migrates the atomic entries of the GRAS partition according to the creation time of the atomic entries of the GRAS partition.

[0140] The migration conditions are that the occupancy rate of the GRAS partition is greater than the preset occupancy rate threshold, or the recursive call depth limit is triggered.

[0141] In this application, GRAS employs at least a two-level hierarchical structure in its physical implementation to address capacity limitations and achieve performance optimization. In this embodiment, a two-level hierarchical structure is used as an example. GRAS employs a high-speed atomic verification layer L1-RAS and a capacity management layer L2-RAS for capacity expansion and overflow management in its physical implementation.

[0142] The L1-RAS is small, located on-core, and has extremely fast access speed, storing the return addresses of recent, frequently called functions. The L2-RAS is larger, may be located off-core, or consists of a protected cache / memory region, and can act as an overflow area for the L1-RAS or a second-level prediction mechanism to address the limited depth of the RAS. In response to L1-RAS GRAS partitions meeting preset migration conditions, atomic entries in the GRAS partition are migrated based on their creation time. That is, when the L1-RAS is full, the oldest entry (with complete address, CFI tag, and SCID) is automatically pushed out and into the L2-RAS. The L2-RAS effectively serves as an overflow area for the hardware-accelerated protected shadow stack, and its storage area is protected by additional authentication or encryption measures to ensure the addresses remain secure within a larger storage space.

[0143] The dynamic policy configuration of this application is described below.

[0144] In this application, the need for policy changes is determined based on software perception and decision-making. The OS kernel or hypervisor detects events that require changes to the security policy and determines the triggering requirement.

[0145] Taking performance-driven scenarios as an example, if the system load is extremely high and CPU resources are scarce, it is necessary to temporarily reduce the CFI check level of a low-sensitivity process to improve throughput.

[0146] Taking security drivers as an example, if the system detects potential attack activities (such as through CFI FailureHandler), it needs to immediately raise the CFI verification level of all user-space processes to the highest strength.

[0147] Furthermore, target identification is performed, and the software identifies the target GRAS partitions (e.g., user-space partitions Slices U1, U2) and target security context IDs (SCIDs) that require policy changes.

[0148] Furthermore, in the execution strategy selection, the software selects a new strategy configuration based on a preset strategy set (such as high-performance mode, full verification mode, and read-only mode).

[0149] Furthermore, software configuration CSRs (atomic writes) are executed, and the OS writes new configuration parameters to GRASCSRs.

[0150] Furthermore, to write the target CSR, the OS kernel writes new policy values ​​to predefined GRAS configuration CSRs using privileged instructions (such as CSRRW or CSRRWI).

[0151] The following is an example of CSR field configuration:

[0152] GRAS_CONFIG_REG[Partition_ID]: Specifies the target partition ID.

[0153] GRAS_CONFIG_FIELD.Enable_CFI_TAG: Set to 0 (disable) or 1 (enable) CFI Tag verification.

[0154] GRAS_CONFIG_FIELD.Failure_Action: Sets the behavior after a CFI failure (e.g., 00=Trap, 01=Discard & Clear Partition).

[0155] The write operation in this embodiment is atomic. The hardware design ensures that the GRAS unit is not in an uncertain state during CSR configuration changes, meaning the new policy takes effect immediately and completely.

[0156] Furthermore, the GRAS management unit (GRAS_MGMT) receives and applies new policies, enabling real-time hardware response and policy switching.

[0157] Optionally, the GRAS management unit continuously monitors or receives CSR configuration change signals via interruption to monitor CSR changes.

[0158] Optionally, the hardware immediately applies the new configuration parameters to the operating logic of the target GRAS partition, executing the policy application.

[0159] In some implementations, if the strategy is degraded (e.g., high-performance mode): the GRAS management unit instructs the CFI checksum and tag operation unit to skip the CFI tag verification step when processing JALR instructions for that partition in the future, thereby saving pipeline time.

[0160] In some implementations, if the strategy is an upgrade (such as full check mode): hardware recovery or mandatory requirement for a full atomic ternary check of the partition.

[0161] The processor core executes JAL / JALR instructions and implements a new strategy at runtime.

[0162] For JAL execution, when the processor executes the JAL instruction for the target partition, the GRAS unit decides whether to generate and push the CFI tag based on the currently effective policy (such as whether the CFI tag is enabled).

[0163] For JALR execution, when the processor executes the JALR instruction, the CFI verification unit executes the corresponding verification process according to the latest policy set for that partition in the CSR.

[0164] In this application, the hardware automatically generates and atomically stores tags within the pipeline. Whether overflow to L2-RAS is allowed is determined based on the security policy; under a high-security policy, overflow can be configured to be disallowed. If CFI tags are enabled, they can be further categorized based on the "strictness of verification," i.e., CFI verification levels.

[0165] This application binds the CSR register to the GRAS logical partition, enabling the processor to automatically determine, within a single instruction execution cycle, whether a tag needs to be generated for the JAL of that specific partition, and / or whether the partition has the permission to overflow to L2-RAS, based on the current SCID.

[0166] This refined management of "allocating security resources on demand" is key to achieving a balance between "high performance" and "high security".

[0167] Optionally, CFI verification levels can be divided into: Basic level: CFI tag not enabled, only RA matching, to prevent non-malicious errors; Enhanced level (high security): CFI tag enabled, Tag+RA+SCID, to prevent control flow hijacking attacks such as ROP / JOP; Extreme level (highest security): CFI tag enabled, Tag+ is prohibited from overflowing into memory, to prevent physical attacks with memory probing capabilities.

[0168] The key hardware parameters and resource configurations of this application are described below.

[0169] To illustrate the structure and capacity of GRAS entries, a single GRAS entry is designed as a composite data structure, and the components of a GRAS entry include:

[0170] Return address (RA / PC): 64-bit or 32-bit (depending on the RISC-V architecture).

[0171] CFI verification tag: preferably an opaque tag of 12 to 32 bits (such as PAC / MAC), whose bit width is configured by the security policy CSR to ensure verification strength.

[0172] Security Context ID (SCID): Preferably 8 to 16 bits, used to mark the thread ID, privilege level, and security domain when the call is made.

[0173] To illustrate the capacity of the GRAS hierarchy, L1-RAS is designed with a small capacity (8 to 32 entries) to achieve single-cycle access and atomic verification; L2-RAS is designed with a large capacity (64 to 256 entries) to address L1 overflow and improve prediction hit rate. Capacity parameters can be configured or queried via a dedicated CSR.

[0174] The hardware key management and secure storage mechanism of this application is described below.

[0175] For example, the encryption key used to generate and verify CFI Tag (PAC / MAC) is stored in a secure, isolated hardware unit inside the core (such as a dedicated, non-software-readable CSR or one-time programmable memory OTP).

[0176] In a hardware security design (GRAS architecture), their relationship is as follows: The hardware key K (such as the Root Key / MasterKey) is the root key stored in a "secure isolation hardware unit" (such as a Fuse, OTP, or PUF) within the kernel. The CFI Tag encryption key (such as the Session Key / Derived Key) is the key actually used by the CFI verification unit for computation. To illustrate its generation, for security reasons, the hardware typically does not directly use the root key K, but rather through a key operation: KeyTag = KDF(K, SCID). This ensures that different security contexts (SCIDs) use different derived keys. Even if an attacker cracks the user-mode tag, they cannot deduce the kernel-mode tag.

[0177] To illustrate RAS state isolation, when CFI verification fails, the isolation register group used to save the offending address and GRAS state snapshot is designed to ensure that after a trap occurs, attackers cannot modify or clear these states through conventional methods, providing reliable raw data for subsequent forensic analysis by the software handler.

[0178] This application significantly reduces the runtime overhead of the shadow stack through hierarchical and hardware-co-verification, and improves the reliability and coverage of hardware control flow integrity (CFI), thereby enhancing CFI performance and reliability. This application can provide scalable and licensable RISC-V hardware-level security baseline capabilities to meet the dynamic configuration needs of applications with different security sensitivities, offering architectural flexibility.

[0179] Figure 5 This is a structural block diagram of a multi-level return address stack management system for control flow integrity according to an embodiment of this disclosure, as follows: Figure 5As shown, the multi-level return address stack management system for control flow integrity includes a GRAS module, a compiler module, a configuration management module, and a hardware encryption module, among which:

[0180] The GRAS module includes multiple independent GRAS partitions, which are used to isolate and differentiate the return addresses of different GRAS partitions.

[0181] The hardware encryption module is used to store hardware keys and perform encryption and decryption operations for generating and verifying CFI tags based on the hardware keys.

[0182] The compiler module is used to insert metadata at sensitive call points during compilation, or to identify call instructions that require the use of the GRAS module.

[0183] The configuration management module is used to configure the policy management parameters of the GRAS module and manage the status of the GRAS partition during context switching.

[0184] The following describes the overall architecture and composition of the multi-level return address stack management system for control flow integrity according to an embodiment of this application.

[0185] In the hardware architecture extensions (RISC-V Core Modifications), this application introduces a Graded Return Address Stack (GRAS), a multi-dimensional layered hardware mechanism designed to simultaneously address the issues of security isolation, performance bottlenecks, and capacity limitations of return addresses. The hierarchical structure of GRAS includes two main dimensions: logical security partitioning and physical performance layering.

[0186] In some implementations, for vertically hierarchical logical security partitions, the GRAS structure is logically divided into at least N independent security partitions to achieve strict isolation of return addresses for different security domains and differentiated policy management. A description of the logical security partitions is shown in Table 1.

[0187] Table 1

[0188]

[0189] In some implementations, for horizontally graded physical performance hierarchies (L1 / L2), GRAS employs at least two levels of hierarchical structure (L1-RAS and L2-RAS) in its physical implementation to address capacity limitations and achieve performance optimization.

[0190] The L1-RAS (High-Speed ​​Atomic Check Layer) is small, located on-core, and has extremely fast access speed. It can store the return addresses of recent, frequently called functions. The L1-RAS is the main body for performing atomic ternary checks (address + CFI Tag + SCID). The generation and verification logic of the CFI Tag are tightly integrated into the push and pop paths of the L1-RAS, ensuring that the verification latency is hidden in the instruction pipeline.

[0191] The L2-RAS (Capacity Expansion and Overflow Management Layer) is relatively large and may be located off-core or consist of protected cache / memory regions. It can act as an overflow area for the L1-RAS or a second-level prediction mechanism to address the issue of limited RAS depth. When the L1-RAS is full, the oldest entry (containing the address, CFI tag, and SCID) is automatically pushed out and into the L2-RAS.

[0192] L2-RAS effectively serves as an overflow area for hardware-accelerated protected shadow stacks, with its storage area protected by additional authentication or encryption measures to ensure that addresses remain secure within a larger storage space.

[0193] The compiler module is used to insert metadata at sensitive call points during compilation, guide the generation of hardware CFI tags, or identify calls that require the use of GRAS.

[0194] The OS / Hypervisor module is used to configure GRAS security policies and partition mappings via CSR, and to manage GRAS state during context switching.

[0195] like Figure 6 As shown, in this application, the GRAS partition includes a physical / logical "hard partition": a privileged partition ( Figure 6 L1 partition in Figure 6 The user mode (U), supervisor mode (S), machine mode (M), and exception-specific partition shown in the diagram represent the first layer of isolation (privileged isolation) in GRAS. This isolation is a hardware-level logical isolation. It ensures that if an attacker experiences an overflow or control flow hijacking in user mode (U), they cannot interfere with the return stack of supervisor mode (S) or machine mode (M) via JALR return instructions.

[0196] Furthermore, GRAS partitioning also includes "soft isolation" in terms of identifiers: to avoid wasting hardware resources, the isolation between threads and processes in the thread / process partition is achieved through SCIDs. The isolation is a logical isolation based on context labels. All user-mode threads may share the same "user-mode partition (U)," but each entry stores a different SCID, thereby achieving isolation. When thread A returns, even if it can access the user-mode partition, if it attempts to pop the return address belonging to thread B, the hardware will find that the SCID does not match, thus triggering a verification failure.

[0197] Furthermore, GRAS partitioning also includes functional "policy partitions." Policy customization and exception-specific partitions represent different approaches to handling various security requirements: Exception-specific partitions: These are special hard partitions specifically designed for handling traps / interrupts. When the system enters an exception handler, the hardware automatically switches to this partition, ensuring that the control flow of the exception handling logic is not interfered with by the interrupted program. Policy-customized partitions are not physical partitions but rather management attributes. For example, a "forced full verification policy" (highest security) can be customized for the "machine-mode partition." A "verify return address only policy" (highest performance) can be customized for a specific "user-mode process." This "customization" is achieved through dynamic configuration of the aforementioned physical partitions via the GRAS management unit and CSRs.

[0198] In summary, partitioning can be described as a collaboration across three dimensions: The first dimension is Privilege-Level Partitioning: The hardware divides the L1-RAS into four physical / logical partitions: U, S, M, and a dedicated exception handling partition, achieving spatial isolation between different privilege levels. The second dimension is Context-Level Isolation: Within the same privilege level partition, SCIDs are used to identify the return address entries of different threads / processes, achieving identity isolation between tasks. The third dimension is Policy-Based Management: CSRs are used to configure differentiated security strengths (such as verification algorithm strength and actions after failure) for the above different partitions or specific SCID contexts, enabling on-demand customization of defense strategies. Figure 6 In this context, Overflow / Fill can represent the overflow of entries, and Shadow StackMemory represents the shadow stack memory.

[0199] like Figure 5 As shown, in some implementations, the GRAS module is also used for:

[0200] In response to receiving a call instruction, the target GRAS partition is determined from multiple hierarchical return address stack GRAS partitions by querying a mapping table based on the target security context identifier (SCID) of the currently executing thread. The mapping table includes the mapping relationship between security context identifiers and GRAS partitions.

[0201] Obtain the return address and hardware key, and generate a Control Flow Integrity Tag (CFI Tag) based on the return address, hardware key, and target SCID.

[0202] The return address, CFI tag, and target SCID are pushed as atomic entries into the target GRAS partition to isolate and manage the return address.

[0203] In some implementations, the GRAS module is also used for:

[0204] In response to a processor privilege level switch or an exception signal, the operation pointer is redirected from the current GRAS partition to the target GRAS partition corresponding to the privilege level or the exception.

[0205] In response to receiving a return command, the prediction entry is popped from the target GRAS partition.

[0206] Based on the CFI check level corresponding to the target GRAS partition, address verification, tag verification, and context matching are performed atomically.

[0207] If the verification passes, a return transition is executed. Alternatively, if the verification fails, a CFI verification failure exception is triggered.

[0208] In some implementations, the GRAS module further includes an atomic verification layer and a capacity management layer, wherein:

[0209] The atomic verification layer is used to store atomic entries in different GRAS partitions.

[0210] The capacity management layer stores atomic entries for GRAS partitions.

[0211] The GRAS module is also used to migrate atomic entries from the atomic verification layer to the capacity management layer when the GRAS partition meets the preset migration conditions.

[0212] The migration conditions are that the occupancy rate of the GRAS partition is greater than the preset occupancy rate threshold, or the recursive call depth limit is triggered.

[0213] In some implementations, the compiler module is also used to support the generation of CFI tags. The configuration management module is also used to dynamically configure and manage mapping tables.

[0214] The following section provides further examples illustrating the structure and implementation of the hierarchical return address stack (GRAS).

[0215] For the physical layered implementation of GRAS (L1 / L2 structure), in this embodiment, GRAS adopts at least two physical layered structures: L1-RAS and L2-RAS, in order to resolve the contradiction between performance and capacity.

[0216] The L1-RAS is located at the tightly coupled point of the processor core pipeline and is preferably a high-speed, multi-port hardware FIFO queue used to store the latest return address entries. It supports single-cycle or extremely low-latency access to ensure that CFI atomicity checks can be completed during the branch prediction phase without introducing additional pipeline bubbles. Its capacity is relatively small, typically set to 8 to 32 entries, to guarantee the highest hit rate and access speed.

[0217] The L2-RAS, located outside the core or in a large on-chip memory area, serves as a capacity supplement and overflow target for the L1-RAS. It can be implemented using large blocks of static random access memory (SRAM) or protected cache blocks (CacheLine). When a logical partition in the L1-RAS overflows, the oldest valid entry is automatically pushed into the L2-RAS along with its complete CFI_Tag and SCID. The L2-RAS region (especially its overflow area in memory) is protected by additional bus encryption or address authentication mechanisms, acting as a hardware-accelerated, protected shadow stack overflow area to ensure safe overflow.

[0218] The following describes the composite structure of GRAS entries. Each entry in a GRAS memory cell is a composite structure that ensures all necessary security and context information is included when pushed, including: Return Address (RA): stores the address of the instruction following the invoked instruction; CFI Verification Tag (CFI_Tag): stores the Pointer Authentication Code (PAC / MAC) generated by the CFI verification unit based on the RA and hardware key K; and Security Context ID (SCID): stores the Privilege Level (PRV), Thread ID (TID), and optional Security Domain Identifier at the time of the call.

[0219] The following describes the implementation of GRAS's logical security partitioning. L1-RAS and L2-RAS physically share resources, but are logically divided into multiple isolated partitions by the GRAS management unit to achieve differentiated policy management. The logical partition categories include at least: user-mode partitions, supervisor-mode partitions, machine-mode partitions, and exception-specific partitions. Each logical partition is managed through a set of independent stack pointers (SPs) and stack depth counters.

[0220] The GRAS management unit has a built-in SCID mapping lookup table (configured via CSR) which is used to quickly locate the corresponding logical partition based on the currently executing SCID when executing JAL or JALR, thus realizing SCID mapping.

[0221] Each logical partition is bound to a set of configuration bits, which are programmed through the CSR to control the behavior of the partition, such as whether to enable CFI_Tag verification, whether to allow overflow to L2-RAS, etc., to achieve dynamic policy configuration.

[0222] This application achieves a balance between high-performance access and fine-grained security isolation through a design that combines physical layering and logical partitioning.

[0223] It should be noted that the different partitions in this application have logical differences, which are directly determined by the privileged attributes of the RISC-V architecture and represent the bottom line of hardware hardcoding: the read and write permissions of the user-mode partition (U-ModePartition) are only accessible in U-Mode. The supervisor-mode / machine-mode partition (S / M-ModePartition) has privileged constraints, and U-Mode instructions cannot access these two partitions (hardware circuit-level isolation). The triggering logic of the exception partition (ExceptionPartition) is different; it is not driven by ordinary JAL instructions, but by the hardware Trap (exception / interrupt) mechanism. When an exception occurs, the hardware automatically switches to the dedicated stack pointer of this partition, achieving an independent stack top. Even if the interrupted U-Mode program stack has crashed, the exception partition can still ensure the control flow safety of the interrupt handler.

[0224] Furthermore, the logical differences between partitions based on dynamic strategies are illustrated using the verification strength logic as an example: M-Mode partitions force ternary verification. U-Mode partitions can be configured to verify only RA (Real-Area Memory) for maximum performance. Regarding error handling logic, exception partitions immediately perform a hard reset upon verification failure (to prevent the entire kernel from being hijacked). User-mode partitions, upon verification failure, only "log the attack and continue (degrade)" to ensure uninterrupted service. As for storage policy logic, S-Mode partitions allow overflow to L2-RAS but prohibit overflow to external DDR memory. U-Mode partitions allow full-path overflow to support infinitely deep recursive calls. Finally, regarding key update logic, high-security partitions logically trigger dynamic rolling key updates after each return operation. Normal partitions use keys with a fixed cycle.

[0225] The following example illustrates the interaction of the call / return process in the instruction pipeline.

[0226] This embodiment describes how the call instruction (JAL) and return instruction (JALR) interact with the GRAS structure and CFI check unit in the processor pipeline to achieve high performance and atomicity verification. Assuming the processor adopts the classic five-stage pipeline model (IF, ID, EX, MEM, WB), we can mainly focus on the interaction of the ID (decode), EX (execute), and MEM (memory access) stages.

[0227] Optionally, in the push-in process of the call instruction (JAL), the JAL instruction in the pipeline is mainly responsible for atomically pushing the return address and security metadata, as shown in Table 2.

[0228] Table 2

[0229]

[0230] Optionally, in the atomicity verification and prediction process of the return instruction (JALR), the processing of the JALR instruction is the core of the entire invention. It integrates branch prediction and CFI verification, as shown in Table 3.

[0231] Table 3

[0232]

[0233] Where RApred represents the return address prediction, Tagpred represents the tag prediction, SCIDcall represents the expected SCID, and SCIDcurrent represents the current SCID.

[0234] The implementation of the CFI.GRAS.SAVE instruction is described below. The CFI.GRAS.SAVE instruction is designed as a RISC-V extended instruction (preferably I-Type or R-Type) to achieve atomic saving of the GRAS state. The instruction format includes an opcode, source register rs1, and destination register rd (optional) or an immediate value. Operands define registers rs1 and rs2 (optional). Register rs1 stores the base address of the target GRAS partition state saving region (i.e., the Thread Control Block (TCB) region in memory). Register rs2 (optional) stores the GRAS partition ID or SCID to be saved.

[0235] The CFI.GRAS.SAVE instruction triggers the GRAS snap-in to atomically write the current state of the specified GRAS partition (including all valid entries, stack pointers, and configurations for L1-RAS and L2-RAS) to the memory region pointed to by rs1.

[0236] The atomicity of instruction execution and the hardware coordination mechanism are described below. When the CFI.GRAS.SAVE instruction enters the execution phase, the GRAS management unit immediately sends a signal to the processor core's instruction fetch and issue unit, temporarily blocking all subsequent JAL / JALR instructions from entering the pipeline, thereby freezing the state of the GRAS unit and achieving pipeline blocking and freezing. During the state preservation period, the GRAS unit has exclusive access to the L1-RAS and L2-RAS memory areas, preventing any other unit (including the branch predictor) from attempting push or pop operations, thus achieving exclusive access. This application guarantees the atomicity of the CFI.GRAS.SAVE execution process, thereby eliminating security vulnerabilities.

[0237] The state data migration mechanism of this application is described below. The state data storage in this application is highly efficient to avoid prolonged pipeline blockage.

[0238] Furthermore, the GRAS management unit packages the partition states to be saved into one or more atomic data blocks. Each data block includes: all valid entries of the L1-RAS partition (including RA, CFI_Tag, SCID), valid entries of the L2-RAS partition and its pointer state, and the hardware pointers to the top and bottom of the stack for that partition. This achieves packet encapsulation.

[0239] Furthermore, data transfer is preferably accelerated via the processor's internal fast bus or DMA (Direct Memory Access) mechanism, rather than through conventional load / store instruction loops. This enables hardware-accelerated transfer, ensuring high throughput and low latency for memory write operations.

[0240] Optionally, the format written to the target memory is a predefined, compressed binary format that fully matches the format required by the corresponding CFI.GRAS.LOAD instruction to ensure that the data can be recovered quickly and accurately.

[0241] The following describes the execution completion and pipeline recovery process of this application. After the state is saved, the GRAS management unit performs the following operations:

[0242] Send a completion signal: Send a signal to the processor core to indicate that the state saving has been successfully completed.

[0243] Unblock: Restore the normal operation of the instruction fetch and issue unit, allowing subsequent instructions to enter the pipeline.

[0244] Status flag: Optionally, the partition is marked as currently in a "saved / frozen" state in the internal register of the GRAS management unit to prevent subsequent operations from accidentally modifying the saved state.

[0245] Through the above mechanism, the CFI.GRAS.SAVE instruction achieves safe and atomic isolation of the GRAS state with minimal pipeline overhead, greatly improving the performance and security of context switching.

[0246] The core state machine of the GRAS management unit of this application is described below. This embodiment describes the core working state machine of the GRAS management unit, which is used to control how the GRAS unit processes call / return operations according to the processor state and configuration policy, as shown in Table 4.

[0247] Table 4

[0248]

[0249] Furthermore, the state machine drives state transitions by receiving events from the CSR, pipeline, and exception unit, as shown in Table 5.

[0250] Table 5

[0251]

[0252] This application achieves physical-level "write-only, no-erase". A dedicated hardware write channel exists between the isolation register group and the CFI verification unit, optimizing the hardware structure. Atomic-level "snapshot capture" implements synchronous logic for "capture upon violation", optimizing timing logic. "Hard isolation" of the security domain, with the linkage between the isolation register and the GRAS partition pointer, optimizes partition management logic.

[0253] In this application, write permissions to the audit register are bound only to the hardware CFI verification logic, not the software instruction set, thus eliminating the possibility of privileged software tampering with evidence at the source and achieving physical immutability. This application solves the "scene contamination" problem in secure forensics by using microarchitecture-level signal linkage to complete a state snapshot the instant a violation is detected in the pipeline, achieving zero-latency capture of the execution state. This application utilizes isolation registers and partition freezing technology to construct an forensics plane completely isolated from the execution environment, ensuring the robustness of the defense mechanism itself and achieving deep decoupling between anomaly handling and the violation state.

[0254] This application aims to propose a hierarchical return address stack (RAS) and shadow stack management mechanism for control flow integrity (CFI). Through multi-level isolation, dynamic control, trusted verification, and context switching awareness of return addresses, it overcomes the contradiction between performance and security.

[0255] Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure.

[0256] like Figure 7 As shown, the electronic device 700 includes:

[0257] The memory 701 and the processor 702 are connected by a bus 703. The memory 701 stores a computer program. When the processor 702 executes the program, it implements the multi-level return address stack management method for control flow integrity according to the present disclosure.

[0258] Bus 703 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0259] Electronic device 700 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 700, including volatile and non-volatile media, removable and non-removable media.

[0260] Memory 701 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 704 and / or cache memory 705. Electronic device 700 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 706 can be used to read and write non-removable, non-volatile magnetic media (… Figure 7 Not shown; usually referred to as a "hard drive"). Although Figure 7 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 703 via one or more data media interfaces. Memory 701 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this disclosure.

[0261] A program / utility 708 having a set (at least one) of program modules 707 may be stored, for example, in memory 701. Such program modules 707 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 707 typically perform the functions and / or methods described in the embodiments of this disclosure.

[0262] Electronic device 700 can also communicate with one or more external devices 709 (e.g., keyboard, pointing device, display 711, etc.), and with one or more devices that enable a user to interact with the electronic device 700, and / or with any device that enables the electronic device 700 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through input / output (I / O) interface 712. Furthermore, electronic device 700 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) through network adapter 713. Figure 7 As shown, network adapter 713 communicates with other modules of electronic device 700 via bus 703. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with electronic device 700, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0263] The processor 702 executes various functional applications and data processing by running programs stored in the memory 701.

[0264] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the multi-level return address stack management method for control flow integrity in this disclosure embodiment, and will not be repeated here.

[0265] To implement the above embodiments, this disclosure also proposes a computer-readable storage medium.

[0266] When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the multi-level return address stack management method oriented towards control flow integrity, as described above. Optionally, the computer-readable storage medium can be ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0267] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0268] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A multi-level return address stack management method for control flow integrity, characterized in that, include: In response to receiving a call instruction, the target GRAS partition is determined from multiple hierarchical return address stack GRAS partitions by querying a mapping table based on the target security context identifier (SCID) of the currently executing thread. The mapping table includes the mapping relationship between the security context identifier and the GRAS partition. Obtain the return address and hardware key, and generate a Control Flow Integrity Tag (CFI Tag) based on the return address, the hardware key, and the target SCID; The return address, the CFI Tag, and the target SCID are pushed into the target GRAS partition as atomic entries to isolate and manage the return address; This also includes: In response to receiving a return instruction, a prediction entry is popped from the target GRAS partition; Obtain the register address corresponding to the return instruction; Based on the CFI verification level corresponding to the target GRAS partition, the consistency verification, tag verification, and context matching of the register calculated address and the return address in the prediction entry are performed atomically within the same pipeline cycle to obtain the verification results; In response to the verification result indicating that the verification passed, the return instruction is executed, and the control flow is transferred to the target address.

2. The method according to claim 1, characterized in that, in: The multiple GRAS partitions include at least machine-mode partitions, supervisory-mode partitions, and user-mode partitions, which respectively isolate and manage the return addresses of firmware, kernel, and applications; and / or, The atomic entry also includes ciphertext encrypted with the return address according to the hardware key; and / or, The mapping table is dynamically configured by configuration registers or privilege level instructions.

3. The method according to claim 1, characterized in that, The GRAS partition also includes an exception handling partition. After obtaining the verification result, the process further includes: In response to the verification result indicating that the verification failed, a Control Flow Integrity (CFI) verification failure exception is triggered, and exception handling is performed in the exception handling partition.

4. The method according to claim 3, characterized in that, The exception handling process performed in the exception handling partition includes: The returned address is identified as the violation address, and the violation address, the reason for the verification failure, and the current GRAS status are stored as violation entries in the isolation register; Perform at least one of the following operations according to the preset security policy: restrict access to registers; log attack attempts corresponding to the call instruction; continue execution of the thread after reducing the Control Flow Integrity (CFI) verification level; terminate the execution thread corresponding to the violation entry; clear or restore the affected execution thread or the GRAS partition.

5. The method according to claim 1 or 2, characterized in that, Also includes: In response to a thread switch, the GRAS state management instructions are parsed and responded to, including a first GRAS state management instruction and a second GRAS state management instruction. In response to receiving the first GRAS state management instruction, the state of the GRAS partition of the current thread is frozen in a hardware atomic operation manner, and the state of the specified GRAS partition is encrypted and saved. In response to receiving a second GRAS state management instruction, the state of the next thread in the specified GRAS partition is decrypted and restored using a hardware atomic operation.

6. The method according to any one of claims 1-4, characterized in that, Also includes: In response to the GRAS partition meeting preset migration conditions, the atomic entries of the GRAS partition are migrated according to the creation time of the atomic entries of the GRAS partition; The migration condition is that the occupancy rate of the GRAS partition is greater than a preset occupancy rate threshold, or the recursive call depth limit is triggered.

7. A multi-level return address stack management system for control flow integrity, characterized in that, It includes a GRAS module, a compiler module, a configuration management module, and a hardware encryption module, among which: The GRAS module includes multiple independent GRAS partitions, which are used to isolate and manage the return addresses of different GRAS partitions using differentiated strategies. The hardware encryption module is used to store hardware keys and perform CFI Tag generation and verification encryption / decryption operations based on the hardware keys. The compiler module is used to insert metadata at sensitive call points during compilation, or to identify call instructions that require the use of the GRAS module. The configuration management module is used to configure the policy management parameters of the GRAS module and manage the status of the GRAS partition during context switching. The GRAS module is further configured to: In response to receiving a call instruction, the target GRAS partition is determined from multiple hierarchical return address stack GRAS partitions by querying a mapping table based on the target security context identifier (SCID) of the currently executing thread. The mapping table includes the mapping relationship between the security context identifier and the GRAS partition. Obtain the return address and hardware key, and generate a Control Flow Integrity Tag (CFI Tag) based on the return address, the hardware key, and the target SCID; The return address, the CFI Tag, and the target SCID are pushed into the target GRAS partition as atomic entries to isolate and manage the return address; The GRAS module is further configured to: In response to a processor privilege level switch or an exception signal, the operation pointer is redirected from the current GRAS partition to the target GRAS partition corresponding to the privilege level or the exception. In response to receiving a return instruction, a prediction entry is popped from the target GRAS partition; Based on the CFI verification level corresponding to the target GRAS partition, address verification, tag verification, and context matching are performed atomically. If the verification passes, a return transfer is executed; or, if the verification fails, a CFI verification failure exception is triggered.

8. The multi-level return address stack management system for control flow integrity according to claim 7, characterized in that, The GRAS module further includes an atomic verification layer and a capacity management layer, wherein: The atomic verification layer is used to store atomic entries in different GRAS partitions; The capacity management layer is used to store atomic entries for the GRAS partition; The GRAS module is further configured to migrate the atomic entries from the atomic verification layer to the capacity management layer when the GRAS partition in the atomic verification layer meets the preset migration conditions, based on the creation time of the atomic entries of the GRAS partition. The migration condition is that the occupancy rate of the GRAS partition is greater than a preset occupancy rate threshold, or the recursive call depth limit is triggered.

9. The multi-level return address stack management system for control flow integrity according to claim 7, characterized in that, in: The compiler module is also used to support the generation of CFI Tags; The configuration management module is also used for dynamically configuring and managing mapping tables.

10. An electronic device, characterized in that, include: processor; Memory for storing the executable instructions of the processor; The processor is configured to execute the instructions to implement the method as described in any one of claims 1-6.

11. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the method as described in any one of claims 1-6.

Images