2023 21st ACM/IEEE International Symposium on Formal Methods and Models for System Design (MEMOCODE)

Formal Verification of Security Properties on RISC-V Processors

Czea Sie Chuah Christian Appold
[email protected] Tim Leinmueller
DENSO AUTOMOTIVE Deutschland GmbH [email protected]
Germany [email protected]
Technical University of Munich DENSO AUTOMOTIVE Deutschland GmbH
Germany Germany

ABSTRACT (MEMOCODE ’23), September 21–22, 2023, Hamburg, Germany. ACM, New
Hardware Security and trustworthiness are becoming ever more im- York, NY, USA, 10 pages. https://doi.org/10.1145/3610579.3611085
portant, especially for security-critical applications like autonomous
driving and service robots. With the increase in distribution of RISC-
V processors, security issues in them arise. Security vulnerabilities 1 INTRODUCTION
and design flaws in processors can be exploited by attackers, e.g. Processors are ubiquituous in our daily live and are embedded in
by running software exploiting the vulnerabilities. This can lead to nearly every electronic device. They enable a lot of very useful
drastic consequences like damaging whole system functionality and applications and due to this enrich and simplify our daily life. To
even human lives can be endangered. Hence, it is very important to function reliably and to fulfill their purpose, they have to be de-
verify compliance of processors with the design specification and signed according to specification and to be free of bugs and design
microarchitecture intent to harden the hardware against malicious flaws. Otherwise, malfunctioning of processors can even endanger
attacks. Detection and removal of design bugs results in improved human life, especially in safety- and security-critical areas like au-
processor security. Therefore, we formally verify in this paper the tonomous driving or service robots. On the other hand more and
security-critical functionality of a commercial RISC-V processor more features, like pipelining, branch prediction or out-of-order
using model checking based formal verification with the formal execution are used in processors and due to this, processor complex-
verification tool Jasper. For this, we determined and implemented a ity is continually increasing. As a consequence, processor design is
comprehensive list of properties for security-critical functionality, getting more and more error-prone.
derived from RISC-V specification and processor microarchitec- In the past years several famous processor bugs and vulnerabili-
ture intent. The properties cover the security-critical functionality ties have been discovered. In the early 1990s the Pentium bug lead to
within a RISC-V processor. With our verification experiments, we a big loss of reputation for Intel [9]. Recently, Spectre and Meltdown
detected design bugs which have been confirmed by the design have been published [14], which exploit security-vulnerabilities in
team. processors to leak secret data. It is expected that even more security-
vulnerabilities will be discovered and exploited in the near future.
CCS CONCEPTS This unveils the underlying challenges in hardware security even
though it had been a focus of research for the past decade. Several
• Computer systems organization → System on a chip; Em-
upcoming and promising new application areas like autonomous
bedded systems; • Security and privacy → Logic and verifica-
driving, IoT and factory automatization even have very high secu-
tion; Embedded systems security; • Hardware → Assertion
rity demands. Hence, processors used in these applications have
checking; Model checking.
to fulfill very high security requirements and it is expected that
the security challenges will continue to grow in future. Therefore,
KEYWORDS processor security is of utmost importance.
Hardware Security, Formal Verification, Model Checking, Security- RISC-V instruction set architecture (ISA) is getting to be adopted
Critical Functionality, RISC-V, Processor more and more extensively on open source and commercial pro-
cessor designs, due to its flexibility to support extensions and cus-
ACM Reference Format:
Czea Sie Chuah, Christian Appold, and Tim Leinmueller. 2023. Formal tomization and its open instruction set. Forecasts predict that dis-
Verification of Security Properties on RISC-V Processors. In 21st ACM-IEEE persion of RISC-V processors will continue to grow strongly in
International Conference on Formal Methods and Models for System Design the coming years. Companies have taken the opportunity of the
free ISA to design chips with high-end performance requirements
supporting automotive and industrial applications [12, 16, 19]. The
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed openness of the RISC-V ISA is a big advantage in terms of having
for profit or commercial advantage and that copies bear this notice and the full citation a huge community to examine and extend the ISA on an ongoing
on the first page. Copyrights for components of this work owned by others than the basis, but at the same time this is also a disadvantage, as attack-
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific permission ers can target the architecture easier. Due to the steadily growing
and/or a fee. Request permissions from [email protected]. dispersion and to enable the use of RISC-V processors in highly
MEMOCODE ’23, September 21–22, 2023, Hamburg, Germany safety- and security critical areas, it is therefore inevitable to ensure
© 2023 Copyright held by the owner/author(s). Publication rights licensed to ACM.
ACM ISBN 979-8-4007-0318-8/23/09. . . $15.00 high security standards and compliance to specification for RISC-V
https://doi.org/10.1145/3610579.3611085 processors.

159

Authorized licensed use limited to: Indian Inst of Inform Technology Guwahati. Downloaded on December 16,2024 at 12:39:06 UTC from IEEE Xplore. Restrictions apply.
 MEMOCODE ’23, September 21–22, 2023, Hamburg, Germany Chuah, et al.

Security of a processor can be validated during pre-silicon and Chip. Paper [8] presents work on security requirements using as-
post-silicon phase and there are different methods for security sertion checkers and code coverage method, with demonstration
checks with different purposes. Pre-silicon validation is done before on OpenRISC processor. A runtime monitor evaluation against 18
silicon are being fabricated, thus changes and fixes on bugs can security bugs on an OpenRISC OR1200 processor is presented in
be carried out cost-efficiently. Post-silicon validation is executed [13], while [7] define and determine security-critical properties
with a fabricated hardware chip causing extremely high costs if any with reference to the MIPS architectural specification for runtime
alteration is needed. Hence, vulnerabilities in processor designs monitoring. Our security-critical property set is much more com-
should be identified as early as possible in the hardware life cycle. prehensive and our work is the first such work which targets the
For this reason, we are focusing on detecting security vulnerabilities RISC-V architecture.
of processors in the pre-silicon phase by using formal verification Both paper [7, 13] implement security-critical properties manu-
in this paper. ally for runtime monitoring while [22] implemented a tool chain
Traditionally, simulation is widely used in the industry for pre- called SCIFinder workflow. They use machine learning to iden-
silicon validation since the dawn of processor evolution. However, tify security-critical properties and as a result discover additional
the limitation of using this method is that verification is done only security-critical properties that were not discovered in previous
for stimulated input patterns, which results in corner case errors manually written papers. They classify these security-critical prop-
to be overseen. Due to growing processor complexity, it is getting erties finding into 5 categories, without considering a few other
even more difficult to investigate sufficient parts of the design func- aspects which are security-critical that we have considered in our
tionality, because too many test cases need to be generated for work.
it. Another method for pre-silicon hardware verification is formal There are only two other previous works [6, 15] which use for-
verification. A fully-automatic approach for formal verification, mal verification for security properties verification. But they are
which is used in this work is Model Checking. Model checking is done on an OpenRISC processor and additionally they are missing
a type of formal verification which uses a mathematical model of some aspects in comparison with our work and our property set is
a system and systematically explores all possible behaviors of the much more comprehensive. There is only one recent work which
system. There are previous works which target formal verification formally verified RISC-V but focusing only on PMP. We are the first
of processor security [6, 15]. Neither of these works targets RISC-V who present a comprehensive set of security properties for RISC-V
processors and for our work we did a much more comprehensive processors, as a result of a detailed security analysis. By doing this
security investigation. As a result we are presenting in this paper a we fill an important gap in the existing literature about processor
much more extensive set of security properties and our work is the security verification. Our research work enables security-critical
first which enables detailed security-critical functionality formal properties formal verification for RISC-V processors. We present
verification for RISC-V processors. In the following we present in our findings by classifying the security-critical properties into 9
section II of the paper related work. Afterwards, section III contin- categories which focus on different security aspects of a RISC-V
ues with our used methodology, before section IV describes our processors.
security-critical properties. Section V discusses about the results of
our formal verification work and finally section VI concludes the
paper with direction on future work.
3 METHODOLOGY
In this section we describe the methodology, which we used for
our work. The used workflow is shown in Fig. 1. We start with
2 RELATED WORK studying specification documents and information about the mi-
There has been formal verification work to verify against ISA com- croarchitecture of the processor to identify functionality which is
pliance on ARM [18] and RISC-V architecture [21]. Regarding RISC- security-critical [3–5, 20]. Afterwards, we derive and implement
V there has been published a RISC-V Formal Verification Framework properties from the identified security-critical functionality and
with a Formal Verification Interface (RVFI) [21] and any RISC-V finally feed them into a commercial formal verification tool to be for-
processor which implements the RVFI can be formally verified for mally verified. Each step will be described in detail in the following
design compliance with the ISA using this framework. Both of those subsections. Our experiment is done on the commercial automotive-
formal verification approaches prove the correctness of the design grade RISC-V processor, Akaria NS31A which is given license from
with respect to the ISA and detect corresponding design bugs in NSITEXE, Inc. [16]. NS31A is optimized for control-specific mi-
processors. The main focus of these frameworks is to verify that crocontroller. NS31A is a RISC-V processor, compliant to RISC-V
instructions work as desired according to specification. In com- instruction set architecture (ISA). It is a 32-bit single-issue proces-
parison to this approach, our main focus is to target directly and sor, with a 4-stage pipeline with the pipeline stages instruction fetch
exhaustively the security-critical functionality with our proper- (IF), instruction decode (ID), execute (EX) and write back (WB). The
ties. Additionally, we target for full-proofs with our more directed NS31A core supports 2 privilege modes: machine mode and user
properties instead of using Bounded Model Checking. mode. It also comes with a branch prediction mechanism with a
Papers [6, 15] analyse security properties on the OpenRISC branch target buffer and a Floating Point Unit. Hardware thread
OR1200 processor, with 13 security-critical properties identified (Hart) control finite state machine (FSM) is included in NS31A core
and implemented respectively. Paper [10] formally verified physical and indicates hart execution states which are independent from the
memory protection (PMP) in an open source RISC-V core, Rocket privilege mode of the hart to control state transition requests from

160

Authorized licensed use limited to: Indian Inst of Inform Technology Guwahati. Downloaded on December 16,2024 at 12:39:06 UTC from IEEE Xplore. Restrictions apply.
 Formal Verification of Security Properties on RISC-V Processors MEMOCODE ’23, September 21–22, 2023, Hamburg, Germany

Concurrent SVA:
assertion_name: assert property (@(posedge clk)
disable iff (rst) (x && !y) |-> ##2 (z == $past(z)));
• assertion_name : label of the assertion expression to be
described, usually with an obvious naming of the behaviour.
• assert property : syntax of a concurrent assertion, without
’property’ the assertion is immediate.
• @(posedge clk) : the property is sampled at the positive
edge of the signal ’clk’.
• disable iff (rst) : the property is disabled when the
’rst’ signal is high.
• (x && !y) : antecedent, which means the pre-condition of
the property to be fulfilled, this can be a combination of a
set of signals or just a signal by itself.
• |-> ##2 : the expression is checked after the number of
clock cycles specified (in this case 2) after pre-condition has
Figure 1: Methodology and Workflow
been fulfilled.
• z == $past(z) : consequent, which is the expression be-
haviour to be checked, such as constant value, rise or fall of
outside the core, debug control request, the execution of instruc- a signal, etc. In this example, comparison with a previous
tions, etc. value ($past()) is done.
In the following when properties are listed, we omit the first half
3.1 Specification of this SVA example and start immediately with the formula of the
First, we deep dive into the RISC-V specification documents and property due to space constraint.
NS31A microarchitecture implementation. In-depth knowledge of
the specification documents and the microarchitecture is required 3.3 Formal verification and analysis
to derive information on security-critical functionalities inside the Thirdly, the assertion properties together with the design are fed
processor. In order to achieve this, we run through numerous litera- into the Cadence Jasper Formal Verification Platform [17] for val-
ture, the RISC-V unprivileged [4] and privileged [5] instruction set idation. Jasper can generate cover property automatically for im-
manual, RISC-V debug specification [20] together with the NS31A plication properties on the pre-condition of the implication. If the
technical reference manual (TRM) [3]. The unprivileged instruc- cover property of an implication property passes, this means the pre-
tion set manual describes the RISC-V unprivileged architecture. condition has been triggered during the verification. If the assertion
It includes the RISC-V base integer ISA, that must be present in passes, the property is fulfilled by the design. When the implication
any implementation, with optional extensions to the base ISA. The cover fails, it means that the pre-condition cannot be fulfilled for
privileged instruction set manual on the other hand covers all as- any behavior in the design. In this case, the implication consequent
pects of RISC-V systems beyond the unprivileged ISA, including has not been checked at all during verification. If the assertion
privileged instructions as well as additional functionality required fails, it means that the property is violated and a corresponding
for running operating systems and attaching external devices. The counter example will be generated by the tool. The counterexample
debug specification outlines debug support for the RISC-V platform. shows a design behavior where the property fails and this can be
The TRM documents hardware configuration, logic specification analyzed to determine whether the behavior is caused by a design
and implementation details of the NS31A processor. In our work, bug or an incorrect properties modeling. If the failure is caused by
we target to cover the security-critical functionalities within the incorrect properties modeling, we modified the property and repeat
RISC-V core comprehensively. the previous steps. On the other hand, if the failure is not caused by
incorrect properties modeling, then it would be an noncompliance
3.2 Modeling of security-critical properties to the specification or microarchitecture intent that needs to be
After identifying security-critical functionalities of the processor fixed.
in specification and microarchitecture intent, we formulate the The advantage of using formal verification is its exhaustiveness
requirements on the correct processor behavior in the form of suit- as it investigates all design behaviors for validity of the specified
able properties. For example, mode transition from user mode to properties. Thus it can also detect bugs appearing only in rare
machine mode is allowed to happen only when it is admitted, e.g. corner cases. This is a huge advantage in comparison to simula-
when an exception or interrupt is executed. Properties of these tion method, where corner cases are often hard to stimulate. The
security-critical functionality are formulated as SystemVerilog As- application of formal verification is a big improvement especially
sertions (SVA) [2] using concurrent assertions as shown below. SVA for security verification. Design behaviors that are not proven by
is a powerful language to model constraints, rules and behaviour simulation could lead to security vulnerabilities, whereas formal
for validating correctness of the design. verification can reliably detect security vulnerabilities for all design

161

Authorized licensed use limited to: Indian Inst of Inform Technology Guwahati. Downloaded on December 16,2024 at 12:39:06 UTC from IEEE Xplore. Restrictions apply.
 MEMOCODE ’23, September 21–22, 2023, Hamburg, Germany Chuah, et al.

4.2 Control and Status Register

CSRs are register for control and status acquisition that associate
to a unique address space, and dedicated access instructions are
provided. Each of these registers have its own functionality and
Figure 2: Pipeline of NS31A RISC-V Processor usually correspond to a particular privilege level be it supervisor
level, hypervisor level, or machine level providing protection be-
tween different software components. To access these CSRs, there
are restrictions and rules to obey. Each CSR has their own read or
behaviors. Model Checking based formal verification can also be write indication and the lowest privilege level that is allowed to
applied relatively quickly in early design stages, as no test benches access them. For instance, mstatus is a CSR for acquiring and con-
have to be written like for simulation. It is reliable since it provides trolling the current operating status of the hart in machine mode.
a systematic and automated way to verify system requirements Under this category, we implemented properties for all the 67 CSRs
with regards to the modelled properties. Formal verification has (when applicable) in the NS31A processor core with reference to
been recommended in many safety and security standards to assure the specification [5], technical reference manual [3] and Table 1. In
high level of quality assurance of a system. The Common Criteria Table 1, for first letter of CSR name, the symbol f floating point, m
(CC) for Information Technology Security Evaluation [1] provide indicates machine mode, t indicates trigger and d indicates debug.
an international standard for computer security certification. Its (1) Property 11-111: CSRs do not have write access in user mode
highest assurance levels EAL5 onwards require formal specification except for user floating point CSRs (example for mstatus).
and verification methods[11].
UserMode && CsrWriteOp |-> !(WriteEn_mstatus)
(2) Property 112-162: CSRs can only be written by instructions
4 SECURITY-CRITICAL FUNCTIONALITY with matching CSR address (example for mstatus).
We have identified and verified in total 1146 security-critical func-
CsrWtAddr!=MstatusAddr |-> !(WriteEn_mstatus)
tionality properties for the RISC-V core. We categorised them into
9 groups, namely instruction execution, control and status register (3) Property 163-228: CSR can only be read by instructions with
(CSR), debug operation, exception and interrupt handling, mode matching CSR address (example for mstatus).
transition, physical memory protection (PMP), control flow, regis- CsrRdAddr!=MstatusAddr |-> RdData_mstatus==32'd0
ter update and memory access. In the following subsections, we (4) Property 229-285: CSR read access is done only for CSR in-
present and explain our properties. structions with corresponding register and immediate operand
as shown in Table 2 (example for mstatus).
4.1 Instruction Execution (!(CSRRW) && !(CSRRS) && !(CSRRC) && !(CSRRWI) &&
NS31A is a 32-bit processor core with a 4-stage pipeline as shown !(CSRRSI) && !(CSRRCI)) |-> CsrRdAddr!= MstatusAddr
in Figure 2. The 4 stages are IF, ID, EX and WB. This allows the (5) Property 286-342: CSR write access is done only for CSR in-
processor to perform an instruction in multiple steps in an over- structions with corresponding register and immediate operand
lapping manner. The properties presented in this subsection prove as shown in Table 2 (example for mstatus).
proper instruction movement in processor and that ALU flags are ((!(CSRRW) && !(CSRRS) && !(CSRRC) && !(CSRRWI) &&
set in the right way. !(CSRRSI) && !(CSRRCI))) |-> !(WriteEn_mstatus)
(1) Property 1-2: Instruction moving from one pipeline stage to (6) Property 343-352: Read-only CSR’s value is constant as it
another, which means from ID to EX (example below) and should not be modified in any case (example for mvendorid).
from EX to WB should remain the same. CsrRdAddr==mvendoridAddr |-> CsrRdData==VendorID
inst_not_changed_id_to_ex: assert property (7) Property 353-398: CSR should be in a valid format. Some
(@(posedge clk) disable iff (rst) idInstValid && read/write CSR fields are only defined for a subset of bit
idPipeReady |-> ##1 exInstCode==$past(idInstCode)); encodings, but allow any value to be written while guaran-
teeing to return a legal value whenever read [5]. As shown
Note: "assertion_name: assert property (@(posedge clk) disable iff (rst)" will
in below example, reserved bits in mie should be 0.
not be shown in succeeding properties of the paper due to page limit.
(2) Property 3-4: Instruction that stays within a pipeline stage {MieRegOut[31:20],MieRegOut[18:12],MieRegOut[10:
should remain the same (example for wb). 8],MieRegOut[6:4],MieRegOut[2:0]} == 23'd0
(8) Property 399-404: CSR access violation are checked as follow:
wbInstValid && !wbPipeReady |-> ##1
wbInstCode == $past(wbInstCode) 4.2.1 Property 399-400. Exception flag is set for write to a
read-only CSR register.
(3) Property 5-10: ALU flag which influence the control flow
should be set correctly for the following instructions: beq 4.2.2 Property 401-402. Exception flag is set for attempts to
(example), bne, blt, bge, bltu, bgeu. access a non-existent CSR.
InstValid && PipeReady && beqOpcode && beqFunct3 4.2.3 Property 403-404. Exception flag is set for attempts to
&& Src1Data == Src2Data |-> equalFlag access a CSR without appropriate privilege level.

162

Authorized licensed use limited to: Indian Inst of Inform Technology Guwahati. Downloaded on December 16,2024 at 12:39:06 UTC from IEEE Xplore. Restrictions apply.
 Formal Verification of Security Properties on RISC-V Processors MEMOCODE ’23, September 21–22, 2023, Hamburg, Germany

Table 1: NS31A Control and Status Register [5][3] Description Access Mode
Register Read Write
Description Access Mode User Counter/Timers
Register Read Write cycle RDCYCLE cycle counter DMU -
User Floating-Point CSRs time RDTIME timer DMU -
fflags Accrued exceptions DMU DMU instret RDINSTRET instructions-retired counter DMU -
frm Dynamic rounding mode DMU DMU cycleh Upper-32bits of cycle DMU -
fcsr Control and status register DMU DMU timeh Upper-32bits of time DMU -
Machine Trap Setup instreth Upper-32bits of instret DMU -
mstatus Status register DM DM Machine Information Registers
misa ISA and extensions DM - mvendorif Vendor ID DM -
mie Interrupt enable register DM DM marchid Architecture ID DM -
mtvec Trap handler base address DM DM mimpid Implementation ID DM -
mcounteren Counter enable register DM DM mhartid Hardware thread ID DM -
Machine Counter Setup D: debug mode; M: machine mode; U: user mode
mcountinhibit Counter-inhibit register DM DM
Machine Trap Handling
mscratch Trap handler’s scratch register DM DM Table 2: CSR read and write operand behaviour[4]
mepc Exception PC register DM DM
mcause Trap cause register DM DM Register operand
mtval Bad address or instruction DM DM Instruction rd rs1 read CSR? write CSR?
mip Interrupt pending register DM - CSRRW x0 - no yes
Machine Memory Protection CSRRW !x0 - yes yes
pmpcgf0-3 PMP configuration DM DM CSRRS/C - x0 yes no
pmpaddr0-15 PMP address register DM DM CSRRS/C - !x0 yes yes
Debug/Trace Registers Immediate operand
tselect Debug/trace select DM DM Instruction rd uimm read CSR? write CSR?
tdata1 First debug/trace register DM DM CSRRWI x0 - no yes
tdata2 Second debug/trace register DM DM CSRRWI !x0 - yes yes
tinfo Information register DM - CSRRS/CI - 0 yes no
Debug Mode Registers CSRRS/CI - !0 yes yes
mcountinhibit Counter-inhibit register D D
dcsr Control and status register D D
dpc Program counter (PC) register D D
dscratch0 Scratch register0 D D
4.3 Debug Operation
Exception Cause Flags for Access Fault∗ Debug mode reserves a few CSR addresses that can only be accessed
meecaddr Captured error address register DM DM in debug mode. Since debug mode has the highest priority (even
meecunlock Unlock control for meecaddr DM DM more than machine mode [5]), access permission for these debug
Machine Counter/Timers CSRs are security-critical.
mcycle Cycle counter DM DM (1) Property 405-407:dpc settings should match the specification
minstret Instruction retired counter DM DM [20].
mcycleh Upper-32bits of mcycle DM DM (a) Property 405 Upon entry to debug mode, dpc is updated
minstreth Upper-32bits of minstret DM DM with the address of the next instruction to be executed.
Hart/Cache Control∗ ebreak sets dpc to address of ebreak instruction. The ebreak
mhtpc Hart PC register DM DM instruction is used to return control to a debugging envi-
mhtenable Hart enable control status register DM DM ronment.
mhtstatus Hart run control status register DM DM InstValid && PipeReady && EbreakDebug |-> ##1
L1 Instruction Cache Control∗ Dpc == $past(InstPC)
ml1cachesysctrl L1 System Control DM DM (b) Property 406-407 dpc is set to the address of the instruction
ml1cacheoperation L1 Operation DM DM that would be executed next if no debugging was going
ml1cacheprefcfg L1 Instruction prefetch control DM DM on where DebugStepExe is asserted i.e. PC+4 for 32-bit
mbpsysctrl Branch prediction system control DM DM instruction that does not change program flow, or the
mbpoperation Branch prediction operation DM DM destination PC on taken jump/branch.
Hart Fetch address Register∗ InstValid && PipeReady && !EbreakDebug &&
mhtfetchaddr Hart fetch address register DM - DebugStepExe && (JumpRequest || (BrExec &&
D: debug mode; M: machine mode; U: user mode BrTaken)) |-> ##1 Dpc == $past(JmpTarget)
∗ NS31A extended CSR

163

Authorized licensed use limited to: Indian Inst of Inform Technology Guwahati. Downloaded on December 16,2024 at 12:39:06 UTC from IEEE Xplore. Restrictions apply.
 MEMOCODE ’23, September 21–22, 2023, Hamburg, Germany Chuah, et al.

Table 3: NS31A Exception and Interrupt [4]

Category Description
Async Reset
NMI
Async NMI External NMI
Error NMI
Machine non-blocking store bus error NMI
Machine non-blocking load bus error NMI
Interrupt
Async Error Interrupt
Interrupt External Interrupt
Software Interrupt
Timer Interrupt
Exception
Figure 3: Illustration of Exception, Interrupt and Trap Instruction Break (Instruction address)
Fetch Instruction address misaligned
Instruction access fault (PMP error)
Instruction access fault (Cache error)
(2) Property 408: dcsr should contain privilege mode that hart
Instruction access fault (Bus error)
was operating when debug mode was entered [20].
Instruction Illegal instruction (Reserved instruction)
EnterDebugMode |-> ##1 Decode Break (ebreak)
(Dcsr[1:0] == $past(PrivMode) Environment call from user mode
(3) Property 409-418: Write to CSR in mode other than debug Environment call from machine mode
mode is not allowed for debug mode register. Instruction Illegal instruction (Privilege error)
Execution Illegal instruction (CSR decode error)
!DebugMode |-> !(WriteEn_dcsr) Load/Store Break (Load/Store address)
Load address misaligned
4.4 Exception, Interrupt and Trap Handling Store/AMO address misaligned
Exception and interrupt are unanticipated events that break the Load access fault (PMP error)
usual flow of instruction execution as shown in Figure 3. Exception Store/AMO access fault (PMP error)
is an unusual condition occurring internally within the processor
while interrupt is an unexpected event that happens. Trap handler
here refers to the handler which are called by either an exception or
(a) Property 483-484: When a trap is taken, previous privi-
an interrupt. These events in the processor need to be handled prop-
lege level for machine mode, mpp bit of mstatus is set to
erly to prevent disruption of continuous flow for the subsequent
privilege level before exception or interrupt;
instructions. They also have prioritization according to the hard-
(b) Property 485-486: Interrupt enable bit for machine mode,
ware specification. Table 3 shows the list of exception, interrupt
mie set to 0 when a trap is taken;
and non-masking interrupt with decreasing priority.
(c) Property 487-488: Previous interrupt enable bit for machine
(1) Property 419-439: Corresponding exception flag is set for all mode, mpie set to value of previous mie;
exceptions, interrupts and NMI in Table 3. (d) Property 489-490: For exception, exception program counter
(2) Property 440-482: mtval and mcause are set to a value indi- for machine mode, mepc set to PC from WB stage while
cating the corresponding exception/interrupt [3]. for interrupt, mepc has to be set to current PC value.
(a) Property 440-466: mtval is written with exception-specific (4) Property 491-498: Exception and interrupt return update sta-
information to assist software in handling the trap, corre- tus correctly with MRET instruction. An MRET instruction
sponding to the exception, interrupt or NMI (example for is used to return from a trap in machine mode [3].
Breakpoint). (a) Property 491-494: By executing MRET when mpp=0, modify
InstValid && PipeReady && !DebugMode && Exception privilege bit mprv=0 and mpp=0.
&& ExcpFlag[19] |-> ##1 RegData_mtval == 32'd0 (b) Property 495-496: "1" is set to mpie when the state is re-
(b) Property 467-482: mcause is set to the exception code cor- turned to the previous state before the occurrence of a
responding to the exception, interrupt or NMI (example trap due to the MRET instruction.
for Breakpoint). (c) Property 497-498: The value held in mpie is restored in mie
InstValid && PipeReady && !DebugMode && Exception when the state is returned to the previous state before the
&& ExcpFlag[19] |-> ##1 RegData_mcause == 32'h3 occurrence of a trap due to the MRET instruction.
(3) Property 483-490: Exception and interrupt update status cor- (5) Property 499-500: Exception implies handled is verified with
rectly [5]. the following properties:

164

Authorized licensed use limited to: Indian Inst of Inform Technology Guwahati. Downloaded on December 16,2024 at 12:39:06 UTC from IEEE Xplore. Restrictions apply.
 Formal Verification of Security Properties on RISC-V Processors MEMOCODE ’23, September 21–22, 2023, Hamburg, Germany

DebugMode == 1'b1 ##1 DebugMode == 1'b0 |->

PrivMode == MachineMode
(c) Property 511: During processor reset regardless of any
circumstances. The property below is proven during reset,
which is different from the other properties.
PrivMode == MachineMode && !MstatusMIE &&
MstatusMPP == UserMode
(d) Property 512: When exception happens, privilege mode is
Figure 4: Mode transition set to machine mode.
exception_happen |-> ##1 PrivMode == MachineMode
(e) Property 513-515: When interrupt happen, privilege mode
(a) Property 499: If an exception appeared exception handler is set to machine mode under the conditions below[5]:
should be started, if conditions for exception start are (i) either the current privilege mode is M and the mie bit
fulfilled. in the mstatus register is set, or the current privilege
(b) Property 500: Exceptions are not being handled in absence mode has less privilege than machine mode;
of any request for exception. (ii) bit i is set in both mip and mie. mip bit high means a
(6) Property 501: Interrupt implies handled. When interrupt pending interrupt.
happens, interrupt_counter increase by 1 and eventually ((MachineMode && Mstatus_Mie) && ((Mip[3] &&
interrupt service routine occur. interrupt_counter is de- Mie[3]) || (Mip[7] && Mie[7]) || (Mip[11] &&
creased for every interrupt service routine start. Mie[11]) || (Mip[19] && Mie[19]))) |-> ##1
interrupt_counter!=6'd0 |-> strong PrivMode == MachineMode
(##[0:$] InstPC == InterruptTrapEntry) (3) Property 516-517 Transition into debug mode valid for:
(7) Property 502: Interrupt is disabled/enabled according to value (a) Property 516: From user mode in case of an halt request
of mie bit[5]. Interrupt taken is enabled when mie bit is high and when the hart control FSM permits it, change to debug
and disabled when mie bit is low. mode is done. Halt request is a request to halt execution
of a hart.
(|IntCause[31:3]) |-> IntTaken == MstatusMIE (b) Property 517: From machine mode in case of a halt request
(8) Property 503: The Interrupt bit in mcause is set if the trap and when the hart control FSM permits it, change to debug
was caused by an interrupt[5]. mode is done.
IntBrReq |-> ##1 RegData_mcauseINT (4) Property 518: When return from debug/machine mode, MRET
(9) Property 504: mepc register is written with the address of the update privilege mode with the previous mode saved.
instruction that was interrupted[5]. mret_occured |-> ##1 PrivMode == $past(MstatusMPP)
IntBrReq |-> ##1 RegData_mepc == $past(InstPC)
(10) Property 505: If frm is set to an invalid value (101–111), any 4.6 Physical Memory Protection
subsequent attempt to execute a floating-point operation PMP acts as an access control for physical memory region within
with a dynamic rounding mode is illegal. the RISC-V processor for instruction and data access. It also detects
illegal access to any out-of-range address. Each PMP entry consists
4.5 Mode Transition of an address register (pmpaddr) and a configuration (pmpcfg) as-
NS31A supports 2 privilege levels: user mode and machine mode. sociated with it as shown in Figure 5. The PMP entry 0 has the
Machine mode is mandatory for a RISC-V processor to allow low- highest priority for determining the access and the priority de-
level access to the implementation. User mode is used for conven- creases as the number gets higher. The functional correctness of
tional application. In NS31A, debug mode is implemented as an PMP is vital to provide security guarantee on a RISC-V processor
additional privilege mode with further access than the machine avoiding unwanted access to the memory or modification to the
mode which is used for off-chip debugging and manufacturing access permission.
test. Transition between modes [4] can only occur under specific pmpaddr stores the address registers which defines the memory
conditions and requirements. We formally verified correctness and range of the PMP entry and these address range is determined by
validity of transition between the privilege modes as follow: the addressing mode:
(1) Property 506-507: Transition into user mode valid for the • NA4 - Naturally aligned four-byte region
following: • NAPOT - Naturally aligned power-of-two region
(a) Property 506: From machine mode when MRET is executed. • TOR - Top of range
(b) Property 507: From debug mode after debug retires if user
mode is stored in dcsr before entering debug. pmpcfg consists of 8 bits each and 4 of these configuration are
(2) Property 508-515: Transition into machine mode valid for: combined to be stored as one CSR:
(a) Property 508: From user mode when hart state allows. • L - Lock bit indicates that the PMP entry is locked and con-
(b) Property 509-510: From debug mode immediately after figuration to the associated address registers are ignored.
debug retires. • A - Addressing modes are described on the paragraph above.

165

Authorized licensed use limited to: Indian Inst of Inform Technology Guwahati. Downloaded on December 16,2024 at 12:39:06 UTC from IEEE Xplore. Restrictions apply.
 MEMOCODE ’23, September 21–22, 2023, Hamburg, Germany Chuah, et al.

(3) Property 1079-1084: PMP access correctness through machine

mode and user mode are checked with the properties below:
(a) Property 1079-1081: If no PMP entry matches an M-mode
access, the access succeeds. We check that the PMP entry
does not fall under TOR, NA4 or NAPOT region.
Opcode==Pmp && !tor_in_region && !na4_in_region
&& !napot_in_region && LSPrivMode==MachineMode
&& !DebugMode |-> !LoadAccessFault
(b) Property 1082-1084: If no PMP entry matches an S-mode or
U-mode access, but at least one PMP entry is implemented,
the access fails. If at least one PMP entry is implemented,
but all PMP entries’ A fields are set to OFF, then all S-mode
and U-mode memory accesses will fail.
(4) Property 1085-1092: PMP violation - If there is PMP violation
Figure 5: PMP address and configuration (load access fault or store access fault), then for load there
should be no read on the target register and for store there
should be no write on the target register.
• R - Read bit control the read access permission of the PMP
entry. PipeRegEn && LoadAccessFault |-> ##1
• W - Write bit control the write access permission of the PMP RegData == $past(RegData)
entry.
• X - Execute bit control the execute access permission of the 4.7 Control Flow
PMP entry. It is very important that the PC is always set properly by the proces-
(1) Property 519-646: PMP locking functionality correctness is sor. Otherwise, wrong instructions could be fetched and executed,
checked with regards to the properties below: which could then be exploited by attackers to execute malicious
(a) Property 519-550: When PMP entry is locked, i.e., writes to code. We developed a new approach to formally verify the proper
the configuration register and associated address registers setting of the PC. Our PC properties evaluate the PC for each setting
are ignored (example for pmpcfg0). of the PC for a valid instruction into the pipeline register entering
RegData_Pmpcfg0.L |-> !pmpaddr0_WtVld WB stage. With this, we formally verify the PC setting for each in-
(b) Property 551-566: Locked PMP entries remain locked until struction that is executed in the processor and as a result we prove
the hart is reset (example for pmpcfg0). that the PC is always set correctly as implied on the specification. In
RegData_Pmpcfg0.L |-> addition to the properties for PC verification, we use some auxiliary
RegData_Pmpcfg0.L throughout !hartRst code. If a valid instruction enters the WB stage that sets the PC to
(c) Property 567-582: If PMP entry N is locked, writes to pmpcfgN a value other than PC +4, we save this in the verification environ-
and pmpaddrN are ignored (example for pmpcfg0). ment (e.g. for jal or executed branches). Besides that, we also store
RegData_Pmpcfg0.L |-> ##1 $stable all events which happen between a valid instruction entering WB
(RegData_PmpcfgRegs0[4:0]) stage and the next valid instruction entering WB stage, e.g. inter-
(d) Property 583-598: If PMP entry N is locked and pmpcfgN.A rupts. This information is then used to decide the correct PC for
is set to TOR, writes to pmpaddrN-1 are ignored (example the successor instruction of a valid instruction entering WB stage
for pmpcfg1). according to RISC-V specification. With the properties listed in the
RegData_Pmpcfg1.L && RegData_PmpcfgRegs1.A==TOR following, we then prove the correctness for setting the PC. The
|-> !pmpaddr0_WtVld properties below cover all possibilities of instructions and events
(e) Property 599-630: For NAPOT, writing to pmpaddrN is valid that can happen which would influence the setting of the PC.
if pmpcfgN.L=0 (example for pmpaddr0).
(1) Property 1093: For first executed instruction, PC has to be PC
!RegData_Pmpcfg0.L && RegData_Pmpcfg0.A==NAPOT
that should occur after reset.
&& RegData_Pmpcfg1.A!=TOR && CSRWrite
|-> pmpaddr0_WtVld firstInstruction && write_wb_pipe_reg &&
(f) Property 631-646: For TOR, writing to pmpaddrN-1 and !interrupt_appeared |-> wb_InstPC == resetPC
pmpaddrN is valid if pmpcfgN.L=0 (example for pmpcfg1).
(2) Property 1094: If previous instruction does not require other
RegData_Pmp1.L && RegData_Pmpcfg1.A==TOR &&
PC adaption and no special event appeared in between, stan-
CSRWrite |-> !pmpaddr0_WtVld && !pmpaddr1_WtVld
dard PC increment occur.
(2) Property 647-1078: PMP prioritization correctness for each
addressing mode and permission access combination are !firstInstruction && write_wb_pipe_reg &&
checked here. If a PMP entry matches all bytes of an access, !interrupt_appeared && !exception_appeared &&
then the L, R, W, and X bits determine whether the access !last_jal && !last_jalr && !last_mret &&
succeeds or fails. If it falls in more than one region, it matches !last_branch_taken && !debug_return
the permission in the lowest region. |-> wb_InstPC == lastWbPC +4

166

Authorized licensed use limited to: Indian Inst of Inform Technology Guwahati. Downloaded on December 16,2024 at 12:39:06 UTC from IEEE Xplore. Restrictions apply.
 Formal Verification of Security Properties on RISC-V Processors MEMOCODE ’23, September 21–22, 2023, Hamburg, Germany

(3) Property 1095: Prove for correct PC set when an interrupt values transferred to memory by load or store operations. We for-
occurred. mally verified the properties below for correctness of the load and
write_wb_pipe_reg && interrupt_appeared store instruction.
|-> wb_InstPC == interruptEntry (1) Property 1135-1140: In memory stores, the value sent to the
(4) Property 1096: Prove for correct PC set when an exception memory subsystem is exactly the value of the register speci-
occurred. fied in the store instruction. Our properties prove that the
rightmost bits of the register are sent to Load Store Unit
write_wb_pipe_reg && exception_appeared
according to the target address.
|-> wb_InstPC == exceptionEntry
(dataoffset_lsuBusReqAddr == 2'h01 && InstValid
(5) Property 1097: Prove for correct PC set when returned from
&& Opcode == Store) |-> (BusReqWtData ==
debug mode.
{RegData[InstCode[rs2]][23:0], 8'h00});
write_wb_pipe_reg && debug_return
(2) Property 1141-1145: In memory loads, the value stored in
|-> wb_InstPC == csrDpc
the target register is exactly the value from the memory
(6) Property 1098: Prove for correct PC set when previous in- subsystem.
struction was jal instruction. (3) Property 1146: The address sent to the memory subsystem
!firstInstruction && write_wb_pipe_reg is exactly the effective address given the GPR values and
&& last_jal |-> wb_InstPC == jal_nextPC instruction contents (i.e., addressing mode and immediate).
(7) Property 1099: Prove for correct PC set when previous in- (Opcode == Store && (Funct3 == SW||SH||SB) ||
struction was jalr instruction. (Opcode==Load && (Funct3==LW||LH||LB||LHU||LBU)))
!firstInstruction && write_wb_pipe_reg |-> (BusReqAddr == (RegData[rs1] + Immediate));
&& last_jalr |-> wb_InstPC == jalr_nextPC
(8) Property 1100: Prove for correct PC set when previous in-
5 RESULTS
struction branch was taken. We identified and formally verified 1146 properties that are grouped
under 9 categories as shown in Table 4 using Jasper formal veri-
!firstInstruction && write_wb_pipe_reg
fication tool. Some design bugs have been discovered during our
&& last_branch |-> wb_InstPC == branch_nextPC
formal verification experiments with Jasper. A counterexample is
(9) Property 1101: Prove for correct PC set when previous in- provided for each violation trace for debugging purpose by Jasper.
struction was MRET. The property violations will be explained and discussed below. Run-
!firstInstruction && write_wb_pipe_reg time for these verification experiments ranges between 0.01s to
&& last_mret |-> wb_InstPC == mret_nextPC 4000s depending on complexity of the property, besides the Control
Flow properties. For the Control Flow properties, all properties be-
4.8 Register Update sides the properties for the standard PC increment (Property 1094)
Register acts as a temporary storage of instruction, data or address. and the property for the MRET (Property 1101) instruction could be
Some registers serve for a special own purpose in RISC-V, for in- verified successfully within 24 hours. The two properties mentioned
stance register x0 is fixed to 0, register x1 holds the return address could not be verified successfully in less than 48 hours. We applied
for a call and register x2 is a stack pointer. Other registers are blackboxing of some submodules of the processor for verification
available for general purpose usage such as function arguments, of the standard PC increment and the MRET property and with this,
saved register or temporaries. Any alteration of the register value those properties could also be proven successfully within 24 hours.
could lead to undesired functionality change or even denial of ser-
vice, e.g. if stack pointer maliciously modified. Hence, we prove the Table 4: Formal Verification Results
following properties for register updates.
(1) Property 1102: The register update as the result of executing Properties
an instruction is the register specified as the target register Categories SVA Pass Fail
by the instruction. Instruction Execution 10 10 0
WbWriteReg |-> RegBankWbEn && Control and Status Register 394 280 114
(RegBankWbRd[4:0] == InstCode[11:7]); Debug Operation 14 14 0
Exception, Interrupt and Trap Handling 87 87 0
(2) Property 1103-1134: Register change implies that it is the
Mode Transition 13 13 0
instruction target (example for GPR 1).
Physical Memory Protection 574 574 0
true ##1 RegData1[31:0] != $past(RegData1[31:0]) Control Flow 9 8 1
|-> $past(InstCode[11:7] == 5'd1); Register Update 33 33 0
Memory Access 12 12 0
4.9 Memory Access Total 1146 1031 115
Memory access in RISC-V is done through the load and store in-
structions. Attackers often target these instructions to modify the

167

Authorized licensed use limited to: Indian Inst of Inform Technology Guwahati. Downloaded on December 16,2024 at 12:39:06 UTC from IEEE Xplore. Restrictions apply.
 MEMOCODE ’23, September 21–22, 2023, Hamburg, Germany Chuah, et al.

5.1 Counterexample 1 [3] 2020. NSITEXE NS31A Technical Reference Manual, Document Version
NRV31210000-00-E Revision 1.0.2. Technical Report. NSITEXE, Inc.
For Property 229-285, we have proven noncompliance with speci- [4] Waterman Andrew and Asanović Krste. 2019. The RISC-V Instruction Set Manual,
fication. According to the RISC-V specification [4], if rd=x0, then Volume I: User-Level ISA, Document Version 20191213. Technical Report. RISC-V
Foundation.
the instruction CSRRW or CSRRWI shall not read and shall not [5] Waterman Andrew, Asanović Krste, and Hauser John. 2021. The RISC-V Instruc-
cause any of the side effects that might occur on a CSRRW or CSR- tion Set Manual, Volume II: Privileged Architecture, Document Version 20211203.
RWI read. However, current NS31A allows the read access to the Technical Report. RISC-V International.
[6] Padmaja Bhamidipati, Shanmukha Murali Achyutha, and Ranga Vemuri. 2021.
CSRRW or CSRRWI even if rd=x0. This is not consistent to the Security Analysis of a System-on-Chip Using Assertion-Based Verification. In
RISC-V Specification, and is considered as erratum. 2021 IEEE International Midwest Symposium on Circuits and Systems (MWSCAS).
826–831. https://doi.org/10.1109/MWSCAS47672.2021.9531916
[7] Michael Bilzor, Ted Huffmire, Cynthia Irvine, and Tim Levin. 2011. Security
5.2 Counterexample 2 Checkers: Detecting processor malicious inclusions at runtime. In 2011 IEEE
For Property 286-342, we have proven noncompliance with spec- International Symposium on Hardware-Oriented Security and Trust. 34–39. https:
//doi.org/10.1109/HST.2011.5954992
ification. According to the RISC-V specification [4], if rs1=x0 or [8] Michael Bilzor, Ted Huffmire, Cynthia Irvine, and Tim Levin. 2012. Evaluating
uimm=0, then the instruction CSRRS/C or CSRRS/CI shall not write security requirements in a general-purpose processor by combining assertion
checkers with code coverage. In 2012 IEEE International Symposium on Hardware-
and shall not cause any of the side effects that might occur on a Oriented Security and Trust. 49–54. https://doi.org/10.1109/HST.2012.6224318
CSRRS/C or CSRRS/CI write. However, current NS31A allows the [9] M. Blum and H. Wasserman. 1996. Reflections on the Pentium division bug. IEEE
write access to the CSRRS/C or CSRRS/CI even if rs1=x0 or uimm=0. Trans. Comput. 45, 4 (April 1996), 385–393. https://doi.org/10.1109/12.494097
[10] Kevin Cheang, Cameron Rasmussen, Dayeol Lee, David W. Kohlbrenner, Krste
This is not consistent to the RISC-V Specification, and is considered Asanović, and Sanjit A. Seshia. 2022. Verifying RISC-V Physical Memory Protec-
as erratum. tion. arXiv:2211.02179 [cs.CR]
[11] Federal Office for Information Security. [n. d.]. Evaluation Assurance
Level (EAL). https://www.bsi.bund.de/EN/Themen/Unternehmen-
5.3 Counterexample 3 und-Organisationen/Standards-und-Zertifizierung/Zertifizierung-und-
Anerkennung/Zertifizierung-von-Produkten/Zertifizierung-nach-CC/IT-
For Property 1101 on the PC verification, we discover a bug that Sicherheiskriterien/CommonCriteria_v31/eal_stufe.html
occurs when a MRET instruction is in the WB stage and additionally [12] Tora Fridholm. 2023. Codasip and IAR Demonstrate Dual-Core Lockstep for RISC-
an exception appears, while the CPU is in debug mode. As the V. codasip.com/press-release/2023/03/14/codasip-and-iar-demonstrate-dual-
core-lockstep-for-risc-v/
processor is in debug mode, the next PC should here not be the [13] Matthew Hicks, Cynthia Sturton, Samuel T. King, and Jonathan M. Smith. 2015.
PC for the exception, but the successor PC is decided by the MRET SPECS: A Lightweight Runtime Mechanism for Protecting Software from Security-
instruction. Nevertheless, we found a scenario where the PC was Critical Processor Bugs. In Proceedings of the Twentieth International Conference on
Architectural Support for Programming Languages and Operating Systems (Istanbul,
the PC of the exception handler. Turkey) (ASPLOS ’15). Association for Computing Machinery, New York, NY,
USA, 517–529. https://doi.org/10.1145/2694344.2694366
6 CONCLUSION [14] Mark D. Hill, Jon Masters, Parthasarathy Ranganathan, Paul Turner, and John L.
Hennessy. 2019. On the Spectre and Meltdown Processor Security Vulnerabilities.
As conclusion, in our work we identified a comprehensive set of IEEE Micro 39, 2 (March 2019), 9–19. https://doi.org/10.1109/MM.2019.2897677
[15] Binod Kumar, Akshay Kumar Jaiswal, V S Vineesh, and Rushikesh Shinde. 2020.
security-critical properties within the specification and microar- Analyzing Hardware Security Properties of Processors through Model Checking.
chitecture in a RISC-V processor and formally verified them using In 2020 33rd International Conference on VLSI Design and 2020 19th International
formal verification. We grouped our security-critical properties in Conference on Embedded Systems (VLSID). 107–112. https://doi.org/10.1109/
VLSID49098.2020.00036
9 groups and elaborated them in detail. Our set of security-critical [16] Inc NSITEXE. [n. d.]. NS31A : RISC-V 32bit CPU Which Supports ISO26262 ASIL D.
properties and their formal verification enables to increase the www.nsitexe.com/en/ip-solutions/ns-series/ns31a/
security-level of RISC-V processors considerably, which is a very [17] Jasper Formal Verification Platform. [n. d.]. Jasper RTL Apps | Cadence - Cadence
Design Systems. https://www.cadence.com/en_US/home/tools/system-design-
important work due to the growing dispersion of RISC-V processors. and-verification/formal-and-static-verification/jasper-gold-verification-
The verification results also show that formal verification scales platform.html
[18] Alastair David Reid, Rick Chen, Anastasios Deligiannis, David Gilday, David
well for most of the properties. For a few properties, we had to apply Hoyes, Will Keen, Ashan Pathirane, Owen Shepherd, Peter Vrabel, and
additional abstraction techniques like blackboxing, to obtain proofs. Ali Mustafa Zaidi. 2016. End-to-End Verification of ARM ® Processors with
For future work, we intend to extend our verification on security- ISA-Formal. https://api.semanticscholar.org/CorpusID:45478983
[19] Renesas. 2023. Renesas Expands RISC-V Embedded Processing Portfolio with
critical properties to formal verification of absence for Hardware New Voice-Control ASSP Solution. www.renesas.com/br/en/about/press-
Trojans. Additionally, we intend to research the usability of our room/renesas-expands-risc-v-embedded-processing-portfolio-new-voice-
properties as runtime monitors to increase security guarantees control-assp-solution
[20] Newsome Time and Wachs Megan. 2022. The RISC-V External Debug Support
during processor operation. Version 0.13.2. Technical Report. RISC-V International.
[21] Clifford Wolf. 2017. End-to-end formal ISA verification of RISC-V processors
with riscv-formal. 7th RISC-V Workshop Proceedings.
ACKNOWLEDGMENTS [22] Rui Zhang, Natalie Stanley, Christopher Griggs, Andrew Chi, and Cynthia Sturton.
This work was partially funded by the Federal Ministry of Education 2017. Identifying Security Critical Properties for the Dynamic Verification of
a Processor. SIGARCH Comput. Archit. News 45, 1 (apr 2017), 541–554. https:
and Research (BMBF) under the DIVA-IC project with funding code //doi.org/10.1145/3093337.3037734
FKZ:16ME0279

REFERENCES
[1] 2017. Common Criteria for Information Technology Security Evaluation, Version
3.1, revision 5. Technical Report. Common Criteria.
[2] 2018. IEEE Standard for SystemVerilog–Unified Hardware Design, Specification,
and Verification Language. IEEE Std 1800-2017 (Revision of IEEE Std 1800-2012)
(Feb 2018), 1–1315. https://doi.org/10.1109/IEEESTD.2018.8299595

168

Authorized licensed use limited to: Indian Inst of Inform Technology Guwahati. Downloaded on December 16,2024 at 12:39:06 UTC from IEEE Xplore. Restrictions apply.