A processor branch prediction attack vulnerability formal verification method
Formal verification of the processor branch predictor using model checking technology solves the problem that existing technologies cannot fully verify the security of branch predictors, discovers potential attack paths, and improves the security of branch predictors and the universality of verification.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING UNIV OF POSTS & TELECOMM
- Filing Date
- 2023-04-14
- Publication Date
- 2026-04-17
AI Technical Summary
Existing technologies lack formal verification methods for processor branch predictors, making it impossible to fully and accurately verify whether they can defend against branch prediction attacks and to discover potential security vulnerabilities.
By employing model detection technology, a security attribute and behavior model of branch prediction attacks is established. The branch predictor is designed and modeled as a state machine, and its compliance with security specifications is checked through formal verification methods to discover potential attack paths.
It enables automated verification of processor branch predictors, is applicable to a variety of hardware and software designs, discovers new attack methods, and improves security and the universality of verification.
Smart Images
Figure CN116415256B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer security technology, and in particular to a formal verification method for processor branch prediction attack vulnerabilities based on model detection technology. Background Technology
[0002] One of the key design goals of modern processors is high performance. To achieve this goal, researchers have proposed numerous performance optimization mechanisms and techniques. Branch prediction is one of them, and its purpose is to solve the pipeline blocking problem caused by branch instructions.
[0003] Branch prediction is implemented by introducing a branch predictor component into the processor hardware. This component can predict the jump direction and jump address of a branch instruction, thereby obtaining the address of the next instruction in advance. If the prediction is correct, the pipeline can execute normally, avoiding blocking; if the prediction is incorrect, the processor needs to roll back the pipeline to the correct instruction address and re-execute.
[0004] By exploiting the time window created by processor rollback when a branch predictor makes a prediction error, attackers can execute malicious instructions transiently, leading to information leakage. The Spectre attack, exposed by Google in 2018, exploited this vulnerability, posing a significant threat to various processor models from numerous manufacturers. Therefore, the performance of branch predictors is crucial for computer security.
[0005] Since its inception, branch prediction technology has seen the development of numerous excellent branch predictors, demonstrating superior performance in terms of prediction accuracy, speed, and power consumption. However, the security of these branch predictors remains unassessed. While researchers have proposed various defenses against branch prediction attacks such as Spectre, their adequacy still needs verification. Future branch predictor designs should consider security performance, but currently, methods for verifying security performance are lacking.
[0006] To address the aforementioned issues, existing work has verified the security of the executable program by modeling the microinstruction lifecycle and comparing observation results, but it does not consider security from the perspective of the branch predictor design itself. This work can only identify security vulnerabilities from the perspective of software programs and cannot provide a comprehensive and accurate verification of the security performance of hardware branch predictors.
[0007] Currently, academia and industry lack a method to formally verify a specific branch predictor design, confirm its ability to defend against any branch prediction attack, and identify all possible branch prediction attacks. Therefore, it is essential to design a verification method that can comprehensively analyze processor branch prediction attacks. Summary of the Invention
[0008] The purpose of this invention is to provide a formal verification method for processor branch prediction attack vulnerabilities based on model detection technology. This method can perform formal verification on a specific branch predictor design, confirm whether it can defend against any branch prediction attack, and identify all possible branch prediction attacks, thus filling a technological gap.
[0009] To achieve the above objectives, the present invention provides the following technical solution:
[0010] This invention provides a formal verification method for processor branch prediction attack vulnerabilities, comprising the following steps:
[0011] S1. Establish the security attributes violated by branch prediction attacks, wherein the security attributes describe the security specifications that a secure branch predictor design should follow;
[0012] S2. Establish a branch prediction behavior model, describing the branch prediction attack as a combination of a series of abstract branch operations; the branch operation is a quintuple consisting of operator, operation type, operation address, jump direction and jump address, which is an abstract representation of a certain branch instruction;
[0013] S3. The branch predictor is designed and modeled to accept branch prediction behavior instructions, and to design different branch prediction model state machines according to different input instructions, output prediction results, check security specifications, and convert branch prediction attacks into path specifications on the state machine; the path specification of the branch prediction attack is: there is a memory access operation sequence that can reach a certain state node, and in this state, the branch predictor model does not meet the branch prediction security specification; the path specification of the secure branch predictor design is: there is no memory access operation sequence that can reach a certain state node, and in this state, the branch predictor model does not meet the branch prediction security specification.
[0014] S4. Perform model verification on the state machine of the branch predictor design to determine whether it has a branch prediction attack vulnerability.
[0015] Furthermore, the security specification for branch prediction attacks in step S1 is as follows: when two users with different security levels share the same branch predictor, the two users cannot generate more additional information flow than sequential execution during prediction execution, that is, the prediction between the two threads is non-interfering.
[0016] Furthermore, in step S2, the operator is either an attacker or a victim.
[0017] Furthermore, the operation type in step S2 is a classification type of branch instructions, which includes: unconditional direct branch instructions, unconditional indirect branch instructions, conditional direct branch instructions, and conditional indirect branch instructions.
[0018] Furthermore, unconditional indirection instructions include the call instruction for function calls and the return instruction for returning.
[0019] Furthermore, the operation address in step S2 is a set of addresses that can be operated on by both the attacker and the victim, which are divided into three categories: the first category is any address adr; the second category is alias, which represents an address that is consistent with adr after hashing; and the third category is dfr, which represents an address that is completely different from adr and alias.
[0020] Furthermore, in step S2, the jump direction is divided into three types: jump, no jump, and invalid. Jump means that the execution flow jumps to the target address for execution, no jump means that the execution flow executes the next instruction sequentially, and invalid means that this field is invalid.
[0021] Furthermore, the jump address in step S2 is divided into four categories: normal address, which is any ordinary address; malicious address, which is a piece of malicious code when executed in the actual processor; private address, which will leak private information when executed in the actual processor; and invalid, which means that this field is invalid.
[0022] Further, step S3 models the branch predictor as a finite state machine that makes a series of state transitions from an initial state under a specific branch operation sequence. This includes modeling the entire branch predictor for verification and modeling individual predictor components for verification. The entire branch predictor includes multiple individual predictor components, including but not limited to BTB, PHT, BHB, RSB, and LP.
[0023] Furthermore, the method for model verification in step S4 is as follows: check whether a path that satisfies a certain condition will appear on a certain model. If it is proven that such a path cannot be generated under a given state transition, then the verification is successful; otherwise, find a counterexample path.
[0024] Compared with the prior art, the beneficial effects of the present invention are as follows:
[0025] (1) The present invention proposes a formal verification method for processor branch prediction attack vulnerabilities. It uses a processor branch predictor for modeling, and the modeling method is scalable and can model different abstract granularities according to actual needs. This method is applicable to various hardware or software branch predictor designs. Only simple rule descriptions need to be written to efficiently and automatically verify various branch predictor designs. It is applicable to different processor and instruction set platforms.
[0026] (2) The present invention proposes a formal verification method for processor branch prediction attack vulnerabilities, which puts forward a security specification violated by branch prediction attacks. This method is applicable not only to branch prediction attack vulnerability detection but also to the design reference of secure branch predictors. This specification is not limited to a specific branch predictor design but is universally applicable to various branch predictor designs. Verification only requires writing security specification check statements according to the specific design. Furthermore, the security level can be finely divided according to actual needs to adapt to more security requirements.
[0027] (3) This application applies six branch prediction designs with practical significance, analyzes and formally verifies the corresponding branch prediction designs, and realizes a systematic analysis of cache vulnerabilities. Attached Figure Description
[0028] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly described below. Obviously, the drawings described below are only some embodiments recorded in this invention, and those skilled in the art can obtain other drawings based on these drawings.
[0029] Figure 1 A flowchart is provided for a formal verification method of processor branch prediction attack vulnerability in an embodiment of the present invention.
[0030] Figure 2 The diagram shows the overall architecture of the verification general branch predictor model provided in this embodiment of the invention.
[0031] Figure 3 This is a diagram illustrating the internal processing logic of the prediction submodule provided in an embodiment of the present invention. Detailed Implementation
[0032] To better understand this technical solution, the method of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0033] The following describes a formal verification method for processor branch prediction attack vulnerabilities according to the present invention, such as... Figure 1 As shown, it includes the following steps:
[0034] S1. Establish the security attributes violated by branch prediction attacks, wherein the security attributes describe the security specifications that a secure branch predictor design should follow.
[0035] Branch prediction attacks involve attackers maliciously poisoning the branch prediction predictor with partial knowledge of its mechanism. When the victim executes the program, this can lead to transient execution vulnerabilities, where the branch predictor predicts based on the attacker's poisoned information, causing the victim to jump to the wrong direction or address to execute malicious code, resulting in information leakage. Alternatively, it can cause side-channel or covert-channel vulnerabilities, where attackers analyze the branch prediction's initial state, the prediction result for the current branch, and the state of the branch predictor after the prediction ends, thus also leading to information leakage.
[0036] The security specification for branch prediction attacks is: when two users with different security levels share the same branch predictor, the two users cannot generate more additional information flow than sequential execution during predictive execution; that is, the prediction between the two threads must be non-interfering. The formal language description is:
[0037]
[0038]
[0039] in, This represents the branch sequence in the case of sequential execution. This represents the branch sequence in the case of prediction execution. Indicates prediction without interference. Any operation within, Indicates a high security level. Indicates a low security level. The security level is , The security level is L. This indicates that they share the same branch predictor. This means that it is equivalent to, Indicates branch prediction, Indicates the level of security classification. This indicates that it does not exist. This indicates a prediction error. Indicates the direction of information flow.
[0040] S2. Establish a branch prediction behavior model, describing branch prediction attacks as a combination of a series of abstract branch operations.
[0041] The branch operation is a quintuple consisting of operator, operation type, operation address, jump direction, and jump address, which is an abstract representation of a branch instruction.
[0042] In this context, the operator can be either an attacker or a victim.
[0043] Operation type is a classification of branch instructions, which includes: conditional direct branch instructions, unconditional direct branch instructions, conditional direct branch instructions, and unconditional indirect branch instructions.
[0044] Unconditional indirection instructions include the `call` instruction for function calls and the `return` instruction for returning.
[0045] Because the `call` instruction used for function calls and the `return` instruction used for returns affect multiple predictors, these two types of instructions are classified separately. Unconditional direct branch instructions do not use a branch predictor, so these instructions are ignored. In summary, the operation types include: unconditional direct (UD), unconditional indirect (UI) with `CALL` and `RET`, conditional direct (CD), and conditional indirect (CI).
[0046] The operable addresses are the set of addresses that both attackers and victims can manipulate, divided into three categories: The first category is arbitrary addresses (adr); the other two categories are determined by their relationship with adr. The second category is alias, which represents an address that, after hashing (to solve the problem of aliases in predictor table entries), is identical to adr; the third category is dfr, which represents an address that is completely different from adr and alias.
[0047] There are three types of jump direction: taken, not taken, and invalid. Take means that the execution flow jumps to the target address for execution. Not taken means that the execution flow executes the next instruction sequentially. Invalid means that this field is invalid. Unconditional indirect branch operation (UD) uses this type because such operation must jump.
[0048] Jump addresses are divided into four categories: normal addresses (any ordinary address); gadget addresses (malicious code executed in the actual processor); secret addresses (private information leaked when executed in the actual processor); and invalid addresses (invalid field, used by conditional direct branch (CD) operations because the address of this type of operation can be directly calculated without the need for a branch predictor).
[0049] S3. The branch predictor is designed and modeled to accept branch prediction behavior instructions, and to design different branch prediction model state machines according to different input instructions, output prediction results, check security specifications, and convert branch prediction attacks into path specifications on the state machine; the path specification of the branch prediction attack is: there is a memory access operation sequence that can reach a certain state node, and in this state, the branch predictor model does not meet the branch prediction security specification; the path specification of the secure branch predictor design is: there is no memory access operation sequence that can reach a certain state node, and in this state, the branch predictor model does not meet the branch prediction security specification.
[0050] The branch predictor is designed and modeled as a finite state machine that performs a series of state transitions from an initial state under a specific branch operation sequence. This includes modeling the entire branch predictor for verification and modeling individual predictive components for verification. In practice, verification can be performed by modeling either the entire branch predictor or individual predictive components. Ultimately, the model must achieve both predictive behavior and safety compliance behavior.
[0051] In modern processors, the entire branch predictor generally refers to the BPU (branch predictor unit), which includes multiple individual prediction components, including but not limited to BTB (branch target buffer), PHT (pattern history table), BHB (branch history buffer), RSB (return stack buffer), and LP (loop predictor).
[0052] The BTB (branch target buffer) is responsible for predicting jump addresses, and its internal implementation is similar to a cache. The PHT (pattern history table) is responsible for predicting jump directions, and its internal implementation is a bimodal predictor. The BHB (branch history buffer) stores branch history, and its purpose is to work with the PHT to improve prediction accuracy. The RSB (return stack buffer) is responsible for predicting the return address of the RET instruction, and its internal implementation is a stack structure. The LP (loop predictor) is specifically responsible for predicting the loop body.
[0053] Modeling of branch predictors as follows Figure 2As shown, it consists of three modules: an operation distribution module, a prediction submodule, and a safety specification check module. The path specification of the branch predictor model is: there is no branch operation sequence that can reach a specific state node; in this state, the safety specification is violated. In this example, a general branch predictor design is verified. This design mainly includes four prediction submodules: BHB, PHT, BTB, and RSB. Its internal processing logic is as follows: Figure 3 As shown, the left side represents the composition and values of the internal state variables of the prediction submodule, while the right side represents the internal processing logic. Specifically, BHB stores branch history and handles the hash calculation of instruction addresses. In this example, it directly outputs the conversion result without showing the conversion process, thus reducing the state space. PHT is responsible for predicting the jump direction, matching the instruction address with the index tag before prediction. If a match is found, the current prediction is based on the actual jump result of the previous branch operation. BTB is responsible for predicting the jump address, matching the instruction address with the index tag before prediction. If a match is found, the current prediction is based on the actual jump result of the previous branch operation. RSB is responsible for predicting the address of RET operations. CALL operations push the operation address onto the RSB stack, and when a RET operation arrives, the RSB pops the address from the stack to provide the prediction. For all submodules, the security level of attacker branch operations is low, while the security level of victim branch operations is high.
[0054] Branch instructions are modeled as branch operations, consisting of a quintuple of operator, operation type, operation address, jump direction, and jump address. There are two types of operators: attacker and victim. There are five operation types: UI, CD, CI, CALL, and RET. There are three types of operation addresses: adr, alisa, and dfr. There are three types of jump directions: inv, taken, and not_taken. There are four types of jump addresses: inv, normal, gadget, and secret.
[0055] After performing the above steps, a branch prediction model state machine is formed, in which the branch predictor model accepts branch operations and makes corresponding changes. Specifically, as follows: Figure 2 The operation distribution module distributes branch operations. CD type branch operations are distributed to PHT, and CI type branch operations are distributed to BHB. After address translation in BHB, they are distributed to PHT and BTB. In addition, BTB also accepts UI and CALL type branch operations. RSB accepts CALL and RET type branch operations. Each submodule ultimately provides a prediction result and checks compliance with security specifications at each state.
[0056] S4. Perform model verification on the state machine of the branch predictor design to determine whether it has a branch prediction attack vulnerability.
[0057] The branch predictor model and security specifications are written as model code for the model validation tool. Model validation is an algorithm that checks whether a specific model meets a certain path specification. In the verification experiments of this application, the Kripkre structure and CTL language are used to describe the security caching model and security specifications, respectively, but other model and specification description methods can also be used.
[0058] The method for model verification is as follows: check whether a path that satisfies a certain condition can appear on a certain model. If it is proven that such a path cannot be generated under a given state transition, then the verification is successful; otherwise, find a counterexample path.
[0059] Model validation can be performed using a model validation tool to verify the established cached model code. Any model validation tool that supports CTL validation can be used. In the validation experiments of this application, the NuSMV model validation tool is used. After execution, it may proceed to one of the following two sub-steps:
[0060] 1) Validation successful. Output: The branch predictor design is safe.
[0061] 2) Verification failed. The branch predictor design has a vulnerability, and further analysis of the cause of the vulnerability is needed.
[0062] The following are verification experiments conducted on the prediction submodules Bimodal, Gshare, TAGE, BTB, RSB, and the General branch predictor design. Table 1 shows the results of verifying these six branch prediction designs using the methods provided in this application. A total of 507 two-step attacks, 39,620 three-step attacks, 36 four-step attacks, and 40 five-step attacks were found in these six designs. In the verification of the General branch predictor model, a novel attack method was discovered that exploits the Branch History Buffer (BHB) to leak branch history information. This is unprecedented in previous attacks. Furthermore, a method using BHB to control the PHT and BTB entry indexes was also discovered.
[0063] Table 1 shows the results of the validation of the method of the present invention on six branch prediction designs.
[0064] Model Name 2 steps 3 steps 4 steps 5 steps Bimodal 2 8 24 16 Gshare 16 0 0 0 TAGE 274 20784 0 0 BTB 12 0 0 0 RSB 3 12 12 24 General 200 18828 0 0
[0065] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. However, these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. A processor branch prediction attack vulnerability formal verification method, characterized in that, Includes the following steps: S1. Establish the security attributes violated by branch prediction attacks, which describe the security specifications that a secure branch predictor design should follow. S2. Establish a branch prediction behavior model, describing the branch prediction attack as a combination of a series of abstract branch operations; the branch operation is a quintuple consisting of operator, operation type, operation address, jump direction and jump address, which is an abstract representation of a certain branch instruction; S3. The branch predictor is designed and modeled to accept branch prediction behavior instructions, and to design different branch prediction model state machines according to different input instructions, output prediction results, check security specifications, and convert branch prediction attacks into path specifications on the state machine; the path specification of the branch prediction attack is: there is a memory access operation sequence that can reach a certain state node, and in this state, the branch predictor model does not meet the branch prediction security specification; the path specification of the secure branch predictor design is: there is no memory access operation sequence that can reach a certain state node, and in this state, the branch predictor model does not meet the branch prediction security specification. S4. Perform model verification on the state machine of the branch predictor design to determine whether it has a branch prediction attack vulnerability. The model verification method is to check whether a path that satisfies a certain condition appears on a certain model. If it is proven that such a path cannot be generated under a given state transition, the verification is successful. Otherwise, find a counterexample path. If the verification is successful, output that the branch predictor design is safe. If the verification fails, the branch predictor design has a vulnerability.
2. The processor branch prediction attack vulnerability formalization verification method according to claim 1, characterized in that, The security specification for branch prediction attacks in step S1 is as follows: when two users with different security levels share the same branch predictor, the two users cannot generate more additional information flow than sequential execution during predictive execution, that is, the two threads should not interfere with each other during prediction.
3. The processor branch prediction attack vulnerability formalization verification method of claim 1, wherein, In step S2, the operator is either an attacker or a victim.
4. The processor branch prediction attack vulnerability formalization verification method according to claim 1, wherein, In step S2, the operation type is a classification of branch instructions, which includes: unconditional direct branch instructions, unconditional indirect branch instructions, conditional direct branch instructions, and conditional indirect branch instructions.
5. The processor branch prediction attack vulnerability formalization verification method according to claim 1, wherein, Unconditional indirection instructions include the `call` instruction for function calls and the `return` instruction for returning.
6. The processor branch prediction attack vulnerability formalization verification method according to claim 1, wherein, In step S2, the operation address is a set of addresses that can be operated on by both the attacker and the victim, which are divided into three categories: the first category is any address adr; the second category is alias, which represents an address that is consistent with adr after hashing; and the third category is dfr, which represents an address that is completely different from adr and alias.
7. The processor branch prediction attack vulnerability formalization verification method according to claim 1, wherein, In step S2, the jump direction is divided into three types: jump, no jump, and invalid. Jump means that the execution flow jumps to the target address for execution, no jump means that the execution flow executes the next instruction sequentially, and invalid means that this field is invalid.
8. The processor branch prediction attack vulnerability formalization verification method according to claim 1, wherein, In step S2, the jump address is divided into four categories: normal address, which is any ordinary address; malicious address, which is a piece of malicious code when executed in the actual processor; private address, which will leak private information when executed in the actual processor; and invalid, which means that this field is invalid.
9. The formal verification method for processor branch prediction attack vulnerabilities according to claim 1, characterized in that, Step S3 designs and models the branch predictor as a finite state machine that makes a series of state transitions from an initial state under a specific branch operation sequence. This includes modeling the entire branch predictor for verification and modeling individual predictor components for verification. The entire branch predictor includes multiple individual predictor components, including but not limited to BTB, PHT, BHB, RSB, and LP.