SOURCE ARCHIVE
EXTRACTED CONTENT
83,517 charsPOLITECNICO DI TORINO Repository ISTITUZIONALE
A Survey of Recent Developments in Testability, Safety and Security of RISC-V Processors
Original A Survey of Recent Developments in Testability, Safety and Security of RISC-V Processors / Anders, J., Andreu, P., Becker, B., Becker, S., Cantoro, R., Deligiannis, N., Elhamawy, N., Faller, T., Hernandez, C., Mentens, N., Namazi Rizi, M., Polian, I., Sajadi, A., Sauer, M., Schwachhofer, D., SONZA REORDA, M., Stefanov, T., Tuzov, I., Wagner, S., Zidaric, N.. - (2023), pp. 1-10. (2023 IEEE European Test Symposium (ETS) Venice (Italy) 22-26 May 2023) [10.1109/ETS56758.2023.10174099]. Availability: This version is available at: 11583/2978944 since: 2023-05-30T20:36:24Z
Publisher: IEEE
Published DOI:10.1109/ETS56758.2023.10174099
Terms of use:
This article is made available under terms and conditions as specified in the corresponding bibliographic description in the repository
Publisher copyright IEEE postprint/Author's Accepted Manuscript
©2023 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collecting works, for resale or lists, or reuse of any copyrighted component of this work in other works.
(Article begins on next page)
19 June 2026
A Survey of Recent Developments in Testability, Safety and Security of RISC-V Processors
Jens Anders∗∗ , Pablo Andreu¶, Bernd Becker∗ , Steffen Becker∥ , Riccardo Cantoro† ,
Nikolaos I. Deligiannis† , Nourhan Elhamawy‡ , Tobias Faller∗ , Carles Hernandez¶, Nele Mentens§ , Mahnaz Namazi Rizi§, Ilia Polian‡ , Abolfazl Sajadi§ , Mathias Sauer††, Denis Schwachhofer‡ , Matteo Sonza Reorda† , Todor Stefanov§ , Ilya Tuzov¶, Stefan Wagner∥ , Nuša Zidariˇc§ ∗Dpt. of Computer Science, University of Freiburg, Freiburg, Germany ‡Institute of Computer Architecture and Computer Engineering, University of Stuttgart, Stuttgart, Germany †Dpt. of Control and Computer Engineering, Politecnico di Torino, Turin, Italy §LIACS, Leiden University, Leiden, Netherlands ¶Universitat Politècnica de València, Spain ∥Institute of Software Engineering, University of Stuttgart, Stuttgart, Germany ∗∗Institute of Smart Sensors, University of Stuttgart, Stuttgart, Germany ††Advantest Europe, Boeblingen, Germany
Abstract—With the continued success of the open RISC-V archi- implementation, as shown in Table I, is abbreviated as: (i) the
tecture, practical deployment of RISC-V processors necessitates base (e.g., RV32I, RV32E etc.) and (ii) the extensions that are
an in-depth consideration of their testability, safety and security supported (each letter represents an extension [3]). For instance
aspects. This survey provides an overview of recent developments
in this quickly-evolving field. We start with discussing the the PicoRV32 core implements the base integer ISA of 32-bits
application of state-of-the-art functional and system-level test (RV32I) and the base integer ISA of 32-bits, using 16 registers
solutions to RISC-V processors. Then, we discuss the use of RISC- (RV32E) and supports the integer multiplication and division
V processors for safety-related applications; to this end, we outline (M) extensions and the compressed instructions (C), hence the
the essential techniques necessary to obtain safety both in the ISA string RV32IEMC.
functional and in the timing domain and review recent processor
designs with safety features. Finally, we survey the different aspects Table I: Selected RISC-V cores: academic and open source
of security with respect to RISC-V implementations and discuss
the relationship between cryptographic protocols and primitives Core ISA # st. Comments Interface Tech. Ref.
Rocket RV64G,C 5 variable cache, opt. L2, Tilelink Crossbar, RoCC ASIC✓ [4]
on the one hand and the RISC-V processor architecture and MMU, b.p. [5]
hardware implementation on the other. We also comment on the BOOM RV64G,C variable cache, opt. Tilelink Crossbar, RoCC, ASIC✓ [6]
(v1/v2/v3) 6/9/11 L2, MMU, b.p., OoO integrated RoCC FPGA [7]
role of a RISC-V processor for system security and its resilience Ibex RV32 I/E, 2 + 1 opt. b.p., OpenHW eXtension, FPGA [8]
against side-channel attacks. (Zero−RI5CY) C,M,B opt. L0, LSU PULP AXI4, APB, crossbar ASIC✓ [9]
CV32E40P RV32IMC 4 opt. L0, LSU, AXI4, APB, crossbar ASIC✓ [10]
Index Terms—RISC-V, functional and system-level test, safety- (RI5CY) F opt. L2, ‡ PULP
CVA6 RV64GC 6 variable cache, AXI4, APB, ASIC✓ [11]
related applications, cryptography, secure execution (Ariane) RV64IMC LSU, b.p., ⊕ PULP
VexRiscv RV32I 2 + 3 opt. I/D cache, AXI4, Avalon, wishbone FPGA [12]
MAFDC opt. LSU, OoO ASIC✓ [13]
I. Introduction PicoRV32 RV32I 1 opt. I/D cache AXI4, MM, PCPI FPGA [14]
EMC ASIC [15]
RISC-V is an open, load-store instruction set architecture SCARV RV32IMC 5 side-channel hardened, mem. mapped FPGA [16]
LSU, ASIC
(ISA) based on well-known and established RISC principles SweRV RV32IMC 4 ultra-low-power core, AXI4, AHB-Lite, FPGA [17]
(VeeR EL2) I cache mem. mapped ASIC [18]
that is provided under open source licenses. RISC-V was # st. – number of pipeline stages + optional stages opt. – optional features
b.p. – branch prediction OoO – Out-of-Order
developed by the researchers of the Berkeley Architecture ‡ – manycore possible or only manycore ⊕– in-Order issue, commit, OoO write back
L0 – prefetch buffer for I cache ✓– fabricated
Research laboratory and began with a goal to make a practical
ISA that is open-source, usable academically, and deployable in In Table I we list selected RISC-V cores, with focus on
any hardware or software design without royalties. In the past academic and open source designs. In the first two columns we
decade, the RISC-V universe expanded and started conquering list the core and supported base ISA and possible extensions.
markets beyond personal computers, such as transportation and Then we list number of pipeline stages and some of the
industrial [1]. One of the greatest advantages is the open ISA, implemented core features, e.g., branch prediction or out-
which allowed a strong RISC-V community to emerge [2]. of-order execution, and available interfaces; the latter is of
The ISA specification defines XLEN = 32/64/128 address importance for System-on-Chips (SoCs), ISA extensions and
space variants and “mandates" a convenient, modular processor coprocessor designs. Finally we provide technology with ✓
design, consisting of alternative base parts with added optional denoting fabricated ASIC chips.
extensions. Although there are standard open and ratified Recently, several surveys have emerged to cover the current
ISA extensions, RISC-V allows custom extensions to be state-of-the-art in RISC-V developments and features. For
defined as well, e.g., PULP extension. The RISC-V ISA of an a comparative survey of selected open-source cores listing
benchmark and maximum frequency, core area, and power knowledge of the underlying architecture and expensive project
consumption for both FPGA and ASIC technologies see [2]. time - often months - to achieve a satisfying test coverage. In
The survey in [19] is focusing on open-source hardware inte- many instances, specific test details have to be derived from
gration of machine learning applications (ML). Authors of [1] the hardware architecture implementation. Depending on the
classified the RISC-V software ecosystem into four categories: test, these details span from register initialization sequences
application fields (space systems, IIoT, AI-based heterogeneous up to reasoning about fault propagation paths.
systems), RISC-V implementations (soft-cores, System-on- RISC-V offers a modular and fully customizable ISA
Chip (SoC), emulators and simulators), software architecture specification that features a variety of pre-defined extensions.
(bare-metal, OS, development tools), and deployment features Combining the base ISA with a set of extensions enables de-
(security, reliability, low-power). The survey in [20] presents signs ranging from power-efficient embedded microcontrollers
ISA extensions designed by the RISC-V community and the to high-performance chip designs. This modular structure of
progress of official RISC-V ISA extension specifications. Abella the RISC-V ISA leads to an incremental processor design.
et al. [21] provided an overview of why RISC-V is successful Consequently, the development of SBSTs is led alongside the
and some contributions on RISC-V and security against side- incremental implementation of each ISA extension. As the
channel attacks, a dual core LockStep system with diverse ISA extensions form defined boundaries of SBST modules the
redundancy, and System-Level Test. reuse of those software modules for other RISC-V cores is
In this paper, we survey the recent developments around encouraged.
RISC-V with focus on the following aspects: test, safety, For example, both RI5CY and Zero-RI5CY cores (see
and security. More specifically, in the area of functional Table I) implement the RV32I base specification and the M test in Section II, we focus on test generation methods for extension. Hence, it is reasonable to assume that some parts Software-Based Self-Test, Burn-In and System-Level Test and test structures of the same STLs can be re-used for both and the first steps in the development of a model of non- cores as shown in Figure 1. Though, when re-using the tests functional properties of hardware. Then, in Section III, we for a different implementation a loss in test coverage is to describe the potential and existing solutions of RISC-V for be expected. Nevertheless, with reduced effort a test engineer safety-related applications, with focus on functional correctness can extend and port the existing tests and merely develop and timing verification. Finally, in Section IV, we provide an additional tests for the remaining, not yet-covered C and F overview of RISC-V security from the cryptographic, hardware extensions supported by the RI5CY core. Although porting and ISA perspective, focusing on the granularity of added is possible, the reader should note that even though the two hardware and added custom ISA extensions in the context of systems implement the same ISA extensions, hard-to-test faults hardware/software co-design, and conclude the section with are architecture-dependent [23]. RISC-V system security. II. RISC-V and Functional Test M C F In this section we present how RISC-V is able to support research on generating functional tests. In Section II-A we RV32I start with the challenges of generating Software-Based Self- Test (SBST) and Burn-In (BI) programs and how the RISC-V Test specification and ecosystem can help there. M Programs Afterwards, we move from SBST to System-Level Test RV32I (SLT) in Section II-B, where we show how the open-source nature of RISC-V and the tools it spawned support research Figure 1: Reuse of SBSTs for designs with overlapping ISAs in automated test program generation. Here we explain why it is difficult to use traditional testing methods for SLT and The architecture dependency of hard-to-test faults implies a why a greybox approach to generating tests becomes necessary. high complexity for test generation. For each new architecture, Then, we go into detail on how an open-source SoC generation the development effort for testing hard-to-test faults has to framework supports the development of a high-level model of be repeated. On top of that, the non-intuitive fault behavior non-functional properties of hardware. and propagation make manual development unfeasible. There- A. RISC-V and Functional Test Development fore, tool-aided, automatic SBST development is required for targeting these faults. Software-Based Self-Test (SBST) [22] allows at-speed, native In the context of test generation, formal methods like in-field testing of processors with respect to permanent faults bounded model checking (BMC) provide a facility to find test by running software programs on the processor core, requiring sequences for hard-to-test faults under functional constraints. no Design for Testability (DfT) infrastructure and averts over- The test engineer formalizes these functional constraints in testing of manufactured chips. It is well known that the manual a test specification. This test specification models the set development of SBST programs (also known as Self Test of valid test behaviors that are allowed to be generated by Libraries, or STLs) is an arduous task that requires in-depth the BMC solver. This test specification, among other things,
includes the set of allowed instructions as specified by the functional test programs. ISA, allowed Control and Status Registers (CSRs) accesses and configurations, and the memory model. B. How RISC-V supports research in System-Level Test Except for the most recently developed extensions, all parts of the official RISC-V ISA exist as formal specifications A LA and build a ground truth for the RISC-V ecosystem of tools. (Ep Wafer (Ep (pS According to the use case, these specifications are combined Manufacturing sort and inserted into various processes exploiting their reusability. Similarly, these formal specifications are reusable for test ATE generation and allow for the automatic derivation of large £229 = parts of the test specification. Hence, RISC-V’s open-source GH and openly available ISA specifications lay the groundwork r= for automated SBST generation per extension module. Technology It has been shown that SBST generation embedding parts improvement of the formal RISC-V specification allows for rapid tool-aided SBST development targeting hard-to-test faults in scalar, single- Figure 2: Test flow including System-Level Test (SLT) [29] issue pipelined processor core modules [24]. Depending on the supported ISA extensions of the processor core, a test System-Level Test (SLT) has emerged as an additional specification is derived in a modular fashion. By transforming test step in the last decade [30]. It is used to improve the the required specification parts into a test specification and quality assurance of complex SoCs, as traditional testing is not combining them with comparatively few additional constraints, sufficient anymore. Figure 2 shows that SLT is executed as the a test procedure can be developed incrementally. The additional very last step after Final Test. constraints are SoC architecture-specific and include parameters SLT tries to approximate the end-user environment of the like memory regions and exception handling. Additionally, the DUT as closely as possible. For example, a smartphone test procedure type is specified depending on the environment SoC might be placed into a board that resembles an actual the SBST is run. This environment can be a small-scale test smartphone, plus some monitors and sensors to observe the after tape-in during development where the SoC is embedded non-functional properties of the SoC. A test engineer or a into a custom test bench and the SoC’s outputs are accessible; system then boots an operating system, in the above example, or an at-speed end-of-manufacturing test under harsh conditions it might be Android or iOS, and checks for unexpected behavior. to test for infant mortality of chips by artificially aging them If that is not the case, more applications that are typical in the (Burn-In test); or a timed self-test of chips in-field during DUT’s mission mode are executed, e.g., a video is streamed operation to detect degradation due to electromigration and onto the device or a browser is started. The DUT is considered fatigue caused by external stress. defective if, at any point, unusual events such as a crash or Burn-In test (BI) [25], is omnipresent in the safety-critical unexpected errors occur. During SLT, the DUT is considered a domain. More specifically, dynamic BI methodologies require blackbox. This is due to the complexity of these SoCs but also functional stress-inducing stimuli. For the case where the due to the fact that some Intellectual Properties are locked, and devices under test (DUTs) are RISC-V processors [26], the only I/O interfaces and behavioral descriptions are provided. stimuli generation process can be greatly aided and guided by There are some issues with this approach. In particular, these the incremental ISA structure. For instance, such a process test suites are currently manually composed by test engineers. requires the identification of the appropriate vectors (i.e., Furthermore, the quality of those cannot be determined be- assembly instructions) in order to compose a typically short forehand, as the only available metric is a simple pass/fail. and stress-effective program for the DUT. That is, a program So the defect level and diagnosis of returned ICs are used to that is able to maximize the number of logical switches in short determine the quality of the suite after the fact. Finally, typical periods of time. By having a clear reference of the implemented testing times for SLT are ranging from 15 min to up to 2 h and sub-set of instructions then we can rely on strategies (e.g., SAT- SLT programs are also very large compared to structural tests solvers [27], evolutionary algorithms [28]) to identify such or SBST. sequences and an efficient stress program for the DUT. With the above issues, it is unfeasible to use traditional Overall, RISC-V’s formal specifications are a cornerstone methods such as fault simulation to gauge the quality of for functional test constraint derivation e.g., the ISA itself, the test suite. Instead, different metrics and approaches for CSR behavior, and the memory model, directly providing the generating shorter SLT programs are developed [29]. One transition from a specification to functional test generation. important factor in generating these tests is that we want RISC-V eases the complexity of STL development by pro- to control non-functional properties, such as temperature or viding an open, modular, well-organized ISA as well as an power consumption, of our DUT because some defects that ecosystem of tools (e.g., compiler, instruction set simulator, are assumed to be detected exclusively by SLT are marginal virtual prototype) that can be used alongside electronic design defects [31]. The detection of this kind of defects depends on automation (EDA) software to develop and validate RISC-V certain requirements, such as having a component at a specific
temperature or a temperature gradient between components or defects and can figure out a way to imitate the conditions a specific sequence of interactions that can only happen in the in which they manifest themselves. Causes of these marginal mission mode of the DUT. defects are still unknown, but by having such insights we might Writing SLT programs that control non-functional properties be able to find solutions to mitigate them and generalize the by hand requires a lot of time and knowledge about the archi- behavior of these. tecture of the DUT, which makes it infeasible in practical use. On top of that, by having this transparency of the architecture, Instead, there is ongoing research on methods to automatically we can develop the SLT snippets to target specific peripherals generate program snippets that are able to reliably control these or specific areas in the core that we believe to be problematic. properties. To develop these methods, it is necessary to analyze Therefore, the SLT snippets can be developed as compact multiple different architectures. This is where an open-source as possible, reducing the test times but maintaining the fault SoC generator framework called Chipyard [5] can help. coverage or even achieving a higher fault coverage. Furthermore, in Section II-A, we already showed how we We also had a chance to compare a RISC-V design with can easily derive constraints for methods such as evolutionary and without DfT structures. We draw the conclusion that DfT algorithms from the freely-available specification. This is useful structures are needed to facilitate the traditional structural test for SLT program generation as well. For example, we can use insertions as well as the SLT test insertion by speeding up the greybox-based methods that are guided by feedback to generate simulation process, having full controllability and observability program snippets that optimize a specific non-functional of the DUT and resulting in much higher fault coverages than property of our DUT [32]. These methods include genetic without DfT structures. This visibility is what helps to identify programming [33] or mutation-based greybox fuzzing [34]. more faults and gives the insight on possible causes of a defect. Chipyard has the distinct advantage that it allows us to The freely available RISC-V specification and the rich freely configure SoCs based on either an in-order (Rocket [4], ecosystem of open-source cores and tools allow researchers to CVA6 [11] Ibex [8] and an educational core called Sodor) work on functional program generation easily by, on the one or out-of-order (BOOM [35]) core or even mix both. For hand, enabling them to easily derive constraints to automatically example, we can add or remove caches and change their size generate valid assembly snippets, and, on the other hand, or modify aspects of the cores themselves, such as the number allow to analyze and use architectures for different application of issues in the BOOM core, the size of the return order scenarios to extract common and architecture-specific features buffer, and much more. We can also freely enable or disable to guide test program generation. extensions and choose between a 32-bit and 64-bit architecture. The flexible configurability allows us to examine multiple configurations for real-world different scenarios, e.g., embedded III. RISC-V for Safety-related Applications processors or high-end smartphone SoCs, and identify common and architecture-specific features to derive a generic model of In the context of safety-critical systems several different non-functional properties to use for SLT program generation. ISAs are widely used in different applications domains. Some Additionally, there is a wide range of well-tested periphery illustrative examples are the case of the SPARC [36] for space, available that we can utilize as well to test interactions between the Tricore [37] in the automotive domain, and the PowerPC the core and the periphery. And, due to the open-source nature in avionics and aerospace. Recently, ARM processors [38] of Chipyard, we are able to add our own periphery and make have also increased their presence in safety-critical domain changes to existing ones, such as, for example, bus monitors, applications allowing safety-critical application developers to observe activity on all the buses in the DUT. We can use enjoying from the wide ARM software ecosystem. this as feedback for a fuzzer to, for example, maximize the In this context, RISC-V arises as a great opportunity to break contention on each bus or cover all the possible transactions the existing safety-critical system fragmentation, and many with all possible sources and destinations. industrial players in the safety-critical domain have shown their Chipyard already supports many of the designs listed interest in RISC-V. The modularity, openness, and flexibility in Table I. As several of these designs are also compatible with of RISC-V are the key features for its potential success in traditional ASIC design flows, it is possible to extract more safety-critical systems. However, the adoption of RISC-V is information such as power simulations, map them to an FPGA also subject to having processor architectures that meet the to speed-up simulation time and get hardware measurements, stringent needs for certification of functional safety products. and extract additional insight by adding output of bus monitors Currently, the RISC-V functional safety special interest group as feedback for the aforementioned greybox monitors. is working on a white-paper covering the best practices for Moreover, the RISC-V tools and cores are easy to set the design of RISC-V processors safety-related applications. up with other commercial tools for further development and The following two subsections about functional correctness investigation. This allows us to work on new, more elaborate (Section III-A) and timing verification (Section III-B) elaborate metrics to evaluate the performance of the different SLT on the impact of the functional safety in the design of RISC-V snippets. Not just for non-functional properties but also for based processors. Finally, in the last Section III-C, we review standard fault models (e.g., stuck-at or transition fault delays). some of the existing RISC-V processors targeting safety-critical Thus, we have some insights into possible causes for marginal applications.
A. Functional Correctness impact of implementation technology. The functional safety measures at hardware level commonly B. Timing Verification include fault tolerance, error detection and correction mecha- Functional safety certification processes impose several nisms. First of all, the processor internal memory structures, requirements to the software development and validation such as register files and L1/L2 caches, must be protected processes [47]. Several of these requirements are related to the with error correction codes (ECC) [39]. Single-error correction timing behaviour of applications and are tightly coupled with and double-error detection (SECDED) Hamming codes are the characteristics of the processor in which the software is commonly considered in this context because of their moderate executed. In general, and regardless of the functional safety resource and performance overheads [40]. Likewise, the internal application domain, the execution time of software needs to be interconnect and external communication buses are subject to bounded at the unit level and to enable a reliable integration ECC protection. of such elements the hardware/software architecture must The replication of entire on-chip components is another ensure freedom from interference at the scheduling level. These widely-used technique to detect and correct hardware faults. software requirements are usually translated into the need The basic fault detection capabilities are achieved by dual of deriving the worst-case execution time (WCET) for each modular redundancy. In multicore processors it is typically software unit and the need for temporal and spatial isolation implemented in the form of dual-core lockstep (DCLS) [41], a between the different software items. mechanism that executes the same program on two CPU cores WCET derivation is challenged by the presence of hardware in parallel, compares cores outputs at each clock cycle and features that introduce execution time variability such as caches signals any discrepancies. Some lockstep processors allow and shared resources. Thus, processor designs targeting safety- flexible usage of the redundant (slave) cores, providing a critical applications need to implement specific features targeted lock mode for reliable execution of critical applications, and to control, reduce or completely remove such execution time split mode for high-performance execution of non-critical variability and achieve a predictable behaviour. For instance, applications [42]. The triple-modular redundancy (TMR) or execution time predictability can be attained by replacing higher multiplicity replication schemes, for instance triple-core caches by scratchpads or by implementing restrictive policies lockstep [43], enable real-time error correction. for resource sharing such as time-division multiplexing [48]. The diverse execution of the replicated cores plays an However, in general, achieving constant execution time in important role in any replication scheme, whenever it is specific resources comes at the expense of computing per- supposed to prevent common-mode failures. Diversity can formance and/or flexibility which is not acceptable in many be introduced at ISA and/or microarchitectural levels, resulting application domains. Thus, the current trend towards attaining in heterogeneous fault-tolerant CPU architectures [44]. These predictability in complex hardware platform relies on the use solutions, however, are often considered impractical due to of timing monitoring and quota enforcement policies [49]. their increased cost and complexity of software running on Resource partitioning can be implemented with software only top of heterogeneous cores. A more affordable (low-overhead) means and with both hardware and software support. How- approach for diverse redundancy is time staggering mecha- ever, fine-grain and performance efficient partitioning requires nism, which introduces controlled inter-core delay to ensure specific hardware support. In that respect, the RISC-V ISA that replicated (homogeneous) CPU cores execute different has defined the H extension for virtualization. The H extension instructions at any given time instant. enables the execution of unmodified OS as hypervisor guests Additional fault detection mechanisms, commonly provi- and thus, the co-existence of applications with heterogeneous sioned in dependable CPU architectures, include watchdog needs in terms of performance and criticality. Unfortunately, timers, performance monitoring (profiling), trace and debug the partitioning implemented at the H-extension level does not support units. prevent the execution time interference originated at micro- The RISC-V implementation with integrated fault tolerance architectural features like caches, queues and interconnects. For and error detection mechanisms can be verified by means of that, additional hardware support such as cache partitioning, fault injection (FI) experiments. FI is a well-known testing time-predictable arbitration policies, and dedicated hardware technique [45], used to verify the behaviour of critical system for fine-grain isolation is needed [50]. in presence of faults, evaluate the efficiency of integrated safety mechanisms, identify safety vulnerabilities and error C. Existing RISC-V Solutions for Safety-related Applications propagation paths. In fact, the usage of FI testing during the Several RISC-V processors have been adapted or designed to system design is recommended by ISO 26262 standard [46]. At meet functional safety requirements. The NOEL-V [51] from the early design stages, the simulation-based FI allows to verify FrontGrade Gaisler is a processor for the space domain that safety mechanisms implemented in high-level HDL model of implements the RV64GCH ISA configuration. However, the the system, e.g. ECC, lockstep execution, etc. Whereas at the GPL version of the NOEL-V core does not implement fault- late design stages the FPGA-based FI and physical FI are useful tolerant features. The NOEL-V has also been used to build the to evaluate safety features with all implementation details taken SELENE platform [52]. The SELENE platform is a multicore into account, including synthesis-place-route optimizations and SoC that implements hardware-based diverse redundancy in
the form of non-intrusive light-lockstep [53], the safeSU [54] ISA hardware cryptographic
hardware monitors for timing verification and enforcement, and perspective perspective DTLS perspective
provides virtualization support for partitioning hypervisors such LBCPQCIBC protocols
as Jailhouse [55] and XNG, both already supporting RISC-V. KEM ECDHE
RISC-V based systems from the PULP project [56] have also KDF ECDSA composed
AEAD LWE primitives
been adapted to ease its adoption in safety-related applications. LWC sampler
CBC,CBF,OFB
For instance, a RISC-V cluster based on the PULP project [57] AES_GCM SHA-3 hash
implement hybrid modular redundancy to select between dual AES stream/block functions
ciphers RNGs SHA-2 primitives
and triple redundancy with lockstep execution in a flexible Keccak Permutations
SubBytes NTT Permutations basic
manner. ShiftRows Binary Elliptic Curve building
MixColumns Extension Point Arithmetic
Other RISC-V processors targeting safety-related applica- AddRoundKey Field Arith. blocks
tions that are commercially available (not open-source) are Figure 3: Supported security features in RISC-V based architectures, catego-
the SiFive P550 Application class processor with configurable rized from three different perspectives.
dual-core lockstep, RAS capabilities, and ECC in interconnect
and memories, and the Fraunhofer EMSA5-FS which has been
certified as ASIL-D ready according to ISO 26262:2018 for 1) The cryptographic perspective: The pyramid in Figure 3
functional safety in vehicles. A RISC-V processor tailored shows, in a top-down fashion, some main building components
for high-energy physics applications (e.g. particles detectors needed to assure secure communications. Cryptographic proto-
at CERN) based on Fraunhofer AIRISC core [58] combines cols providing secure communication channels (for example the
radiation-hardened fabrication technology with several archi- DTLS protocol) are designed as challenge-response handshakes
tectural protection measures, including fine-grain TMR and with appropriate steps to assure confidentiality, data integrity,
extensive memory scrubbing. authentication and non-repudiation, and furthermore to prevent
known attacks such as replay, man-in-the-middle, etc. These
IV. RISC-V for Security Applications protocols require several cryptographic primitives, a.o. digital
In this section, we discuss recent developments concerning signatures (like ECDSA) for authentication. Such cryptographic
RISC-V cores with respect to security. We begin with a primitives are composed of basic building blocks. For example,
conceptual overview of these developments from cryptographic, the round function of the block cipher AES is composed of
hardware, and ISA perspectives in Section IV-A, where we use blocks such as SubBytes, ShiftRows, MixColumns, AddRound-
secure communication applications running on RISC-V as an Key, and relies on finite field arithmetic.
example. In Section IV-B, we further support our conceptual 2) The hardware perspective: In the past decades, it became
overview by presenting selected RISC-V cores with or without clear that security is a necessity for many embedded software
custom ISA extensions and cryptographic hardware, added as applications. However, introducing security-related features in
co-processors to the RISC-V core or integrated in the main a system induces a communication and computational overhead.
datapath of the core. In Section IV-C, we highlight some recent Such overhead can be reduced by adding dedicated hardware to
approaches to secure RISC-V implementations that prevent a general-purpose embedded processor in order to accelerate the
or hinder Side-Channel Attacks. Finally, in Section IV-D, we security-related computations in an application. In the middle
briefly cover specific RISC-V security topics from a system of Figure 3, we show the hardware perspective of security-
point of view. related features existing in RISC-V based cores and distinguish
A. Conceptual Overview between dedicated co-processors tightly/loosely coupled with
the main core and dedicated hardware additions to the main
In this section, we present RISC-V features, supporting core. For example, attaching a cryprographic co-processor, such
secure communication, from three perspectives. We begin the as the DTLS Cryptographic Engine [59], is a common solution.
discussion by categorizing the security features based on the Alternatively, dedicated hardware, such as the AES functional
type of cryptographic computation they support. This is pre- unit [63], can be added to the datapath of the main core. The
sented as the cryptographic perspective (Figure 3 – right). The work presented in [73] analyzes the building blocks of the
pyramid shows examples of basic building blocks, primitives, Lightweight Cryptography (LWC) finalists to find the most
and protocols required to provide information security. They suitable acceleration granularity, e.g., their smallest hardware
are placed in a pyramid to express the hierarchical dependency addition is for the Xoodyak parity plane manipulation (xorrol)
among them, i.e., the basic building blocks are used to construct with only a 1.155× increase in the area of the main core.
(composed) primitives that are used to construct security related 3) The ISA perspective: The RISC-V ISA is designed to
protocols. The hardware perspective (Figure 3 – middle) shows be modular including a relatively small stable base ISA and hardware design decisions distinguishing between dedicated multiple standard extensions while it also allows the design hardware added to the main RISC-V core and a coprocessor of custom instruction extensions. The distinction based on interfaced with the main core. Finally, the ISA perspective the presence of custom extensions is shown on the left of distinguishes between Base ISA, Standard Extensions, and Figure 3. For example, the aforementioned DTLS engine Custom Extensions (Figure 3 – left). interacts with the main core via a memory-mapped interface
Base ISA + Standard Ext. + + Custom Extensions Base ISA + Standard Ext. only
HW added to the main core coprocessor interfacing
with the main core
Table II: Cryptographic applications and granularity of added hardware and added custom ISA extensions in the context of hardware/software co-design
RISC-V RISC-V HW perspective Application and
Main add to co- control granularity (Figure 3), Implementation Technology
ISA core core proc. details Cryptographic perspective comments CAD tools Ref.
RV32 BlueSpec ✓ memory mapped entire DTLS as coprocessor: SPA-hardened configurable 65nm LP CMOS, [59]
I RISC-V interrupts (wfi) ECDHE & ECDSA prime field ECC accelerator, fabricated
FSM in coproc. AES-128-GCM, SHA2-256 stand-alone crypto possible
RV32 BlueSpec ✓ memory mapped, entire LWE-PQC as Sapphire modular ALU with config. 40nm LP CMOS, [60]
IM RISC-V interrupts (wfi), coprocessor: Frodo, NewHope prime, SRAM-based NTT fabricated
Sapphire insn. qTESLA, CRYSTALS-Kyber butterfly unit, Keccak core SPA on fabricated chip
decode+control CRYSTALS-Dilithium distribution sampler
RV32 Rocket ✓ RoCC entire crypto coprocessor: 4-stage pipelined 28nm CMOS, [61]
I AES, ECC, SHA-256 coprocessor, finite post-layout, Synopsys
field multiplier VCS and PrimeTime PX
RV32 Ibex ✓ AES IP AES coprocessor with AES IP in decode stage Nexys Artix-7, [62]
IMC + connected one custom instruction mode as insn. parameter Xilinx Vivado 2018.1
Custom to CSRs (ECB, CBC, CFB, OFB) post-P&R simulation
RV32/64 SCARV ✓ main core AES-GCM with custom insns AES-FUs for 4 32-bit exten- Yosys post-synthesis [63]
IMC + 32-bit decoder for: SubBytes, MixColumns, sion sets and 1 64-bit set, RISC-V Cryptography
Custom Rocket ✓ RoCC and SubBytes + MixColumns carry-less mult. for GCM Extension K proposals
RV32 CV32E40P ✓ Accelerator finite field accelerator, Montgomery Muliplier, Xilinx ZedBoard, [64]
IMCF (RI5CY) connected used for IBC (PQC): SIKE Modular Adder and Xilinx Vivado 2017.4
to FPR Subtractor
RV32 VexRiscv ✓ APB decoder prime field coprocessor, Modular arithmetic: adder, Xilinx Virtex-7, [65]
I connected to used for IBC (PQC): SIKE dual Montgomery multi- post-P&R
the main core plier for all SIKE primes
RV32 CV32E40P ✓ 32-bit AHB NTT accelerator, hash, DMR hardened NTT and Xilinx ZedBoard [66]
IM (RI5CY) Intecrconnect accelerator, used for LBC NTT-LUT core, hash core Zynq-7000,
(PQC): NewHope with Keccak FI simulation
RV32 VexRiscv ✓ Flexible prime field accelerator, w/ 4 2 variants: synthesized with Artix-35T, Xilinx [67]
IM+ pipeline: custom insn, used for LBC a fixed prime, and flexible Vivado 2019.1, iCE40
Custom plugins (PQC): Kyber, NewHope prime as parameter UltraPlus, Icestorm
RV32 CV32E40P ✓ main core finite field accelerator, w/ 4 PQ-ALU, ternary multi- Xilinx ZCU102 [68]
IM+ (RI5CY) decoder custom insns. used for LBC plier, Chien module, modu- Zynq UltraScale+
Custom (PQC): LAC lar reduction , SHA256
RV32 SCR1 ✓ 32-bit AHB-Lite vector coprocessor w/ 12 NTT core, Keccak core, TSMC 28nm HPC, [69]
IMC+ Interconnect custom insns. used for LBC binomial sampler, Random fabricated
Custom (PQC):Kyber, NewHope, LAC Number Generator
RV32 Ibex ✓ Vector Instru- vector coprocessor, w/ 16 NTT, CWM, modular arith- Xilinx Alveo U250 [70]
IMC+ ction Interface custom insns. used for LBC metic for each exLane, Vivado 2019.2
Custom (PQC): CRYSTALS-Kyber register pooling, automatic
index generation
RV32 SweRV-EL2 ✓ main core finite filed accelerator,w/ 4 carry-less multiplication, Nexys Artix-7, [71]
IMC+ decoder custom insns. used for: polynomial reduction, para- Verilator v4.032
Custom AES, Reed- Solomon codes metrized degree, irred. poly.
RV32 CV32E40P ✓ main core various accelerators, w/ 29 NTT, modular arithmetic, Xilinx Zynq-7000, [72]
IMCF+ (RI5CY) decoder custum insn., used for LBC Keccak in decode stage UMC 65nm,
Custom (PQC): NewHope, Kyber, binomial sampling, Kara- Cadence Incisive
Lightsaber , Firesaber, Saber tsuba, Toom-Cook multi- Enterprise Simulator,
pliers in execute stage Joules
RV32 Rocket ✓ main core LWC finalists: separate main core, Zbkb/x FU, SASEBO-GIII board [73]
GC + decoder extensions for each candidate ans ISE-specific LWC FU Kintex-7 target,
Custom by benchmarking, e.g., Ascon for each candidate, also Xilinx Vivado 2019.1
sigma.lo, sigma.hi insns, e.g., implementing AES-GCM
XOODYAK xorrol insn for reference
RV32 CV32E40P ✓ main core Ascon-p with a custom insn: Ascon-p in Decode stage, 65nm LL CMOS [74]
IMC+ (RI5CY) decoder permutation with number of Internal state in GPR Cadence Encounter RTL
Custom rounds as parameter Ascon, Ascon-hash, ISAP Compiler, NanoRoute
PQC = Post-Quantum Crypto, IBC = Isogeny Based Crypto., LBC = Lattice-Based Crypto, LWE = Learning With Errors, ECC = Elliptic Curve Crypto.
LWC = Light-Weight Crypto., SPA = Simple Power Analysis, FI = Fault Injection, DMR = Dual Modular Redundancy
CSR = Control and Status Registers, FPR = Floating Point Registers, GPR = General Purpose Registers
and does not require any (custom) additions to the ISA [59]. extensions, ISA and hardware designers can choose a suitable In contrast, the work in [62], [63] presents a design of custom level of granularity of the instructions and dedicated hardware AES instructions for RISC-V. In general, with custom ISA added to the RISC-V based architecture. For example, the
authors of [62] implemented the entire AES primitive with exploiting side-channel leakage, such as power consumption
different modes, including ECB, as a custom instruction, while or electromagnetic emanations. Thus, in the past two decades,
[63] presents separate RISC-V ISA instructions for utilizing we have seen the rise of side-channel analysis (SCA) for
the SubBytes and MixColumns basic blocks as well as a single cryptographic circuits and systems. More recently, such SCA
instruction for utilizing both SubBytes + MixColumns. trend could be witnessed for RISC-V based systems featuring
Finally, there exists an ongoing effort to propose and stan- support for security-related applications. We briefly discuss
dardize RISC-V cryptography ISA extensions containing two some side-channel hardened RISC-V solutions, aiming to
orthogonal sets of specific instructions: first, scalar & entropy prevent, or at least to hinder, the extraction of sensitive data
source instructions [75], and second, vector cryptographic from RISC-V based systems.
instructions [76]. The scalar & entropy source instructions As mentioned earlier, the DTLS Cryptographic Engine [59] is
are cryptographic instruction proposals for smaller cores often attached as a co-processor to a RISC-V core. This engine that do not implement vector extensions. They include a implements countermeasures to prevent simple power analysis subset of "constant-time" instructions with data-independent (SPA) from distinguishing point addition and point doubling. execution time to prevent timing side-channels. In contrast, Similarly, the Sapphire co-processor implements constant-time vector cryptographic instructions are proposed to be used SPA-hardened sub-modules [60]. The designers of Sapphire in large and high performance cores that have large vector also conducted simple power analysis on the fabricated chip to registers that are reused. Some examples are AES and SHA-2, verify the constant-time execution. The Sapphire co-processor with instructions on different granularity, for example single- has no differential power analysis (DPA) countermeasures, but round (building block) and all-round (primitive). It is also its designers have discussed how to include such countermea- possible to vectorize SHA-3 using a number of general-purpose sures using the Sapphire’s programmability. instructions, allowing for simultaneous processing of multiple The authors of [77] propose a secure RISC-V ISA and pieces of data to increase the performance of SHA-3 [76]. architecture by including an additional secure pipeline which is B. Selected RISC-V Cores with Security-related Features completely separated from the unprotected (original) pipeline. The instruction decode stage disables the unprotected pipeline In this section, we present selected state-of-the-art proposals during execution of protected instructions to prevent leakage. for RISC-V implementations with security support. These The secure pipeline executes a set of instructions protected proposals are shown in Table II where the order of the by Domain-Oriented Masking (DOM) with multi-cycle non- rows roughly follows the top-down cryptographic perspective linear operations, e.g., 4-cycle 1-bit ADD instruction with two illustrated with the pyramid in Figure 3. The columns in Table II fresh random numbers per share. The idea of custom ISA are organized starting with the ISA perspective and the RISC-V instructions to mitigate SCA has been extended in [78] to main core, in the first two columns, followed by three columns include DOM and other masking approaches. The authors summarizing the hardware perspective, with checkmarks for have presented 22 custom instructions such as conversion dedicated hardware added to the main core and co-processor of operands (Boolean to/from Arithmetic masking), Boolean designs. When custom extensions are present, indicated in the masking operations, arithmetic masking operations, and masked ISA column, the instruction decoder in the main core has to be finite field arithmetic for GF(28). They place a masked ALU modified but we do not consider this as an addition to the main containing dedicated hardware, including random bit generators, core in Column 3. Column 5 lists some implementation details in parallel to the unprotected ALU in the SCARV core, with a to show the relationship between the dedicated hardware and 1.45× area increase for the ASIC implementation. Additional the main core. For example, the Sapphire co-processor in Row randomness and re-masking are used to compensate for not 3 has its own instructions decoder and controller, and could duplicating the datapath. The work in [78] also provides be reused with any main core. preliminary SCA results on FPGA implementations of the Column 6 provides some application details from the SCARV core by running and comparing unmasked AES using cryptographic perspective, illustrated with the pyramid in only the base ISA and masked AES using the aforementioned Figure 3, together with the granularity of the ISA extensions custom extensions. and corresponding hardware additions. Column 7 provides Finally, the authors of [79] have used formal verification very brief implementation comments, such as expensive cryp- methods to design a secure Ibex core with additional features, tographic computations, i.e. sub-modules illustrated with the preventing leakage, such as secure register file, AND-gated pyramid in Figure 3, and architectural decisions. Finally, in computation unit, and clear for the hidden LSU buffer. The Column 8, we provide some information on the technology security features increase the total Ibex core area by only 9.9%. and CAD tools used to design the RISC-V cores, focusing mostly on fabricated ASIC and configured FPGA designs. D. RISC-V System Security C. Towards Side-Channel Attack Resilience for RISC-V This section briefly discusses selected RISC-V security topics, such as Root-of-Trust (RoT), trusted boot, memory During cryptographic operations, computations are per- protection and isolation, and trusted execution environment formed using sensitive data such as cryptographic keys. It (TEE), from the perspective of added (cryptographic) hardware. has been shown that such sensitive data can be revealed by Some of these topics are also covered in [1], [20], [80].
A secure bootloader is considered to be the smallest RoT, funding from the ECSEL Joint Undertaking (JU) under grant
on top of which the chain of trust and trusted code base are agreement No 877056, Agencia Estatal de Investigación from
built. For example, Sanctum [81] uses trusted on-chip ROM Spain under grant agreement no. PCI2020-112092 within
to hold the bootloader. In addition, the system includes a the NextGenerationEU program. Furthermore, this research
hardware TRNG and PUF, and software SHA-3, ECDSA and was supported by Advantest as part of the Graduate School
AES implementations [82] to provide strong isolation using "Intelligent Methods for Test and Reliability" (GS-IMTR) at
enclaves and to protect against software attacks, such as cache the University of Stuttgart. For this work, Leiden University
timing attacks and passive address translation attacks. Sanctum received funding from the Dutch Research Council (NWO)
has been designed for Rocket RISC-V with minimal hardware through the PROACT project (NWA.1215.18.014).
extensions and implemented on Xilinx Zynq 7000 FPGA. References
Keystone [83] is an open-source framework for building
customized TEEs with only basic primitives implemented in [1] B. W. Mezger et al., “A Survey of the RISC-V Architecture Software
hardware. The framework is comprised of a device-specific [2] Support,” IEEE Access, vol. 10, pp. 51 394–51 411, 2022.
A. Dörflinger et al., “A comparative survey of open-source application-
secret key available only to the trusted boot process, a hardware class RISC-V processor implementations,” in CF, 2021, pp. 12–20.
source of randomness, and a trusted boot process. The Keystone [3] RISC-V ISA, Unprivileged Specification, https://riscv.org/technical/
RoT can be either a hardware crypto engine or tamper-proof [4] specifications/.
K. Asanovi´c et al., “The Rocket Chip Generator,” EECS Department,
software. It uses physical memory protection (PMP) and a University of California, Berkeley, USA, Tech. Rep. UCB/EECS-2016-
security monitor running in machine mode to enforce memory [5] 17, Apr. 2016.
A. Amid et al., “Chipyard: Integrated Design, Simulation, and
isolation. For example, a SoC with two Rocket cores using Implementation Framework for Custom SoCs,” IEEE Micro, vol. 40,
Keystone implements two hardware accelerators, SHA-3 and [6] no. 4, pp. 10–21, 2020.
ECDSA, connected via Tilelink [84]. Another example is the C. Celio et al., “BROOM: An Open-Source Out-of-Order Processor
With Resilient Low-Voltage Operation in 28-nm CMOS,” IEEE Micro,
ITUS RISC-V based secure SoC [85] which includes two vol. 39, no. 2, pp. 52–60, 2019.
Rocket cores and integrates Keystone-enclaves for TEE. The [7] J. Zhao et al., “SonicBOOM: The 3rd Generation Berkeley Out-of-
SoC, implemented on Xilinx Kintex 705, also includes a [8] Order Machine,” 2020.
Ibex documentation, https : / / readthedocs . org / projects / ibex - core /
hardware key management unit with one-time programmable [9] downloads/pdf/latest/, May 2023.
memory, TRNG and PUF, a hardware signature verification P. Davide Schiavone et al., “Slow and Steady Wins the Race? a
Comparison of Ultra-Low-Power RISC-V Cores for Internet-of-Things
unit with boot sequencer, SHA3, the XMSS and ECDSA digital Applications,” in PATMOS, 2017, pp. 1–8.
signature schemes, and a memory protection unit with AES- [10] M. Gautschi et al., “Near-Threshold RISC-V Core With DSP Exten- GCM. In addition, [85] also considers countermeasures for sions for Scalable IoT Endpoint Devices,” IEEE Trans. VLSI Syst., vol. 25, no. 10, pp. 2700–2713, 2017. side-channel attacks. Keystone has been also modified to run [11] F. Zaruba et al., “The Cost of Application-Class Processing: Energy on the CVA6 core and on a GPU-scale accelerator with 4096 and Performance Analysis of a Linux-Ready 1.7-GHz 64-bit RISC-V cores, divided into clusters of 8 [86]. Core in 22-nm FDSOI Technology,” IEEE Trans. VLSI Syst., vol. 27, no. 11, pp. 2629–2640, Nov. 2019. [12] GitHub - SpinalHDL/VexRiscv: A FPGA friendly 32 bit RISC-V CPU V. Conclusion [13] implementation, https://github.com/SpinalHDL/VexRiscv, 2018. T.-T. Hoang et al., “Low-power high-performance 32-bit RISC- The RISC-V ISA and processors implementing it are V microcontroller on 65-nm silicon-on-thin-BOX (SOTB),” IEICE receiving an ever-increasing attention from both the scientific [14] Electronics Express, vol. 17, no. 20, pp. 1–6, 2020. community and the industry. The test, safety and security GitHub - YosysHQ/picorv32: PicoRV32 - A Size-Optimized RISC-V CPU, https://github.com/YosysHQ/picorv32. aspects discussed in this survey are key prerequisites for RISC- [15] K. P. Ghosh et al., “Technology mediated tutorial on RISC-V CPU core V processor being useful for actual products. While many basic implementation and sign-off using revolutionary EDA management concepts and approaches previously developed for different [16] system (EMS) - VSDFLOW,” in CSTIC, 2018, pp. 1–3. B. Marshall et al., “Implementing the Draft RISC-V Scalar Cryptog- architectures can be reused with minor modifications, the [17] raphy Extensions,” in HASP, 2020, pp. 1–8. open nature of RISC-V ISA calls for new and more universal W. Digital, EL2 SweRV RISC-V CoreTM 1.4, http://www.azhothot. com/risc-v.html, Jan. 2020. solutions for some of the problems mentioned. Therefore, this [18] T. Kruiper, “Area-Optimized RISC-V-Based Control System for 22nm survey can only provide a snapshot of recently obtained results, FDSOI Analog and Mixed-Signal Test Chips,” M.S. thesis, University and the scientific work will continue in the foreseeable future. In [19] of Twente, Jan. 2023. S. Kalapothas et al., “A Survey on RISC-V-Based Machine Learning order to obtain the best solutions, it is important to establish and Ecosystem,” Information, vol. 14, no. 2, p. 64, 2023. maintain connection between RISC-V architects and specialists [20] E. Cui et al., “RISC-V Instruction Set Architecture Extensions: A in test methods, safety and hardware-oriented security. [21] Survey,” IEEE Access, vol. 11, pp. 24 696–24 711, 2023. J. Abella et al., “Security, Reliability and Test Aspects of the RISC-V Ecosystem,” in ETS, 2021, pp. 1–10. Acknowledgment [22] M. Psarakis et al., “Microprocessor Software-Based Self-Testing,” IEEE Des. Test. Comput, vol. 27, no. 3, pp. 4–19, 2010. This work was supported in part by the German Federal [23] M. Prabhu et al., “Functional test generation for hard to detect stuck-at Ministry of Education and Research (BMBF) within the [24] faults using RTL model checking,” in ETS, 2012. project Scale4Edge under contract no. 16ME0132 and by the T. Faller et al., “Constraint-Based Automatic SBST Generation for RISC-V Processor Families,” in ETS, 2023. Italian ICSC National Research Centre for High Performance [25] R. Vollertsen, “Burn-In,” in IIRW, 1993. Computing, Big Data and Quantum Computing within the [26] M. Pietzsch, “RISC-V Processor for Network Platforms According NextGenerationEU program. UPV researchers have received to ISO 26262,” ATZelectronics worldwide, vol. 16, no. 11, pp. 8–13, 2021.
[27] N. I. Deligiannis et al., “Automating the Generation of Programs [58] A. Walsemann et al., “STRV – a radiation hard RISC-V microprocessor Maximizing the Repeatable Constant Switching Activity in Micropro- for high-energy physics applications,” J. of Instrum., vol. 18, no. 02, cessor Units via MaxSAT,” IEEE Trans. Comput.-Aided Design Integr. p. C02032, 2023. Circuits Syst., 2023. [59] U. Banerjee et al., “An energy-efficient reconfigurable DTLS crypto- [28] N. I. Deligiannis et al., “Automating the Generation of Programs graphic engine for securing Internet-of-Things applications,” IEEE J. Maximizing the Sustained Switching Activity in Microprocessor units of Solid-State Circuits, vol. 54, no. 8, pp. 2339–2352, 2019. via Evolutionary Techniques,” Microprocessors and Microsystems, [60] U. Banerjee et al., “Sapphire: A Configurable Crypto-Processor for vol. 98, 2023. Post-Quantum Lattice-based Protocols,” TCHES, vol. 2019, no. 4, [29] I. Polian et al., “Exploring the Mysteries of System-Level Test,” in pp. 17–61, ATS, 2020, pp. 1–6. [61] W. Wang et al., “An energy-efficient crypto-extension design for [30] S. Biswas et al., “An Industrial Study of System-Level Test,” IEEE RISC-V,” Microelectronics J., vol. 115, p. 105 165, 2021. Des. Test. Comput, vol. 29, no. 1, pp. 19–27, 2012. [62] A. Zgheib et al., “Extending a RISC-V core with an AES hardware [31] H. H. Chen, “Beyond structural test, the rising need for system-level accelerator to meet IOT constraints,” in SMACD / PRIME, 2021, test,” in VLSI – DAT, 2018, pp. 1–4. pp. 1–4. [32] D. Schwachhofer et al., “Automating Greybox System-Level Test [63] B. Marshall et al., “The design of scalar AES Instruction Set Extensions Generation,” in ETS, 2023. for RISC-V,” TCHES, vol. 2021, no. 1, pp. 109–136, [33] F. Corno et al., “Automatic Test Program Generation for Pipelined [64] D. B. Roy et al., “Efficient Hardware/Software Co-Design for Post- Processors,” in SAC, 2003, pp. 736–740. Quantum Crypto Algorithm SIKE on ARM and RISC-V Based [34] A. Zeller et al., The Fuzzing Book. CISPA Helmholtz Center for Microcontrollers,” in ICCAD, 2020. Information Security, 2021. [65] R. Elkhatib et al., “Accelerated RISC-V for Post-Quantum SIKE,” [35] P.-F. Chiu et al., “An Out-of-Order RISC-V Processor with Resilient IEEE Trans. on Circuits and Syst. I: Regular Papers, vol. 69, 2022. Low-Voltage Operation in 28nm CMOS,” in Proc. IEEE Symp. VLSI [66] T. Fritzmann et al., “Towards Reliable and Secure Post-Quantum Circuits, 2018, pp. 61–62. Co-Processors based on RISC-V,” in DATE, 2019, pp. 1148–1153. [36] C. Gaisler, Quad core LEON4 SPARC V8 processor - LEON4-NGMP- [67] E. Alkim et al., “ISA Extensions for Finite Field Arithmetic: Accel- DRAFT - data sheet and users manual, 2011. erating Kyber and NewHope on RISC-V,” TCHES, vol. 2020, no. 3, [37] Infineon, AURIX Multicore 32-bit Microcontroller Family to Meet pp. 219–242, 2020. Safety and Powertrain Requirements of Upcoming Vehicle Generations. [68] T. Fritzmann et al., “Extending the RISC-V Instruction Set for [38] X. Iturbe et al., “Addressing Functional Safety Challenges in Au- Hardware Acceleration of the Post-Quantum Scheme LAC,” in DATE, tonomous Vehicles with the Arm Triple Core Lock-Step (TCLS) 2020, pp. 1420–1425. Architecture,” IEEE Design and Test, vol. PP, no. 99, pp. 1–1, 2018. [69] G. Xin et al., “VPQC: A Domain-Specific Vector Processor for Post- [39] A. Dörflinger et al., “ECC Memory for Fault Tolerant RISC-V Quantum Cryptography Based on RISC-V Architecture,” IEEE Trans. Processors,” in ARCS, 2020, pp. 44–55. on Circuits and Syst. I: Regular Papers, vol. 67, no. 8, pp. 2672–2684, [40] E. B. Annink et al., “Preventing Soft Errors and Hardware Trojans in 2020. RISC-V Cores,” in DFT, 2022, pp. 1–6. [70] H. Li et al., “A scalable SIMD RISC-V based processor with [41] M. Peña-Fernández et al., “Dual-Core Lockstep enhanced with customized vector extensions for CRYSTALS-Kyber,” in DAC, 2022, redundant multithread support and control-flow error detection,” pp. 733–738. Microelectronics Rel., vol. 100, p. 113 447, 2019. [71] Y.-M. Kuo et al., “Versatile RISC-V ISA Galois Field arithmetic [42] F. Kempf et al., “An Adaptive Lockstep Architecture for Mixed- extension for cryptography and error-correction codes,” in CARRV, Criticality Systems,” in ISVLSI, 2021, pp. 7–12. 2021. [43] X. Iturbe et al., “The Arm Triple Core Lock-Step (TCLS) Processor,” [72] T. Fritzmann et al., “RISQ-V: Tightly Coupled RISC-V Accelerators TOCS, vol. 36, no. 3, pp. 1–30, 2019. for Post-Quantum Cryptography,” TCHES, vol. 2020, no. 4, pp. 239– [44] I. Marques et al., “Lock-V: A heterogeneous fault tolerance architecture 280, based on Arm and RISC-V,” Microelectronics Rel., vol. 120, p. 114 120, [73] H. Cheng et al., “RISC-V Instruction Set Extensions for Lightweight 2021. Symmetric Cryptography,” TCHES, vol. 2023, no. 1, pp. 193–237, [45] A. Benso et al., Fault Injection Techniques and Tools for Embedded [74] S. Steinegger et al., “A Fast and Compact RISC-V Accelerator for Systems Reliability Evaluation. Springer Science & Business Media, Ascon and Friends,” in CARDIS, 2020, pp. 53–67. 2003, vol. 23. [75] B. Marshall, Ed., The RISC-V Cryptography Extensions, Volume I: [46] L. Pintard et al., “Fault Injection in the Automotive Standard ISO Scalar & Entropy Source Instructions. RISC-V Foundation, Feb. 2022. 26262: An Initial Approach,” in EWDC, 2013, pp. 126–133. [76] K. Dockser, Ed., The RISC-V Cryptography Extensions, Volume II: [47] J. Abella et al., “WCET Analysis Methods: Pitfalls and Challenges Vector Instructions. RISC-V Foundation, Mar. 2023. on their Trustworthiness,” in SIES, 2015, pp. 1–10. [77] P. Kiaei et al., Domain-Oriented Masked Instruction Set Architecture [48] M. S. et al., “T-CREST: Time-predictable multi-core architecture for for RISC-V, Cryptology ePrint Archive, Paper 2020/465, 2020. embedded systems,” J. Syst. Architecture, vol. 61, no. 9, pp. 449–471, [78] S. Gao et al., “An Instruction Set Extension to Support Software-Based 2015. Masking,” TCHES, vol. 2021, no. 4, pp. 283–325, [49] H. Yun et al., “MemGuard: Memory bandwidth reservation system [79] B. Gigerl et al., “COCO: Co-Design and Co-Verification of Masked for efficient performance isolation in multi-core platforms,” in RTAS, Software Implementations on CPUs,” in USENIX, 2021, pp. 1469– 2013, pp. 55–64. 1468. [50] M. Chisholm et al., “Cache Sharing and Isolation Tradeoffs in [80] T. Lu, “A survey on RISC-V security: Hardware and Architecture,” Multicore Mixed-Criticality Systems,” in RTSS, 2015, pp. 305–316. arXiv:2107.04175, 2021. [51] Cobham Gaisler, NOEL-V Processor, https://www.gaisler.com/index. [81] V. Costan et al., “Sanctum: Minimal Hardware Extensions for Strong php/products/processors/noel-v, 2020. Software Isolation,” in USENIX, 2016, pp. 857–874. [52] C. Hernàndez et al., “SELENE: Self-Monitored Dependable Platform [82] I. Lebedev et al., “Invited Paper: Secure Boot and Remote Attestation for High-Performance Safety-Critical Systems,” in DSD, 2020, pp. 370– in the Sanctum Processor,” in CSF, 2018, pp. 46–60. 377. [83] D. Lee et al., “Keystone: An Open Framework for Architecting Trusted [53] F. Bas et al., “SafeDE: a flexible Diversity Enforcement hardware Execution Environments,” in EuroSys, 2020, pp. 1–16. module for light-lockstepping,” in IOLTS, 2021, pp. 1–7. [84] T.-T. Hoang et al., “Quick Boot of Trusted Execution Environment [54] G. Cabo et al., “SafeSU: an Extended Statistics Unit for Multicore With Hardware Accelerators,” IEEE Access, vol. 8, pp. 74 015–74 023, Timing Interference,” in ETS, 2021, pp. 1–4. 2020. [55] R. Ramsauer et al., “Static Hardware Partitioning on RISC-V – [85] V. B. Kumar et al., “Towards Designing a Secure RISC-V System-on- Shortcomings, Limitations, and Prospects,” arXiv:2208.02703, 2022. Chip: ITUS,” J. of Hardware and Syst. Secur., vol. 4, pp. 329–342, [56] PULP Platform, https://pulp-platform.org/. 2020. [57] M. Rogenmoser et al., “Hybrid Modular Redundancy: Exploring [86] M. Schneider et al., “Composite Enclaves: Towards Disaggregated Modular Redundancy Approaches in RISC-V Multi-Core Computing Trusted Execution,” arXiv:2010.10416, 2020. Clusters for Reliable Processing in Space,” arXiv:2303.08706, 2023.