logo

Failure to Disable Reserved Bits

Incomplete Base
Structure: Simple
Description

The reserved bits in a hardware design are not disabled prior to production. Typically, reserved bits are used for future capabilities and should not support any functional logic in the design. However, designers might covertly use these bits to debug or further develop new capabilities in production hardware. Adversaries with access to these bits will write to them in hopes of compromising hardware state.

Extended Description

Reserved bits are labeled as such so they can be allocated for a later purpose. They are not to do anything in the current design. However, designers might want to use these bits to debug or control/configure a future capability to help minimize time to market (TTM). If the logic being controlled by these bits is still enabled in production, an adversary could use the logic to induce unwanted/unsupported behavior in the hardware.

Common Consequences 1
Scope: ConfidentialityIntegrityAvailabilityAccess ControlAccountabilityAuthenticationAuthorizationNon-Repudiation

Impact: Varies by Context

This type of weakness all depends on the capabilities of the logic being controlled or configured by the reserved bits.
Potential Mitigations 2
Phase: Architecture and DesignImplementation
Include a feature to disable reserved bits.
Phase: Integration
Any writes to these reserve bits are blocked (e.g., ignored, access-protected, etc.), or an exception can be asserted.
Demonstrative Examples 1
Assume a hardware Intellectual Property (IP) has address space 0x0-0x0F for its configuration registers, with the last one labeled reserved (i.e. 0x0F). Therefore inside the Finite State Machine (FSM), the code is as follows:

Code Example:

Bad
Verilog

reg gpio_out = 0; //gpio should remain low for normal operation

case (register_address)

verilog
An adversary may perform writes to reserved address space in hopes of changing the behavior of the hardware. In the code above, the GPIO pin should remain low for normal operation. However, it can be asserted by accessing the reserved address space (0x0F). This may be a concern if the GPIO state is being used as an indicator of health (e.g. if asserted the hardware may respond by shutting down or resetting the system, which may not be the correct action the system should perform). In the code below, the condition "register_address = 0X0F" is commented out, and a default is provided that will catch any values of register_address not explicitly accounted for and take no action with regards to gpio_out. This means that an attacker who is able to write 0X0F to register_address will not enable any undocumented "features" in the process.

Code Example:

Good
Verilog

reg gpio_out = 0; //gpio should remain low for normal operation

case (register_address)

verilog
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
System on Chip : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Documentation
Related Attack Patterns
Related Weaknesses
ChildOf: Improper Adherence to Coding Standards (CWE-710)