Hardware Security Verification Example: CWE-1252

Common Weakness Enumeration (CWE) is a community-developed list of software and hardware weakness types which may cause Security issues. The list is maintained by the MITRE organization and can be found here: cwe.mitre.org

In my previous post, “Better Hardware Security Verification through CWE and Information Flow Checking” I introduced Information Flow Checking as a way to verify that you don’t have the weaknesses listed in the CWE database in your design.

Here, let’s look at a more detailed example of how you can translate a Hardware CWE to a security rule which you can include in your simulation regression runs.

“The CPU is not configured to provide hardware support for exclusivity of write and execute operations on memory. This allows an attacker to execute data from all of memory. CPUs provide a special bit that supports exclusivity of write and execute operations. This bit is used to segregate areas of memory to either mark them as code (instructions, which can be executed) or data (which should not be executed). In this way, if a user can write to a region of memory, the user cannot execute from that region and vice versa. This exclusivity provided by special hardware bit is leveraged by the operating system to protect executable space. While this bit is available in most modern processors by default, in some CPUs the exclusivity is implemented via a memory-protection unit (MPU) and memory-management unit (MMU) in which memory regions can be carved out with exact read, write, and execute permissions. However, if the CPU does not have an MMU/MPU, then there is no write exclusivity. Without configuring exclusivity of operations via segregated areas of memory, an attacker may be able to inject malicious code onto memory and later execute it.”

This CWE illustrates how lack of HW support for security (write exclusivity) or a mis-configured MPU may lead to a security vulnerability.

Depending on the actual design implementation there may be several vulnerabilities to verify. Here let’s consider the two cases of writing to instruction memory and executing code from data memory. These cases can be modelled as information flow verification.

In this example, consider the hypothetical SoC below:

The tmcu doesn't have support for write exclusivity and it doesn't have an MPU or MMU to isolate memory regions as execute only. Hence, the tmcu load store unit can write to the entire sram.mem memory and the instruction fetch unit can execute code in the entire sram.mem as well.

Threat Model

An attacker can write malicious code to instruction memory and later execute the code or execute code from data memory.

Security Requirement

If the processor lacks support for write exclusivity, other logic must implement this functionality to prevent writes to instruction memory and instruction fetch from outside instruction memory.

Radix Security Rules

The requirements can be expressed as information flow verification problems i.e.:

• Information (write data) in the Load Store Unit of the tmcu should not be written to sram when the address is outside the instruction address range
• Information (read data) in the sram outside the instruction address range should not be read and flow to the instruction fetch unit of the tmcu.

Using the Tortuga Logic Radix no-flow operator “=/=>” we can write the following security rules:

Verification

Using the security rules above, the Tortuga Radix tool will build a security model which when simulated together with the design will flag any violation of the rules.

Using information flow security rules, over 80% of the MITRE Hardware CWEs can be verified by Radix.

To learn more about how to write security rule checks based on the Hardware CWE list, see this white paper.