Fault Attacks on Access Control in Processors: Threat, Formal Analysis and Microarchitectural Mitigation

Process isolation is a key component of the security architecture in any hardware/software system. However, even when implemented correctly and comprehensively at the software (SW) level, process isolation may be compromised by weaknesses of the hardware (HW). Therefore, at the HW level, an exhaustive verification is desirable which provides the needed formal guarantees ensuring the confidentiality and integrity of the microarchitecture. The situation is further exacerbated if the attacker is able to inject faults, a threat requiring additional attention in formal security analysis. In this paper, we consider a threat model where the attacker is able to inject faults and, at the same time, execute user-level programs. We show that this poses a severe security threat even in systems which have been hardened against fault attacks for specific, security-critical system software. For protection against this threat, we present an exhaustive formal verification methodology that provides security guarantees for access control in processors, and demonstrate how such guarantees are sustained in the presence of fault injection. Guaranteeing correct and robust access control is crucial since it is the basis for process isolation in hardware. The proposed approach implicitly models all possible single and multiple bit flips as well as all stuck-at faults. We leverage the results of our formal analysis to augment the system with protection mechanisms that guarantee security w.r.t. the considered threat model. At the example of several open source RISC-V processors, we demonstrate both the scalability of our formal analysis and the efficiency of the generated defenses.


I. INTRODUCTION
In light of the critical dependence of modern civilization on information technology, security of computer systems against malicious interference is an ever-growing concern. While the implementation of security features in software (SW) is a long-standing vibrant field of research, there has recently been a surge of interest in hardware (HW) security. This The associate editor coordinating the review of this manuscript and approving it for publication was Yang Liu .
interest is held not only by computer architects but also by members of the security community. Attesting to this trend, Mitre's Common Weakness Enumeration database (CWE) introduced a new category specifically for HW vulnerabilities [1].
One particular type of threat to HW security are fault attacks [2]. Attackers capable of injecting faults into a system may cause severe security breaches. The importance of such attacks on cryptographic algorithms was reported already in the 1990s [3]. Recent works show the threat of fault attacks on Fault attacks on HW/SW systems executing security-critical software are already considered in a large body of literature, as pointed to above. In the related threat model intricate knowledge of the security-critical code allows an attacker to mount successful attacks. Typical defenses against such fault attacks include SW-level protection [19] like employment of error-detecting and -correcting codes, checksums in data paths or signature-based control flow checking [20], possibly with HW support [21]. These measures are particularly effective for application-specific computers providing security services, such as crypto-cores, attestation processors or chip card systems.
Nowadays, however, it is becoming commonplace in many computing domains that some security-critical code is executed back-to-back with general application software from ''app stores'' or other untrusted third-party SW repositories, all on the same general-purpose computing platform. Prominent examples for HW/SW systems of this kind are today's smartphones or the infotainment systems built into automobiles. For the security of these computing systems, it is crucial that mechanisms are in place guaranteeing that user-level processes are isolated from each other and from the operating system (OS) kernel. For this purpose, at the HW level, process isolation is implemented by the core's access control infrastructure which is configured and controlled by privileged software. Functional correctness of this HW infrastructure and its configuration through the firmware is essential for security. However, with the possibility of fault injection, such HW/SW systems are targets for attacks that are not fully covered by the existing threat models.
While, in principle, the threat to the data and control flow of the victim's (privileged) system software can be protected using the known and proven measures mentioned above, this is not possible in a straightforward manner for the (user-level) application SW. This SW is controlled by the attacker and unknown at design time. Fault injection that manipulates the microarchitectural HW implementation of the access control infrastructure during user-level execution may compromise process isolation and allow a malicious user-level process to interfere with the rest of the system. Such threats must not be underestimated, as demonstrated by [22]. Attackers can easily deploy fabricated SW to the targeted system through regular distribution channels, for example using an app store [23] or through automotive infotainment systems [24]. At the same time, techniques for injecting faults are becoming increasingly powerful, allowing for attacks with high spatial resolution, for example by laser [25] or electromagnetic fault injection [26], as well as attacks that can inject faults remotely, without physical access to the victim [15]. As a simple example, consider the following scenario: Let the platform provide two execution privilege levels and an access control mechanism separating the data and code space of kernel-level SW from untrusted users. Let the configuration of the access control mechanism be encoded in a system register of the processor; this is a valid assumption for a broad spectrum of architectures. If the attacker is able to inject faults into the system, it could take as little as flipping a single bit to destroy the barrier between the user and kernel memory space, allowing an attacker-controlled user-level SW to freely corrupt the kernel memory. Any hardening and builtin fault-resiliency at the level of kernel SW does not have any effect on this attack scenario, which further exacerbates the threat. While this is a rather obvious case, we demonstrate in Sec. V of this paper that also more subtle cases, as results of less obvious fault injections and fault propagations, can have similarly severe effects.

B. THREAT MODEL
We intend to close this important security gap by complementing the existing threat models with an additional one that specifically targets security of access control and privilege escalation at the microarchitectural HW level. As motivated above, access control and secure privilege escalation constitute process isolation in HW.
Threat model (1). We consider a single-threaded processor supporting privileged execution modes and process isolation using HW security primitives configured by firmware. We abstract the implemented execution privileges into two modes: unprivileged and privileged. All privileged code and data is stored in protected registers R p and protected memory locations M p that are inaccessible by unprivileged processes. The attacker controls an unprivileged process and attempts to break process isolation in order to modify protected code or data outside its own execution environment.
We divide the objective of process isolation into two targets: confidentiality and integrity of the system. Confidentiality means preventing an attacker from reading protected data that is stored in M p . Integrity means preventing an attacker from modifying or influencing R p and M p , the part of the system that is specified as protected, or illegally entering privileged mode. We present a formal representation and an exhaustive verification methodology for confidentiality in Sec. II, and for integrity in Sec. III, under the considered threat model. □ Our assumption of a platform with only two privilege levels and a single thread of execution simplifies the following discussion but is not a limitation of our approach. The properties and methods presented in this paper can accommodate multiple privilege levels and can be extended to multiple threads. Furthermore, while this paper focuses on cores, our methods can be scaled to entire Systems-on-Chip (SoCs) in a similar way as [27] demonstrates for confidentiality.
Extended threat model (2). In addition to running a user-level program on the victim system, we assume the attacker to be able to inject faults into the victim's HW. In particular, we consider all single and multiple bit flips and stuck-at faults as well as their propagation throughout the design. We consider faults injected into the combinational logic as well as into the state-holding elements of the processor core. The proposed fault analysis in Sec. IV allows us to exhaustively model an arbitrary number of faults in any possible fault location at arbitrary time points of process execution.
□ Security violations found under the plain threat model (1) are caused by design bugs at the HW level. Security violations that are found under the extended threat model (2) but not under the plain one require the attacker to inject faults.

C. RELATED WORK
As pointed out by [28], pre-silicon security verification, especially when targeting exhaustive coverage in complex HW systems, remains challenging. Even advanced commercial security architectures, such as AMD SEV which provides process isolation by memory encryption, has been shown to be vulnerable to code injection attacks due to missing integrity protection mechanisms [29].
In [30] a property-driven verification approach for hardware security using information flow properties is presented. The work of [31] extends this work to create specific information flow tracking models. However, a priori knowledge about suspicious paths is needed.
The work on taint propagation for HW security verification is pioneered by [32] and extended by [33] for different security objectives in HW. In [34] a framework for taint properties in both the security and the safety domain is provided. However, all these works require knowledge about securitycritical paths, which is a limitation when attempting to evaluate security against unknown vulnerabilities. This limitation is addressed in [35] with the UPEC approach, which provides formal guarantees for confidentiality, but does not consider integrity.
Hyperflow is a secure-by-construction processor architecture [36] covering a wide spectrum of confidentiality and integrity objectives. However, these security guarantees come with significant costs regarding design flows, system requirements and hardware efficiency. Related lines of research make use of security-driven languages, such as SecVerilog [37]. However, the designer needs to manually label the design with security types, which is not a trivial task for complex designs.
Trusted execution environments (TEEs) provide a framework for secure process execution. The work of [38] presents a hardware root-of-trust architecture for edge devices. In [39] a hardware-software co-design for TEEs is proposed that protects against certain classes of side-channel attacks, such as cache timing attacks. The work of [40] extends to a more complex memory hierarchy allowing arbitration. Keystone [41] presents a customizable framework for TEEs based on RISC-V. In [42] a multi-core platform with a dedicated secure TEE processor is introduced. However, no verification techniques are available yet for TEEs that could provide a formal guarantee of their security.
The threat posed by fault attacks is not addressed by any of the aforementioned works. A substantial amount of research has been conducted on protecting HW systems from faults with the goal to provide safety. However, as shown in [43], protection mechanisms developed to guarantee the safety of a system do not necessarily protect against security attacks. While protection against random events is certainly important, an intelligent fault attacker can circumvent such protection through system observation. Therefore, the results of formal approaches, such as [44], targeting the reliability analysis of systems do not directly translate into the field of security.
Rowhammer is a powerful and prominent fault attack proposed by [45]. Repeated read accesses in DRAM can change the information stored in neighboring cells. There are several approaches to detect and circumvent Rowhammer attacks, as described in [46]. Reference [47] discusses a lightweight protection mechanism based on monitoring operations that result in memory accesses. However, these countermeasures do not protect against fault injection into other parts of the circuit, for example, by laser fault injection, undervolting or overclocking.
Several works analyze the effects of faults for the execution of security-critical applications. In [48] the effect of faults in registers that are not program-visible are analyzed for two microcontroller designs. In [49] the execution of secure code on a RISC-V processor is analyzed for vulnerabilities with an emphasis on faults in such hidden registers. The work of [50] analyzes different microcontroller designs with fault injection campaigns by emulation. In [9], faults target privileged SW execution during the configuration of the physical memory protection unit in RISC-V processors. In [51] security-critical circuit locations are identified based on a property-driven assessment. However, these approaches are not exhaustive, and only verify these effects non-formally for the execution of selected privileged code snippets.
There are dedicated countermeasures for protection of cipher implementations. Several protection schemes are evaluated in [52] which showed that many of them do not perform better than straightforward solutions like hardware duplication or repetition of code. The work of [53] proposes a new microarchitecture to handle faults bypassing double modular redundancy structures. In [54] a framework for identification of vulnerabilities in a crypto implementation based VOLUME 11, 2023 on known vulnerable operations in the cipher is presented. In [55] and [56] fault-protected HW implementations of cryptographic algorithms are evaluated on the gate level. By contrast to our work, [55] is based on simulation. [56] transforms the gate-level netlist into a BDD-based model and performs a formal security analysis. All these works consider fault attacks on HW implementations of cryptographic algorithms. Our work, as explained in Sec. I-A, addresses a different security problem, namely fault attacks on access control in general-purpose processors.
Other works focus on the correct execution of arbitrary SW in the presence of fault attacks. Reference [20] deploys signature analysis for securing the control flow. In [57] encryption and authentication codes are used to prevent incorrect instruction executions and invalid control flow decisions. The work of [58] discusses extensions to a RISC-V processor pipeline for protection of the control flow and the execution of conditional branches. In [59] the protection of the datapath via residue codes is discussed. Another approach applies instruction block signature verification by grouping consecutive instructions and employing HW extensions for signature generation [21]. In [19], the SWIFT methodology is introduced, which utilizes instruction-level redundancy and clever control flow checking to detect transient faults. While the particular problems addressed are of importance when considering security-critical or privileged SW, these works do not deal with the threat of fault attacks that can corrupt the functionality of access control at the HW level. The protection mechanisms of [60] are concerned with the page table walker in the presence of faults for processors with virtual memory management. However, the approach can give security guarantees only for up to four random bitflips. In [61] a HW extension for fault detection that triggers SW countermeasures is proposed, which, however, considers only confidentiality objectives.
A method for analyzing the vulnerability of an FSM to fault attacks on the gate level is proposed in [62]. The work of [63] introduces an FSM architecture that circumvents such vulnerabilities. A set of protected FSM states is specified by the designer. The FSM is analyzed for illegal accessibility of the protected states by fault injection. In this analysis, only faults injected by setup time violations are considered. In [64] a protection mechanism of FSM states also against precise fault injection via laser is introduced. In [65] FSMs are hardened by specific encoding of control and state variables. In contrast to our work, security violations infecting both control and data in the entire processor are not considered in these approaches.
The work of [66] introduces the SNYFI framework that supports pre-silicon verification of synthesized netlists w.r.t. fault resiliency. The tool analyzes the effects of user-defined fault models on the input-output relation of specified subcircuits of a design. However, exhaustive fault experiments w.r.t. all fault models can only be conducted when the circuit state space is small.

D. CONTRIBUTIONS
In this paper, we propose a new method for detecting and defending against the attack scenarios described in Sections I-A and I-B. The method is based on property checking at the Register Transfer Level (RTL) and can provide security guarantees. We exhaustively evaluate the security of RTL designs of processors, w.r.t. formally well-defined security objectives derived from our threat models in Sec. I-B.
Our method approaches the analysis of fault attacks from an entirely new direction. Instead of explicitly modeling injected faults individually and studying their effects on a system, we seek to answer the following question: How can a malicious fault injection invalidate formal guarantees obtained from the formal verification of the considered security objectives? By answering this question we represent large sets of single and multiple faults implicitly in terms of their potential to affect certain components of our proof procedures. Our analysis precisely identifies all parts of the microarchitecture into which a direct fault injection immediately compromises security and which must be protected by traditional countermeasures like error-correcting codes (ECC) or Triple-Modular Redundancy (TMR). We refer to this part of the HW as security-critical infrastructure and demonstrate in Sec. V-C that, for our threat model, it comprises only a small part of the microarchitecture. For the rest of the system, where faults can only indirectly affect the formal guarantees, i.e., through fault propagation to securitycritical functionalities, we leverage information obtained from the proof procedure to create countermeasures by generating low-overhead monitors.
The proposed method, to the best of our knowledge, is the first formal security analysis targeting fault attacks at the RTL. This work, unlike previous works in this field such as [55] and [56], extends the scope from encryption engines to general-purpose processors. Furthermore, this work complements the literature as it targets a new and relevant threat model that is not covered by the previous fault protection works, such as [19], [20], [21], [57], [58], and [59].
Our contributions are, in particular: • For the considered threat model (Sec. I-B), we provide a set of properties to exhaustively detect integrity violations in processor cores (Sec. III). This includes an innovative technique to evaluate the threat of illegal privilege escalation. Together with an existing technique for proving confidentiality [27], the proposed property set forms an exhaustive processor verification framework for access control at the RTL.
• Our verification method is not restricted to a particular program but proves security w.r.t. the considered threat model for any attacker-controlled, user-level software running on the system. • We provide an exhaustive formal method to detect all possible injected faults and fault propagations at the RTL that can lead to a violation of the formulated confidentiality and integrity requirements (Secs. IV-A, IV-B and IV-C). To this end, we propose a novel technique for implicitly modeling faults based on the invariants used by the proof procedure.
• We propose a light-weight and effective protection mechanism for the resiliency of access control mechanisms against fault attacks, which leverages information obtained by our fault analysis and, thus, defends against all types of faults (e.g., single-and mutliple bit transient and permanent faults) visible at the RTL (Sec. IV-D).
We have implemented such protection mechanisms for several RISC-V processors and published them opensource [67].
• The method was applied successfully to several RISC-V processor cores of different size and complexity (Ibex [68], RI5CY [69] and Ariane [70]), showing the high relevance of the considered threat model and the effectiveness and efficiency of the proposed analysis and countermeasures (Sec. V). As a byproduct of our formal analysis, we discovered a bug in the Ariane processor that compromised secure privilege escalation. The bug was confirmed and fixed by the development team.

II. BACKGROUND
In order to give security guarantees for the HW, exhaustive formal methods are needed that can guarantee detection of all possible vulnerabilities in scope. This includes methods for detecting confidentiality violations, e.g., as in [71], as well as novel methods for detecting violations of a processor's integrity, as presented in Sec. III. These methods form the foundation of our fault analysis in Sec. IV.

A. CONFIDENTIALITY IN HW SYSTEMS
The notion of a hyperproperty [72] can be used to specify confidentiality in processor cores at the implementation level (RTL) [35]. In this paper we build upon this approach. We formulate properties that exclusively consider the microarchitecture and allow for arbitrary SW to be run on the processor. We model for all (primary) input variables and Y = (y 0 , y 1 , . . .) for all (primary) output variables of the processor. Using this model, we can describe the HW in a clock-cycle-accurate way by requiring exactly one state transition per clock cycle. A trace t = s 0 s 1 . . . is a finite or infinite sequence of states. Two consecutive states s i and s i+1 in a trace t of an FSM M satisfy the relationship δ(s i , j) = s i+1 , where s i , s i+1 ∈ S and j ∈ I . Furthermore, we use the following notation for ''slicing'' a trace, i.e., denoting individual states or subtraces in t: At any point in time, the processor runs in either privileged or unprivileged mode. This allows us to identify any given state s i as either privileged or unprivileged. A trace consisting of solely privileged or unprivileged states is denoted by t p or t u , respectively. For our threat model it is important to identify the very subset of microarchitectural state variables that are programvisible; we call them architectural. The attacker process is able to observe time points and value changes of architectural state variables, only. We introduce the function architectural(t) which returns, for a trace t, a trace containing valuations only to architectural state variables.
Confidentiality requires that certain secret information cannot be leaked to unprivileged processes. In the following, M p denotes a protected memory location storing secret data. The particular content of the secret memory location at time With these notations, confidentiality can be defined as a hyperproperty: Def. 1 checks whether any unprivileged program running on the HW is independent of the value of the secret, i.e., it executes uniquely w.r.t. the secret. As further described in [35], the confidentiality requirement can be formulated as a hyperproperty for RTL hardware that also covers Spectre [73] attacks.

B. INTERVAL PROPERTY CHECKING
For exhaustively verifying properties, such as in Def. 1, on real processor designs, we use Interval Property Checking (IPC) [74], [75]. IPC is a formal HW verification method for Register Transfer Level designs. Interval properties are formulated over finite time windows and describe relationships between RTL signals at the different time points in the interval using propositional logic formulas. An interval property has the general structure of an implication A ⇒ C from an antecedent A(V , X ) which is a conjunction of assumptions, to a consequent C(V , Y ) which is a conjunction of commitments. An individual assumption a i (V , X ) is usually expressed in terms of state variables V and input variables X ; and an individual commitment c j (V , Y ) is expressed in terms of state variables V and output variables Y . The assumptions and commitments may consider variables for different time VOLUME 11, 2023 Similarly as in SAT-based Bounded Model Checking (BMC) [76], the computational model is given by a finite unrolling of the design's FSM into l time frames with l denoting the length of the finite time window covered by the property.
The boxes in Fig. 1 represent propositional logic formulas expressed in RTL variables as given by the arrows. A formal SAT checker is then used to verify the property by searching for a counterexample, i.e., an assignment to the V @t, V @t + 1, V @t + 2, V @t + 3 X @t, X @t + 1, Y @t + 1 and Y @t + 2 fulfilling the assumption and violating the commitment. If none exist, then the property holds. Note that V @t + i = δ(V @t + i − 1, X @t + i − 1) for i > 0. The state vector V @t + 0 = V @t is unconstrained and represents a symbolic starting state s for the property. In a counterexample computed by the SAT checker, the valuations of the state vectors V @t + 0, V @t + 1, V @t + 2, . . . , represent a state sequence (s, s ′ , s ′′ , s ′′′ , . . .) beginning with the starting state s.
An important difference between a BMC and an IPC property is that BMC starts at a concrete reset state (or some other reachable starting state) and thus produces a ''bounded'' proof, i.e., the proof is valid only in a finite time window starting from the specified state. In IPC, s is symbolic and may represent any starting state. If an IPC property holds, the described piece of behavior is valid globally, i.e., the property holds at any time during the global system operation. On the other hand, a computed counterexample may be false if the starting state s is unreachable from reset.
In practice, false counterexamples are less of a problem than one might expect, as a property often holds in the unreachable part of the state space as well. If a false counterexample is produced, however, it must be excluded in later checks by strengthening the property with an invariant. Invariants are assertions that hold in the design, thus defining an over-approximation of the reachable state set. They are standard practice in IPC and are either generated automatically by commercial tools [74] or inserted by the human user after inspecting counterexamples. All added invariants are formally verified to hold on the design, such that the generality of the IPC proofs is not restricted in any way. Sec. V discusses some examples for invariants. While providing invariants is more of a technicality when using IPCbased property checking and has no effect on the validity of a property, they play an important role in our fault modeling, to be introduced in Sec. IV-B.
IPC invariants are formulated by adding them as logic expressions to the antecedent of an interval property P = (A, C, l). We classify the assumptions A into invariants I = The constraints B thus comprise the original assumptions, before strengthening the property with invariants; they constrain the scenario for which the commitments C must hold.

C. IPC IN ACTION: UPEC
Confidentiality in processors, as defined in Def. 1, can be formulated as an interval property. This approach is called Unique Program Execution Checking (UPEC) [35], [71]. UPEC was originally developed for detecting transient execution side channels, but it covers also other confidentiality violations in processors. Similar to the hyperproperty of Def. 1, UPEC is formulated as a 2-safety property taking two execution traces into account. The two traces are modeled by unrolling two instances of the processor in one model, including two instances of microarchitectural state variables and transition logic. Fig. 2 presents the UPEC property.
The two instances of the system (denoted with indices 1 and 2) are assumed to start with the same microarchitectural state, given as a set of valuations to all state-holding elements in the design. The only exceptions are the storage locations of secret or confidential data. With protection_enabled, a security mechanism protecting the secret is assumed to be in place and the macro unprivileged_mode assumes the current process to be executing in user mode. The property verifies that, after l clock cycles, both instances arrive at the same architectural state. If this can be verified then the secret data cannot influence the program-visible state and, thus, an attacker running a user-level program cannot obtain any information regarding the secret within a time window of length l. It is possible that the symbolic starting state used in the IPC proof may produce false counterexamples which may require the use of invariants, as indicated in Fig. 2. The time window l must be chosen large enough such that all possible propagations of the secret through the system can be detected. While, theoretically, l must be as large as the sequential depth of the FSM's state space, a practical divide-and-conquer methodology together with inductive proofs allows for proof instances that each cover only a few clock cycles [35].

III. INTEGRITY PROPERTIES A. INTEGRITY AS A TRACE PROPERTY
In the following, we present a verification method for integrity of processor cores at the RTL. As described in Sec. II, our threat model consists of an unprivileged attacker process, running on a single-threaded processor core and attempting to interfere with a victim process (i.e., compromising the integrity of the victim's execution environment in terms of process code and data). While the processor is running in unprivileged mode, some parts of the system are protected by dedicated HW or FW mechanisms such that they are not accessible to the unprivileged user. We refer to these parts of the system as protected assets in the remainder of the paper. As already introduced in Sec. I-B, we denote the set of all protected registers by R p and the set of all protected memory locations by M p . The composition of the sets R p and M p for a given processor are well defined by the ISA specification. We refer to the specific register or memory contents at a clock cycle i by R p [i] and M p [i], respectively.
When several processes are run on a single-threaded processor, only a single process can be actually executing at a given time. Switching between processes requires saving the execution context of the suspended process and restoring the context of the resumed process. These context switches are performed on a higher privilege level and are initiated by vertical traps or interrupts. Upon closer inspection of the transition between an unprivileged and a privileged part of a program, we can observe that upon privilege level escalation, the processor always enters certain pre-defined routines. These entry points can be characterized by a set of states S a , which include all authorized or legal states after raising the privilege level. In most architectures, these states are defined by an interrupt vector table, addresses in system registers and exception codes.
This allows us to formulate the following trace property for integrity in processor cores. It formalizes the integrity requirement that any processor must fulfill in order to protect against the threat model of Sec. I-B. The ISU property asserts that an unprivileged process must not ever be able to modify protected assets, i.e., register or memory contents, and privileged mode can only be entered through an authorized state s a ∈ S a . Note that when entering s a , the privileged process executes code and uses data within its own execution environment specified (configured) by R p and M p . Since the ISU property specifies these registers and memory locations to be unmodifiable by any unprivileged process, a user-level attacker cannot influence the privileged execution. Furthermore, for realistic microarchitectures, the assumption is valid that the pipeline is flushed upon privilege escalation and, therefore, no unprivileged process can leave a footprint that maliciously interferes with the privileged execution.

B. INTEGRITY AS A SET OF INTERVAL PROPERTIES
Proving the integrity of a processor, as introduced by the ISU property in Def. 2, on real RTL models for any possible SW requires scalable and efficient verification methods. Similarly to UPEC for confidentiality, we formulate a set of interval properties covering ISU. Using IPC as a proof method, we can verify whether the properties hold under any possible program running on the processor.
By analyzing the ISU property we can decompose the integrity requirement into the following verification targets: 1) prove that an unprivileged process cannot modify (a) protected memory regions M p , (b) protected core-internal registers R p , 2) prove that privilege escalation is secure.
The first target directly relates to the inaccessibility of R p and M p by any unprivileged process. The second target refers to the accessibility of privileged code execution only through some authorized state. Note that all elements of these verification targets are well defined by the ISA.
In the remainder of this section, we introduce interval properties for each target that can be refined for the processor core under verification. Unlike the UPEC property for confidentiality, the property set consists of conventional safety properties that each consider only a single instance of the system model.

1) MEMORY AND REGISTER PROTECTION
Memory isolation is necessary for providing trust boundaries between different processes. This can be accomplished in various ways. For example, the RISC-V architecture specifies a memory isolation feature called physical memory protection (PMP). The PMP can be configured via a special set of registers that are part of the Control and Status Registers (CSRs) in RISC-V architectures. The use of a PMP in RISC-V is optional. Alternatively, address space isolation can be also enforced with virtual memory translation, as it is done, for example, in Ariane [70].
The interval property in Fig. 3 formulates the proof of access control for protected memory regions. Property 1a verifies that for any program running in user-level mode with enabled memory protection, no illegal memory access is conducted. The shown pseudo-code includes invariants which may have to be added to the assumption part, as discussed in Sec. II-B. The other two macros unprivileged_mode and protection_enabled can be refined according to the processor  implementation at hand. Note that there is no restriction regarding the used memory protection mechanism itself; it is merely assumed to be enabled, which must be specified in the corresponding macro. The property is not restricted to a single protection configuration. Instead, it covers all possible configurations of the memory protection mechanisms. This exhaustive coverage is guaranteed by the symbolic configuration models introduced in [27], which we employ in this work. The past() operator refers to signal values in the clock cycle preceding the current one. In a practical refinement of the property commitment, we do not explicitly compare the full memory content with its previous value. Instead, we can use an equivalent and compact formulation in terms of the address, data and control signals of the processor's memory interface.
Security-critical information inside the core itself, e.g., exception vectors for privileged execution, must be protected from any unprivileged program. This information is usually stored in the system memory or in dedicated system registers in the core. A subset of these protected core-internal registers define the settings of the memory protection mechanism. While information in the memory is protected by memory isolation and is, thus, covered by the first verification goal, sensitive system registers are usually inaccessible to userlevel programs, or they are protected by additional mechanisms. Therefore, for the verification target 1b) from above, we propose the interval property in Fig. 4. Property 1b verifies that protected register contents cannot be altered while in user mode with protection enabled.
Both properties, integrity property 1a and integrity property 1b, are defined such that the proof time window always covers exactly one clock cycle.

2) SECURE PRIVILEGE ESCALATION
In most architectures, there is a plethora of legal instruction scenarios leading to a change of privilege in the processor. In order to verify that an attacker cannot raise the privilege level illegally, a property would first need to exclude all legal scenarios by enumerating them in its assumptions. This is prone to errors and can quickly become infeasible, due to the sheer number of scenarios. However, while there are many possible reasons for a privilege escalation, there usually are few legal, well-defined behaviors immediately after the privilege level has been raised (i.e., behaviors starting in an authorized state s a ∈ S a ). Upon privilege elevation, the PC is always set to a specific address pointing to a handler routine. Depending on the architecture, this address is stored in a protected part of the memory or in a special system register. We propose the property in Fig. 5 which verifies that control strictly follows the legal behavior. Any privilege escalation initiated by the attacker must go through an authorized state such that the system enters a secure state with integrity intact.
Although we did not observe this in the microarchitectures we examined, the exact time point when the first privileged instruction is fetched is not necessarily t + 1 as in Fig. 5. If needed, this time point in the property can be adapted to the RTL implementation in a straightforward way. Note that the time window of the proof usually does not depend on the source of the exception or interrupt triggering the privilege escalation. Although exceptions can be raised in different pipeline stages depending on their source, the actual PC update and the write to the privilege mode flags happen in the same pipeline stage in all RISC-V microarchitectures we have examined so far. This results in a time window of one clock cycle for property 2.

C. VERIFYING ISU
The interval properties 1a, 1b and 2 address the different components of the ISU trace property from Def. 2, and together fully cover it. In accordance with our threat model we make the assumption that the privileged SW correctly configures and activates the HW protection mechanisms before any unprivileged SW can be executed. This means that the assumptions of properties 1a, 1b and 2 are fulfilled whenever the unprivileged attacker process begins execution. The validity of these assumptions is guaranteed also afterwards, during the entire execution of the attacker process, if and only if all three properties can be proven : Any bypassing of the access control of protected memory leads to failing of property 1a. Any modification of the configuration registers for the memory protection or any modification of other protected registers leads to failing of property 1b. Any increase of privilege with unauthorized instruction execution leads to failing of property 2. Hence, the ISU property holds if and only if none of the properties 1a, 1b or 2 fails. Importantly, we do not rely on a correct implementation of the HW protection mechanisms, but only assume in our properties that they are correctly activated from the SW's point of view. If, in fact, the integrity of the system is violated by design bugs in the HW protection mechanisms, this is detected by our properties.
For verifying ISU on a given processor the properties 1a, 1b and 2 must be refined to the RTL description. The valid access control configurations are formulated as constraints to the properties. When running property checking, counterexamples may occur that reveal security vulnerabilities caused by bugs in the implementation. They point to possible fixes of the RTL. False counterexamples, on the other hand, are handled by formulating invariants to strengthen the property. The HW is guaranteed to be ISU-secure when all properties hold.

IV. FAULT ANALYSIS
By verifying the security properties introduced in Sec. II-C and Sec. III, we can guarantee that access control mechanisms are effective and have been implemented correctly. Hence, a user-level attacker cannot read secret data or modify protected assets. This covers threat model (1) of Sec. I-B. However, when broadening the attack surface by considering fault injection, such security guarantees may be invalidated. In the following, we therefore address the extended threat model (2) of Sec. I-B. Fig. 6 presents the fault analysis flow. The starting point of our formal fault analysis is the RTL design verified w.r.t. threat model (1) together with the refined properties. We consider fault attacks injecting single or multiple faults into the computing system during program execution with the goal of compromising the access control or memory isolation mechanism in place. The effect of an injected fault is a change in a value stored in a flipflop or in a logic signal on a wire in the combinational circuitry, from which it may propagate to one or more flipflops. An altered value in a storage element (i.e., an error) may propagate further with every clock cycle by normal circuit operation. Our analysis decomposes the effect of fault attacks into two scenarios: The first scenario is when fault injection directly causes a security violation.
For protection against this case, our analysis identifies the security-critical infrastructure of the processor, which must be hardened against faults using conventional techniques such as Triple Modular Redundancy (see Sec. IV-A). The second scenario is when the logical propagation of faults causes a security violation. In Sec. IV-B, we develop a lightweight online monitor to protect against such fault propagation scenarios. Our analysis shows that it is sufficient to monitor the invariants of the refined properties for protection against any fault propagation.

A. SECURITY-CRITICAL INFRASTRUCTURE
Certain system components happen to be trivial single points of failure, i.e., fault injection into these components violates the security requirements immediately. A simple example of such a component is the register that stores information about the privilege level of the currently running process. A single bit flip in this register immediately causes an illegal privilege escalation. We refer to these system components as the security-critical infrastructure.
The security-critical infrastructure is composed of the microarchitectural implementation of certain ISA components that directly impact the security of the system. Since our integrity properties fully cover the integrity requirement for memory and protected registers, they capture all the ISA-level objects that are directly related to this security requirement. In other words, the subset of the design that forms the security-critical infrastructure corresponds to the ISA-level objects to which the interval properties 1a, 1b, and 2 of Sec. III refer to. Def. 3 formally defines the security-critical infrastructure.
The security-critical infrastructure typically includes the protected assets, the PC, and the state variables encoding the privilege level. Identifying these components for a concrete design requires finding the mapping between the ISA-level objects and the microarchitecture. It is a manual but straightforward task and is part of the verification process. Commercial EDA tools provide features that aid verification engineers in extracting such ISA-visible components from the design.
The security-critical infrastructure needs to be hardened against fault attacks by some form of redundancy or other measures for fault detection. An adequate hardening mechanism may be chosen according to power, performance and area restrictions based on a large variety of available techniques, as discussed in Sec. I-C. However, faults may still be injected anywhere else in the system and may lead to a security breach through propagation of errors. Any such propagation can be missed when only hardening the securitycritical infrastructure. Instead additional measures are needed that we develop in the following.

B. MODELING FAULTS AND THEIR PROPAGATION
Our fault analysis seeks to answer the following question: Which parts of the circuit (state variables, logic blocks) besides the security-critical infrastructure are susceptible VOLUME 11, 2023 to fault injections, with respect to the given security requirement?
In answering this question, we actually do not explicitly model all possible single-and multiple-bit faults and their propagation in a gate-level model of the system. Instead, we use the RTL implementation model (as it is used for logic synthesis) together with the interval properties specifying the security requirements. We model the effects of injected faults as erroneous values in the state variables of the RTL model. In other words, we model a fault injection as an alteration of the system state in the RTL model, thereby representing implicitly all possible single-and multiple-bit faults and their propagation.
Before we elaborate the theoretical underpinnings of our fault analysis more formally, we provide some intuition of our reasoning. We distinguish between the two cases that fault injection can alter the system state within the reachable state space or creates an unreachable state.
Fault injection creates an unreachable state: In this case, our fault analysis exploits the fact that the interval properties specifying the security requirements start from a symbolic starting state (cf. Sec. II and Sec. III). This symbolic state abstractly represents all states, i.e., all possible valuations to the state variables, including such states that are unreachable from reset. While the system never assumes unreachable states during normal operation, it may do so as a result of a fault injection.
If an IPC property can be proven for the RTL design, then it holds on a set of states that includes all states reachable from the initial states (reset) and, possibly, some or all of the unreachable states. As explained above, our IPC properties are strengthened by a set of invariants that are either generated automatically or created manually by analyzing spurious counterexamples to rule out the failing unreachable states (cf. Sec. II-B).
The key observation for our fault analysis, now, is that these invariants implicitly contain just the information we are interested in. They exclude all unreachable bad states; this means that any unreachable state violating the commitment of the property must necessarily violate an invariant. Hence, a fault injection that creates an unreachable bad state can be detected through its violation of an invariant, as is developed further below.

□ Fault injection alters reachable state:
We now consider the case where fault injection might alter the system state in the reachable state space. In the reachable state space our properties are proven to be fulfilled, i.e., a fault injection does not compromise security according to these properties. This only leaves the case that fault injection ''switches off'' the assumption of a property by violating the constraints B (cf. last paragraph of Sec. II-B), fulfilling the property trivially. Fortunately, this case can never occur due to the structure of the property set created in Sec. III-B. The properties 1a, 1b and 2 have the special characteristic that it is not possible to switch off the constraints of one property without violating the commitment of one of the other properties. Hence, a fault injection can never trivially fulfill one property without at least one of the other properties failing. This is elaborated in the formal discussion below.
□ As a result, taking both above cases into account, we may conclude that any fault injection breaking the security requirement alters the system state in such a way that it violates an invariant. This is developed more formally in the following and proven in Theorem 1 below. It provides a strong basis for low-overhead mitigations of the security threat considered in this paper.
We consider an RTL design of a processor and a security requirement specified as a set of (1-safety) interval properties Q = {P i }, each of length l = 1 (one clock cycle), such as the ones developed in Sec. III. The following lemma shows that the contraposition of an IPC property is also valid in the case that fault injections alter the state of a system to an unreachable state. Let R ⊆ S be the set of states reachable from some reset state s 0 ∈ S 0 . Let P(A, C, l = 1) ∈ Q be an IPC property that holds in every starting state s ∈ S. Further, consider a states ∈ S \ R assumed by the system as the consequence of a fault. Lets ′ = δ(s, x) be the next-state computed by the design under some input x. If the commitment C of property P is violated for the state sequence (s,s ′ ), then (s,s ′ ) must also violate the assumption A.
Proof: Property P is an implication A ⇒ C between two sub-properties (logic formulas) A and C. Let the state sequence (s,s ′ ) be a counterexample to C. Since P holds for any starting states ∈ S, and, by contraposition, P = (¬C ⇒ ¬A), the state sequence (s,s ′ ) is also a counterexample to A. □ It is important to note that the logic formulas expressing the commitments C(V , Y ) and constraints B(V , X ) of the properties in our security requirement Q usually depend only on small subsets of the RTL signals. We define V P ⊆ V as the state variables appearing in the commitments and constraints, and the projection δ P (V , X ) as the next-state function component that determines the next-state values of the variables in V P , based on the transition function δ of the FSM implemented by the design. For the integrity requirement of Sec. III-B, V P comprises the protected assets (commitments of integrity properties 1a and 1b), the program counter (commitment of integrity property 2) and the state variables encoding the privilege level (constraints of properties 1a, 1b and 2). Note that the protected assets also appear in the constraints of properties 1a and 1b. Similarly, we define Y P as the output variables appearing in the commitment C(V , Y ) and the projection λ P (V , X ) as the output function component computing the output values for the variables in Y P . In the RTL design, the functions δ P and λ P correspond to the combinational logic in the fan-in of the state variables V P and outputs Y P , respectively. (The security objectives described in this paper do not consider outputs so that Y P is empty.) Definition 3 (Security-critical infrastructure): For a given security requirement Q = {P i }, the state variables V P ⊆ V and the output variables Y P ⊆ Y appearing in the commitments and constraints of the P i , as well as their combinational fanins δ P and λ P , constitute the security-critical infrastructure of the system.
Let us now reconsider the above question of what parts of the circuit outside the security-critical infrastructure are susceptible to fault injections. With the help of Lemma 1 we make the following important observation: Corollary 1: Given a set Q = {P i } of IPC properties, each of length l = 1, describing a security requirement which holds in the (fault-free) processor. Assume single or multiple fault injections into arbitrary signals of the design except for signals of the security-critical infrastructure. If the effect of such a fault injection yields a system state that does not violate the assumption of any property P i ∈ Q, then it cannot compromise security as specified by Q.
Proof: An injected fault cannot change the system state ''immediately'', i.e., with a propagation delay shorter than one clock cycle, such that it violates the commitment of some property P i (A i , C i , l = 1) ∈ Q, because all commitments C i are expressed only in terms of variables V P and Y P , which, by assumption of the corollary, are excluded from fault injection. The effect of a fault injected anywhere outside the security-critical infrastructure requires at least one full clock cycle of circuit processing before it can reach V P or Y P . Hence, we can model the fault effect by a transition (s,s ′ ) withs ′ = δ(s, x) for an arbitrary input x. For every property P i (A i , C i , l = 1) ∈ Q, the fault effect (s,s ′ ) either does not violate the commitment C i or, by Lemma 1, it must also violate the assumption A i . □ When we apply these results to the ISU property of Sec. III and the corresponding interval properties, we can draw further conclusions: Theorem 1: Given the integrity requirement, specified by ISU (Def. 2), and the set Q = {P i } of integrity properties 1a, 1b and 2 which hold in the (fault-free) processor. Assume a fault can be injected anywhere in the design with the exception of the security-critical infrastructure.
Any such fault injection compromising the ISU requirement is detectable by a violation of an invariant of at least one property P i ∈ Q.
Proof: Let one or more injected faults violate the commitment of a property at an arbitrary clock cycle denoted by time point τ .
Since a fault is assumed not to be injected directly into any state variable V P of a property or into its combinational fanin δ P , a fault injection cannot invalidate a constraint or commitment immediately, i.e., in the same clock cycle τ . Hence, faults violating constraints or commitments can only do so by fault propagation. In accordance with Corollary 1, a fault violating a property P i and thus its commitment C i violates also the assumptions A i = I i ∪ B i , I i ∩ B i = ∅. As a consequence, the violation of the assumptions is either (partly) caused by violations of invariants in I i , which proves the theorem, or by violation of only constraints B i . For the latter case, we need to distinguish between constraints denoted by the macros unprivileged_mode and protection_enabled respectively. A fault propagation can violate unprivileged_mode raising the privilege level either while transitioning into an authorized state (cf. III-B) or into an (attacker-controlled) unauthorized state. In the former case, the attacker loses control and there is no security violation, because the executed privileged code is authorized. In the latter case, property 2 fails (all assumptions are fulfilled, while the commitment is violated). This means there must exist an invariant for property 2 that considers this case, since all properties in Q hold on the fault-free design, by assumption of the theorem. The other constraint, denoted by protection_enabled, appears in the assumptions one clock cycle prior to the commitments. Fault propagations violating this constraint do so at time point τ − 1. However, the macro protection_enabled is formulated using state variables of system registers or memory contents, for both of which properties 1a and 1b assert unmodifiability in their respective commitments. Hence, a fault propagation violating protection_enabled at time point τ − 1 also violates a commitment in Q. As a consequence, this case can be ruled out by induction: The violation of constraints at τ − 1 is also a violation of property commitments, which, in turn, entails a violation of the assumptions at τ − 2. The induction is based at time point τ − n, when the attacker-controlled process begins execution in a secure state, i.e., protection_enabled holds (cf. end of Sec. III). In consequence, monitoring all invariants of the properties in Q detects any security-relevant fault effect. □ This observation allows us to design effective and efficient fault attack detection mechanisms by implementing monitoring logic that checks the assertion of the assumptions A i of a set of security properties Q (cf. Sec. IV-D) in every clock cycle of execution. We implicitly take into account all security-critical faults and their propagation. The property's invariant specifies not only the set of vulnerable state variables, but also the specific valuations to these state variables that represent a security risk. In fact, the invariants implicitly describe the prefixes of all possible fault attacks on the security-critical infrastructure during user-level program execution.

C. EXTENSION TO CONFIDENTIALITY
Theorem 1 and the discussion in the previous Sec. IV-B are concerned with integrity requirements where a set of assets is protected against illegal modification through fault attacks. It is desirable if the same approach can be taken also for confidentiality requirements where a fault injection must not lead to leakage of secret data to a user-level process(cf. Sec. II-A). Can we use the invariants developed for a UPEC property to construct a monitor detecting a leakage by fault injection? The basic idea, indeed, works here as well: If a fault effect induces a system state that violates the commitment of a UPEC property then it must also violate its assumption. However, there are a few obstacles to applying this idea in a straightforward manner.
UPEC verifies the confidentiality and not the integrity of variables and the state variables appearing in the commitments of the UPEC property do not represent securitycritical infrastructure that is hardened against fault injection. Therefore, a fault effect that violates the assumption of the UPEC property doesn't necessarily violate an invariant; it could also violate a constraint relevant to the confidentiality requirement, e.g., ''non-privileged mode'' or ''protection enabled''.
Fortunately, we still can extend our approach to confidentiality by combining a monitor for the assumptions of the confidentiality property with the monitor for the integrity properties. As a matter of fact, the security-critical infrastructure of the integrity requirement is also responsible for protecting the confidentiality of secret data. In other words, the confidentiality requirement implies the integrity requirement for the variables implementing protection mechanisms. Let Q be the set of integrity properties implementing ISU (Def. 2) according to Sec. III-B, and let U be the UPEC property. Like in the proof for Theorem 1, Q * = Q∪{U } is a set of properties where every constraint in each property is checked by the commitment of at least one property of Q * . Therefore, a monitor watching all invariants from the properties in Q * detects any fault effect compromising confidentiality of secret data or integrity of protected assets or both.

D. COUNTERMEASURES
As discussed in Sec. I-A, common countermeasures against fault attacks on the security-critical HW are not effective under the considered threat model. We propose a hardening technique based on Theorem 1 to close this gap. Our approach uses information extracted from the property assumptions, with minimal implementation overhead. As explained in Sec. IV-B, from all faults that are injected (except into security-critical infrastructure) only those that violate the invariants used in the security properties can compromise security, as it has been defined in Secs. II-A and III. This insight allows us to develop an online HW monitor that raises an alarm whenever the system experiences a fault effect with potential security implications, by constantly checking that the system complies with the invariants.
This monitor is capable of detecting all security-critical fault injections except for those into security-critical infrastructure. The security-critical infrastructure, as defined in Sec. IV-A, needs to be hardened by other techniques. Internal logic can be hardened by HW redundancy, such as TMR. This is reasonable and affordable when the number of the involved variables and the size of their fan-in logic is small compared to the rest of the circuit. This is a valid assumption for our threat model, as shown in Sec. V. In addition, information redundancy mechanisms like ECC can be applied to protected memory regions. Note that our approach is orthogonal to any such implementation for hardening the security-critical infrastructure. Fig. 7 shows the structure of the proposed monitor. The monitor detects all behaviors leading to security violations by propagation of fault effects to the system's security-critical infrastructure. It takes the signals used in the invariants I and property constraints B (e.g., user mode, protection enabled) as inputs. Internally, the monitor implements the logic expressions from the invariants and checks in every clock cycle whether the system state fulfills the invariants. If not, the monitor raises an alarm. If the system leaves the constraint state space (e.g., through a trap to machine mode), the monitor is disabled. Depending on the architecture, the alarm can be used to trigger an exception, interrupt or reset.
Similarly as in many other fault-resilient architectures, it may be considered a weakness that faults injected into the HW of the monitor itself may compromise its functionality and suppress an alarm. Fortunately, since the proposed monitor reads only a subset of the state variables and ignores most of the state-holding elements in the processor, common hardening techniques like, e.g., Triple Modular Redundancy (TMR), can be applied to the critical state variables without a large overall overhead.

V. EXPERIMENTS
We applied the introduced integrity properties to three RISC-V processor implementations and analyzed their vulnerability to fault attacks. The experiments were conducted on • Ibex (version from August 2021), a 32-bit RISC-V CPU core, with the same configuration as in the OpenTitan project, featuring a 2-stage pipeline and a PMP; • RI5CY, a 32-bit 4-stage core with a PMP, as used in the Pulp project; • Ariane v4.1.2, a 64-bit in-order CPU featuring a 6-stage pipeline with out-of-order write-back, scoreboarding and virtual memory management. The PMP bugs in RI5CY described in [27] compromise not only functionality but also confidentiality and integrity. Therefore, we used a corrected version of the PMP for our experiments. For each processor, we set up the integrity properties as introduced in Sec. III. We use the open-source  symbolic verification IP from [77] to cover all permissible PMP configurations. Tab. 1 shows the overall manual effort needed for the security verification. The reported times include the refinement of the property templates to the corresponding processor implementations as well as the development of invariants.
We implemented, for each design, a monitor as introduced in Sec. IV-D that captures any fault attack violating our security objectives.

A. PROPERTY CHECKING
Tab. 2 shows the proof runtimes of the different experiments. All experiments were conducted on an Intel i7-8700 @ 3.2 GHz with 64 GB RAM running Linux using the commercial property checker OneSpin 360 DV.
The Ibex and RI5CY designs both fulfill all properties. Integrity property 1a and 1b as well as the UPEC property are also fulfilled by Ariane design.
However, a bug was detected when proving integrity property 2 on Ariane: Interrupt handling was not implemented according to the RISC-V ISA. The CSRs mtvec and stvec specify how the PC is computed when entering supervisor or machine mode. The mode field of mtvec determines whether, upon entering machine mode, the PC is set directly to the address given by the base field, or whether the PC is loaded from an entry in the vector table. CSR stvec holds the corresponding information for privilege escalation to supervisor mode. However, in Ariane the PC was loaded from the vector table regardless of the mode field of mtvec when entering machine mode. A bug in the CSR module caused this miscalculation. In some cases, the PC was computed based on the mode field of stvec rather than mtvec when entering machine mode. Therefore, any process running in supervisor mode could interfere with the fetched address and control what code was executed when entering machine mode, which is a serious threat in virtualization environments.
The bug was confirmed and fixed by the development team. Note that the Ariane design has been used as case study for several large hardware security competitions [78]. The work in [79] also detected several bugs in Ariane. However, none of these activities caught the incorrect trap handling. This demonstrates the benefits of a formal approach which can detect even hard-to-detect corner case bugs. The proof runtime on the fixed design (green) was the same as the runtime until we obtained a counterexample on the buggy design (red).

B. EXEMPLARY FAULT ATTACKS
In most of our proofs from the previous subsection we need invariants to exclude unreachable processor states. States that are unreachable in normal system execution can be induced by a fault attack and violate the security requirements. As discussed in Sec. IV-B, any fault propagation to the state variables of an invariant poses a threat to system security. For each Ibex and RI5CY we developed two invariants and, for Ariane, 11 invariants. All of them were proven on the respective designs by separate induction proofs. The invariants show all possible fault attack scenarios violating our security objectives. In the following we present two selected examples of the attack scenarios found by our method.

1) CODE INJECTION IN RI5CY
If a user-level process executes an instruction accessing a privileged CSR on RI5CY, the decoder issues an illegal instruction and raises an exception. In fact, in a fault-free execution a user-level program is not able to write to a privileged CSR. Fig. 8 shows the corresponding invariant. (This invariant like all other invariants used in our experiments were formulated in SVA and formally proven by the commercial property checker.) The register csr_op_ex_o specifies the CSR operation with 2'b00 encoding NONE, i.e., no reading or writing to the CSR. alu_operand_b_ex_o defines the address of the accessed CSR with bits 9 and 8 specifying the privilege level of the accessed CSR. The field priv_lvl_q specifies the privilege level of the program currently executing. A 2-bit value of '00' specifies user mode. The invariant specifies that a user-level process does either not modify a CSR, or it is a user-level CSR. If an attacker injects faults into the register alu_operand_b_ex_o while accessing a user-level CSR, they can illegally modify privileged CSRs. Bit flips in bit 9 and 8 of alu_operand_b_ex_o can essentially lead to accesses to supervisor or machine mode CSRs. Note that an illegal write to mtvec allows an attacker to load its own code in machine mode upon a trap.

2) SECRET KEY EXTRACTION ON ARIANE
We analyzed the invariants used in the confidentiality experiments on Ariane, as made available by [35]. These invariants exclude a number of unreachable state valuations within VOLUME 11, 2023 A. L. DUQUE Antón et al.: Fault Attacks on Access Control in Processors the system. As an example, Fig. 9 shows an unreachable state transition (indicated by the dotted arrow) in the data cache controller FSM as it is excluded by one of the invariants. When a read transaction encounters a cache miss while an earlier request to the same address is being processed by the miss handler, the cache controller enters state WAIT_MSHR. In this state, the cache controller waits for the refill by the miss handler and then repeats the transaction with the saved address (WAIT_TAG_SAVED). When the transaction is repeated, by definition, it cannot be a cache miss again and thus it cannot go to a cache refill state (WAIT_REFILL_GNT). However, if such a transition is forced by an injected fault, the cache continues the transaction by initiating a cache refill. However, in state WAIT_REFILL_GNT, the saved address is deemed invalid, and the cache refill is carried out based on the current request coming from the core (on the address bits of the input port of the cache). This behavior can be exploited by the attacker by putting the desired secret address on the cache input by executing another load instruction at the same time.
Such a fault injection can create a scenario in which the address of a load transaction is changed in the middle of the operation, potentially leading to readout of protected memory locations.

C. MONITOR IMPLEMENTATIONS
In Sec. IV-D we propose a lightweight protection mechanism against fault attacks. We implemented such a monitor in all three processors and synthesized the designs for Xilinx FPGAs using Vivado. We then compared the number of logic slices, consisting of look-up tables (LUTs) and flipflops (FFs), for the circuits with and without monitor. For RI5CY and Ibex, there were no differences in the number of used logic slices between the original design and the design with an integrated monitor. This is due to the small number of state bits (37 state bits for Ibex, 40 state bits for RI5CY) that are needed to formulate the invariants for the properties. We observed that the synthesis tool was able to merge the monitor logic into logic slices already used for the original designs. Tab. 3 shows the results for Ariane. As can be seen, the overhead is negligible. Even when triplicating these numbers for implementing the monitor based on TMR, as suggested in Sec. IV-D, the resulting overhead remains of no concern. TABLE 3. Monitor implementation in Ariane (core only). As described in Sec. IV-D, the monitors can complement conventional hardening techniques [14] which we assume to be employed for the (well-defined) security-critical infrastructure. The security-critical infrastructure follows from the security requirements and their formalization by the properties. It forms a rather small subset of state variables in all three examples, as shown in Tab. 4. This can be explained by the fact that the interval properties provide a concise formulation of our security requirements.

VI. CONCLUSION
This paper presents an exhaustive method for identifying all security violations caused by fault injection for a given threat model. We present an effective and hardware-efficient approach to defend against fault attacks. It combines protecting a reasonably small and well-defined subset of processor components, called security-critical infrastructure, with a fault detection monitor generated from our results. Our approach covers single and multiple bit flips, as well as stuckat faults.
We implicitly represent the huge space of single and multiple fault injections by certain elements of a formal proof procedure that targets a well defined security goal. Our experiments demonstrate the viability and scalability of our approach for processors of realistic size.
The approach requires a set of interval properties adhering to a certain structure as discussed in Sec. IV-B. So far we are limited to properties covering confidentiality and integrity attacks launched from unprivileged user level processes. Any other threat model needs to be formalized accordingly to be able to apply the method.
Our experiments revealed an important security weakness of the Ariane processor as confirmed by the development team. Even more importantly, our experimental results provide the evidence that the threat model considered in this paper is relevant and that the associated risks are substantial. To this end, we presented several examples of how an attacker could exploit fault injection to break process isolation for a user-level process.
In future work, we will extend the scope of our fault analysis to different types of HW systems, including multicore and multi-threaded processors, as well as complex SoCs.