Improper Translation of Security Attributes by Fabric Bridge

Draft Base
Structure: Simple
Description

This vulnerability occurs when a hardware bridge incorrectly converts security attributes between different fabric protocols, potentially changing a transaction's identity from trusted to untrusted or vice versa during protocol translation.

Extended Description

Hardware systems often integrate components that use different communication protocols (like AHB, AXI, or OCP), requiring bridges to translate between them. These protocols use dedicated signals (such as HPROT, AxPROT, or MReqInfo) to carry critical security metadata—including the initiating controller's hardware identity, privilege level, and transaction type. The bridge must accurately preserve this security context during conversion. When the bridge misinterprets or incorrectly maps these security attributes, it can fundamentally alter a transaction's trust level. An untrusted initiator might be incorrectly labeled as trusted, or vice versa, leading to severe consequences like privilege escalation, access control bypass, or denial of service by allowing unauthorized access to protected system resources.

Common Consequences 1
Scope: ConfidentialityIntegrityAccess Control

Impact: Modify MemoryRead MemoryGain Privileges or Assume IdentityBypass Protection MechanismExecute Unauthorized Code or Commands

Potential Mitigations 2
Phase: Architecture and Design
The translation must map signals in such a way that untrusted agents cannot map to trusted agents or vice-versa.
Phase: Implementation
Ensure that the translation maps signals in such a way that untrusted agents cannot map to trusted agents or vice-versa.
Demonstrative Examples 1
The bridge interfaces between OCP and AHB end points. OCP uses MReqInfo signal to indicate security attributes, whereas AHB uses HPROT signal to indicate the security attributes. The width of MReqInfo can be customized as needed. In this example, MReqInfo is 5-bits wide and carries the privilege level of the OCP controller. The values 5'h11, 5'h10, 5'h0F, 5'h0D, 5'h0C, 5'h0B, 5'h09, 5'h08, 5'h04, and 5'h02 in MReqInfo indicate that the request is coming from a privileged state of the OCP bus controller. Values 5'h1F, 5'h0E, and 5'h00 indicate untrusted, privilege state. Though HPROT is a 5-bit signal, we only consider the lower, two bits in this example. HPROT values 2'b00 and 2'b10 are considered trusted, and 2'b01 and 2'b11 are considered untrusted. The OCP2AHB bridge is expected to translate trusted identities on the controller side to trusted identities on the responder side. Similarly, it is expected to translate untrusted identities on the controller side to untrusted identities on the responder side.

Code Example:

Bad
Verilog

module ocp2ahb (

verilog
Logic in the case statement only checks for MReqInfo bits 4:2, i.e., hardware-identity bits 3:1. When ocp_mreqinfo is 5'h1F or 5'h0E, p0_mreqinfo_o_temp[2] will be 1. As a result, untrusted IDs from OCP 5'h1F and 5'h0E get translated to trusted ahb_hprot values 2'b00.
Applicable Platforms
Languages:
Verilog : UndeterminedVHDL : Undetermined
Technologies:
Not Technology-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Related Weaknesses