Modern integrated circuits (ICs) provide the computational and system control capabilities to process enormous amounts of knowledge, make safety-critical decisions in real-time, and protect sensitive data. Designing an application-specific microcircuit (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 instance, are sourced from specialized organizations and supply a versatile, software-programmable function through their instruction set architecture (ISA), which defines the interface between hardware and software. Open-source processor architectures provide a chance for deeper scrutiny and rigorous security assurance in systems that are already facing a fluid threat environment. this text describes an approach for providing security assurance of IP and SoCs supported the RISC-V open-source ISA.
Invented at the University of California and managed by the non-profit RISC-V Foundation, RISC-V is that 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 that 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 strong and growing steadily. Many individuals and organizations have already donated open-source hardware IPs implementing the RISC-V ISA. The OpenHW Group, for instance, 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 bottom up with custom extensibility in mind, RISC-V allows a replacement level of hardware optimization for specific workloads. Moore’s law is slowing down, and customization is crucial to sustaining the extent of performance improvements that technological advances within the semiconductor manufacturing process can not provide. Moreover, the RISC-V architecture is free from licensing costs and royalties, enabling more companies to develop innovative, affordable products. Much is occurring within the field of IoT and wearable devices with AI capabilities, for instance.
SoC integrators often use open-source or third-party RISC-V processor IPs. These designs and their associated toolchains are often augmented with custom instructions. A high-quality verification environment delivered with the IP and extra system-level testing can provide some confidence that the IP has no critical bugs. Unfortunately, for several applications, this is often not enough, and there are other serious risks to think about.
Vulnerabilities and Trojans
Traditionally, security vulnerabilities in electronic systems are related to 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 sometimes include performance and power optimization features. Complexity increases the danger of missing not only functional bugs but also security vulnerabilities. the safety researchers that discovered the Meltdown and Spectre attacks in early 2018 have demonstrated that performance optimization features in processors are often utilized in unintended ways for nefarious purposes. Since then, more vulnerabilities in both high-end and low-end processors are discovered. Side channels and transient execution attacks may breach secure enclaves and permit malicious applications to leak confidential data or maybe take over the control of the system. and in contrast to software, hardware issues can’t be easily repaired with over-the-air updates. Addressing a hardware issue through software often causes severe performance degradation.
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 instance. Custom instructions and ISA extensions within the process of being ratified, like the Cryptographic extension, provide additional security capabilities. Designers can implement multiple secure enclaves to isolate applications and stop the leakage of sensitive data. However, RTL micro-architectural features can still end in security vulnerabilities. These risks can’t be addressed entirely at the ISA level. a replacement approach under exploration is that the use of an augmented ISA (aISA) to define aspects of execution at the micro-architectural level and, for instance, control the state of buffers or registers not visible at the ISA level. RTL functional bugs could still compromise of these security measures.
A less likely risk but with a far higher severity is that the presence of malicious logic or hardware Trojans within the RISC-V core. A hardware Trojan may be a logic function deliberately designed to be stealthy, which activates in very rare circumstances known only to the attacker. a selected sequence of knowledge and control events that might not happen while the system is working in its target use cases triggers the Trojan logic, which successively delivers a harmful payload, leaking a secret or critically corrupting the system behavior, for instance. SoC integrations using open-source or third-party RISC-V cores can not ignore this risk.
Ensuring that a processor does what it’s alleged to do is tough, but ensuring that it doesn’t do anything that it’s not alleged to do is a good tougher task that’s still largely unaddressed. Safety-critical systems and systems where the protection of knowledge privacy is paramount, need efficient, high-quality solutions that address the danger 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 liable for applying state-of-the-art trust and security verification processes, while IP integrators should have access to independent assurance solutions that will 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 have enjoyed widespread adoption over the past decade. Typically, IP providers and SoC integrators have formal verification experts in their ranks, trying to scale back the danger of missing functional bugs to a minimum. While certain well-defined formal verification tasks are often automated through Apps, generally, significant engineering effort is important to capture the IP’s expected behavior in assertions. Furthermore, there’s no guarantee that enough assertions are written. Undocumented functions or unintended gaps within the set of assertions could lead on to unverified IP functionality.
The open-source nature of RISC-V allows the event of prepackaged, independent assurance solutions. OneSpin’s RISC-V Integrity Verification Solution, for instance, is often applied to a good range of microarchitectures. It includes models of the RISC-V ISA and privileged ISA that are extensible and may accommodate custom instructions. an important aspect of this solution is that it’s supported 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 may be a crucial goal. the answer allows SoC integrators with limited expertise on RISC-V and therefore the RTL implementation under scrutiny to realize confidence within 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 within the previous section has been successfully applied to multiple RTL designs. Adaptive Computing, a corporation that integrates innovative solutions to rapidly optimize, assure, and automate systems of systems and processes for a spread of U.S. Department of Defense and commercial sector customers, has applied the method to the RocketCore, for instance. The RocketCore is an open-source, silicon-proven 64-bit RISC-V core with a 39-bit virtual storage system. it’s a five-stage, single-issue, in-order pipeline with out-of-order completion for long latency instructions like division. It includes the advanced features of branch prediction and instruction replay.
The RISC-V Integrity Verification Solution was applied to the planning with all instructions, privilege levels, interrupts, and exception mechanism, and eight issues were detected (see Fig. 3). Additional information on 3 of them is reported below.
Division corner-case: a deep corner-case bug related to 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 cause system misbehavior. the difficulty appears only under a mixture of rare circumstances, which is why previous verification efforts had missed it.
A replay of illegal instruction: this is often 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 think about. Instruction replay may cause unnecessary memory requests. These requests may have side effects that would be leveraged in side-channel attacks. As a result, this behavior must 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 had been not alleged to do. Undocumented, hidden functions aren’t acceptable when trust and security are a priority, even once they relate to use cases that are deemed not relevant to the top application.
The RISC-V assurance process presented during this article detects scenarios that would affect security, and systematically unveils undocumented functions and hardware Trojans that impact the processor’s behavior, no matter how rare and stealthy they could be. However, side-channels aren’t systematically detected. Exhaustive detection of all potential side-channels requires a fanatical solution with appropriate technology. There are already prototypes that address this challenge. For more information, visit onespin.com/resources/technical-articles and skim 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 would also contain hardware Trojans. Unlike for RISC-V cores, independent trust assurance solutions won’t be readily available. during this case, it might be valuable to possess an automatic, low-effort trust assessment process applicable to any IP. A process that doesn’t include a trusted model of the IP cannot ensure a Trojan’s absence. However, it’s possible to spot unusual and suspicious code patterns and known Trojan signatures, and weaknesses that would be exploited in later development stages for nefarious purposes. A paper on this subject titled an automatic Pre-Silicon IP Trustworthiness Assessment for Hardware Assurance, authored by AEROSPACE Corporation and OneSpin engineers, are going to be presented at the GOMACTech 2020 conference.