How to make processors trustworthy
By Sergio Marchese, Technical Marketing Manager at OneSpin
Modern integrated circuits (ICs) provide the computational and system control capabilities to process enormous amounts of data, make safety-critical decisions in real time, and protect sensitive data.
Designing an application-specific integrated circuit (ASIC) or field-programmable gate array (FPGA) system-on-chip (SoC) from scratch would be prohibitively expensive and time-consuming. Many critical functions are implemented using third-party intellectual properties (IPs). Processor cores, for example, are sourced from specialized organizations and provide a flexible, software-programmable function through their instruction set architecture (ISA), which defines the interface between hardware and software. Open-source processor architectures provide an opportunity for deeper scrutiny and rigorous security assurance in systems that are already facing a fluid threat environment. This article describes an approach for providing security assurance of IP and SoCs based on the RISC-V open-source ISA.
Invented at the University of California and managed by the non-profit RISC-V Foundation, RISC-V is the first open-source ISA to become a genuinely viable industrial choice for a broad range of applications.
RISC-V is an open-source ISA invented at the University of California and managed by the RISC-V Foundation, a non-profit organization with over 300 members founded in 2015. RISC-V is the first open-source ISA to become a genuinely viable industrial choice for a broad range of applications. The ecosystem of tools, software, and expertise is robust and growing steadily. Many individuals and organizations have already donated open-source hardware IPs implementing the RISC-V ISA. The OpenHW Group, for example, is aiming at making the long-awaited prospect of open-source hardware – particularly, processor cores – for high-volume chips a reality.
The rise of RISC-V has many reasons behind it. Built from the ground up with custom extensibility in mind, RISC-V allows a new level of hardware optimization for specific workloads. Moore’s law is slowing down, and customization is crucial to sustaining the level of performance improvements that technological advances in the semiconductor manufacturing process can no longer provide. Moreover, the RISC-V architecture is free from licensing costs and royalties, enabling more companies to develop innovative, affordable products. Much is happening in the field of IoT and wearable devices with artificial intelligence capabilities, for example.
SoC integrators often use open-source or third-party RISC-V processor IPs. These designs and their associated toolchains can be augmented with custom instructions. A high-quality verification environment delivered with the IP and additional system-level testing can provide some confidence that the IP has no critical bugs. Unfortunately, for many applications, this is not enough, and there are other serious risks to consider.
Vulnerabilities and Trojans
Traditionally, security vulnerabilities in electronic systems have been associated with system-level and software issues. More recently, hardware IPs, prominently processors, have also become a central concern (see Fig. 1). Processor implementations use pipeline-based microarchitectures and often include performance and power optimization features. Complexity increases the risk of missing not only functional bugs but also security vulnerabilities. The security researchers that discovered the Meltdown and Spectre attacks in early 2018 have demonstrated that performance optimization features in processors can be used in unintended ways for nefarious purposes. Since then, many more vulnerabilities in both high-end and low-end processors have been discovered. Side channels and transient execution attacks may breach secure enclaves and allow malicious applications to leak confidential data or even take over the control of the system. And unlike software, hardware issues cannot be easily repaired with over-the-air updates. Addressing a hardware issue through software often causes severe performance degradation.
The RISC-V architecture has many features that support the implementation of secure embedded systems. The privilege specification defines four privilege modes (machine, supervisor, hypervisor, and user), for example. Custom instructions and ISA extensions in the process of being ratified, such as the Cryptographic extension, provide additional security capabilities. Designers can implement multiple secure enclaves to isolate applications and prevent the leakage of sensitive data. However, RTL micro-architectural features can still result in security vulnerabilities. These risks cannot be addressed entirely at the ISA level. A new approach under exploration is the use of an augmented ISA (aISA) to define aspects of instruction execution at the micro-architectural level and, for example, control the state of buffers or registers not visible at the ISA level. RTL functional bugs could still compromise all these security features.
A less likely risk but with a far higher severity is the presence of malicious logic or hardware Trojans in the RISC-V core. A hardware Trojan is a logic function deliberately designed to be stealthy, which activates in very rare circumstances known only to the attacker. A specific sequence of data and control events that would not happen while the system is operating in its target use cases triggers the Trojan logic, which in turn delivers a damaging payload, leaking a secret or critically corrupting the system behavior, for example. SoC integrations using open-source or third-party RISC-V cores can no longer ignore this risk.
Ensuring that a processor does what it is supposed to do is hard, but ensuring that it does not do anything that it is not supposed to do is an even more challenging task that is still largely unaddressed. Safety-critical systems and systems where the protection of data privacy is paramount, need efficient, high-quality solutions that address the risk of security vulnerabilities and Trojans.
Smart Hardware Assurance
Assuring the trust and security of RISC-V IPs requires innovative and efficient technical solutions that are complementary to functional correctness approaches, mainly targeting the IP intended use cases (see Fig. 2). IP providers are responsible for applying state-of-the-art trust and security verification processes, while IP integrators should have access to independent assurance solutions that can be deployed quickly and without in-depth knowledge of the IP implementation details.
Formal methods can analyze hardware functions exhaustively and deliver proof that the IP or SoC precisely matches an expected behavior often captured in SystemVerilog assertions. Hardware formal verification using commercial model checkers has enjoyed widespread adoption over the past decade. Typically, IP providers and SoC integrators have formal verification experts in their ranks, trying to reduce the risk of missing functional bugs to a minimum. While certain well-defined formal verification tasks can be automated through Apps, in general, significant engineering effort is necessary to capture the IP’s expected behavior in assertions. Furthermore, there is no guarantee that enough assertions have been written. Undocumented functions or unintended gaps in the set of assertions could lead to unverified IP functionality.
The open-source nature of RISC-V allows the development of prepackaged, independent assurance solutions. OneSpin’s RISC-V Integrity Verification Solution, for example, can be applied to a wide range of microarchitectures. It includes models of the RISC-V ISA and privileged ISA that are extensible and can accommodate custom instructions. A crucial aspect of this solution is that it is based on OneSpin’s GapFreeVerification™ process, which delivers a rigorous proof that the set of assertions modeling the RISC-V ISA is complete and free from gaps. This aspect is of the utmost importance when the detection of hardware Trojans or undocumented logic is a crucial goal. The solution allows SoC integrators with limited expertise on RISC-V and the RTL implementation under scrutiny to gain confidence in the quality and trustworthiness of the IP. IP developers can use it to detect security weaknesses and functional bugs before release.
Does It Work?
The RISC-V integrity assurance process described in the previous section has been successfully applied to multiple RTL designs. Edaptive Computing, a company that integrates innovative solutions to rapidly optimize, assure, and automate systems of systems and processes for a variety of U.S. Department of Defense and commercial sector customers, has applied the process to the RocketCore, for example. The RocketCore is an open-source, silicon-proven 64-bit RISC-V core with a 39-bit virtual memory system. It has a five-stage, single-issue, in-order pipeline with out-of-order completion for long latency instructions such as division. It includes the advanced features of branch prediction and instruction replay.
The RISC-V Integrity Verification Solution was applied to the design with all instructions, privilege levels, interrupts, and exception mechanism, and 8 issues were detected (see Fig. 3). Additional information on 3 of them is reported below.
Division corner-case: a deep corner-case bug associated with the out-of-order completion of the division instruction. This issue could have caused a software program using the division operation to compute incorrect results and lead to system misbehavior. The issue appears only under a combination of rare circumstances, and that is why previous verification efforts had missed it.
Replay of illegal instruction: this is not a corner-case bug. Replaying an illegal instruction can waste processing cycles, but if this happens only in rare situations, the performance impact is negligible. However, there are other aspects to consider. Instruction replay may cause unnecessary memory requests. These requests may have side effects that could be leveraged in side-channel attacks. As a result, this behavior needs to be either eliminated or clearly understood and documented.
Undocumented instruction: an undocumented, non-standard instruction called CEASE that stops the core was detected. In effect, the RISC-V RocketCore could do something that it was not supposed to do. Undocumented, hidden functions are not acceptable when trust and security are a concern, even when they relate to use cases that are deemed not relevant to the end application.
The RocketCore case study is presented in detail in the GOMACTech 2019 paper titled Complete Formal Verification of RISC-V Processor IPs for Trojan-Free Trusted ICs. To obtain a copy, visit onespin.com/resources/white-papers.
What’s Next?
The RISC-V assurance process presented in this article detects scenarios that could affect security, and systematically unveils undocumented functions and hardware Trojans that impact the processor’s behavior, regardless of how rare and stealthy they might be. However, side-channels are not systematically detected. Exhaustive detection of all potential side-channels requires a dedicated solution with appropriate technology. There are already prototypes that address this challenge. For more information, visit onespin.com/resources/technical-articles and read the EE Times article Side-Channel Attacks on Embedded Processors.
Processor cores are crucial IPs within embedded systems. However, a typical SoC integrates many other IPs that could also contain hardware Trojans. Unlike for RISC-V cores, independent trust assurance solutions might not be readily available. In this case, it would be valuable to have an automated, low-effort trust assessment process applicable to any IP. A process that does not include a trusted model of the IP cannot ensure a Trojan’s absence. However, it is possible to identify unusual and suspicious code patterns and known Trojan signatures, and weaknesses that could be exploited in later development stages for nefarious purposes. A paper on this topic titled An Automated Pre-Silicon IP Trustworthiness Assessment for Hardware Assurance, authored by AEROSPACE Corporation and OneSpin engineers, will be presented at the GOMACTech 2020 conference.