Cycuity recently expanded the Radix family with the introduction of Radix-ST , adding static security analysis capabilities to our hardware security verification solutions. This addition strengthens security assurance by complementing existing dynamic security verification solutions, Radix-S and Radix-M, which leverage simulation and emulation. Unlike these dynamic methods, Radix-ST focuses on analyzing RTL (Register Transfer Level) source code, making it effective from the earliest design stages. While static analysis has its limitations in identifying certain types of security issues, it is more efficient and capable of uncovering security risks that are difficult to detect with dynamic techniques.
When Radix-ST identifies a potential weakness, it cross-references it with the Common Weakness Enumeration (CWE) database. This public, community-developed list of software and hardware weakness types is maintained by the MITRE Corporation, providing a standardized measure for security tools and professionals.
Static vs. Dynamic Testing
To understand the value of Radix-ST, it’s important to distinguish between static and dynamic analysis. Dynamic testing focuses on specific test cases or scenarios, running RTL code to see how it behaves under certain conditions. While useful, it can only test the paths that are explicitly defined. What about the paths that are not?
Static analysis takes a more comprehensive approach. It systematically reviews the entire codebase of a design without executing it. This thorough examination is invaluable for uncovering hidden vulnerabilities, corner cases, and potential attack vectors that might otherwise remain undetected during simulation. By analyzing every line of code, Radix-ST can identify weaknesses that may never surface in a standard testing environment.
How does Radix-ST Work in Your Environment
Integrating Radix-ST into your existing workflow is straightforward. The tool takes block, sub-block, or SoC RTL code as input and processes it to generate a detailed report on whether CWEs were violated.
The violations are presented in the Radix Analysis GUI, where each identified issue is linked directly to the specific line of source code that caused it. This clear connection between the weakness and its location in the design allows engineers to quickly understand the problem and implement a fix.
Radix-ST does not need a simulation test bench. This is an advantage as, early in the design phase when only the RTL for the design is ready, or only sub-blocks of the design are available, Radix-ST can be used to identify and fix security-related issues in the code.
Practical Examples of how to leverage Radix-ST
Let’s look at a common design scenario using a memory block where the read and write addresses, as well as the size of the memory is programmable.
When Radix-ST analyzes the RTL code of the design, it flags CWE-125 (Out-of-bounds Read) and CWE-787 (Out-of-bounds Write). An out-of-bounds read could allow an attacker to access sensitive data stored in other parts of memory. An out-of-bounds write could lead to data corruption, denial of service, or even arbitrary code execution. By flagging these potential issues early, Radix-ST analysis can be used to implement the necessary logic to prevent these memory access violations before the design moves to the next stage, closing a security loophole.
CWE-125
CWE-787
Shifting-Left for Hardware Security Assurance
Radix-ST supports the “Shift-Left” methodology of moving testing and verification activities as early as possible in the design cycle. By identifying security concerns before simulation even begins, Radix-ST enables design teams to strengthen the overall security of the design and avoid the costs and complexities associated with late-stage bug fixes and redesigns.