1994
Access-control-policy protections must be reviewed for design inconsistency and common
weaknesses. Access-control-policy definition and programming flow must be tested in pre-silicon,
post-silicon testing.
Effectiveness = High
Demonstrative Examples
Example 1:
Consider a system with a register for storing AES key for encryption or decryption. The key is
128 bits, implemented as a set of four 32-bit registers. The key registers are assets and registers,
AES_KEY_READ_POLICY and AES_KEY_WRITE_POLICY, and are defined to provide necessary
access controls.
The read-policy register defines which agents can read the AES-key registers, and write-policy
register defines which agents can program or write to those registers. Each register is a 32-bit
register, and it can support access control for a maximum of 32 agents. The number of the bit when
set (i.e., "1") allows respective action from an agent whose identity matches the number of the bit
and, if "0" (i.e., Clear), disallows the respective action to that corresponding agent.
Example Language: Other (Bad)
In the above example, there is only one policy register that controls access to both read and write
accesses to the AES-key registers, and thus the design is not granular enough to separate read
and writes access for different agents. Here, agent with identities "1" and "2" can both read and
write.
A good design should be granular enough to provide separate access controls to separate
actions. Access control for reads should be separate from writes. Below is an example of such
implementation where two policy registers are defined for each of these actions. The policy is
defined such that: the AES-key registers can only be read or used by a crypto agent with identity
"1" when bit #1 is set. The AES-key registers can only be programmed by a trusted firmware with
identity "2" when bit #2 is set.
Example Language: (Good)
Example 2:
Within the AXI node interface wrapper module in the RISC-V AXI module of the HACK@DAC'19
CVA6 SoC [REF-1346], an access control mechanism is employed to regulate the access of
different privileged users to peripherals.
The AXI ensures that only users with appropriate privileges can access specific peripherals. For
instance, a ROM module is accessible exclusively with Machine privilege, and AXI enforces that
users attempting to read data from the ROM must possess machine privilege; otherwise, access to
the ROM is denied. The access control information and configurations are stored in a ROM.
Example Language: Verilog (Bad)
...
for (i=0; i<NB_SUBORDINATE; i++)
begin
for (j=0; j<NB_MANAGER; j++)
begin
assign connectivity_map_o[i][j] = access_ctrl_i[i][j][priv_lvl_i] || ((j==6) && access_ctrl_i[i][7][priv_lvl_i]);
end
end
...
CWE Version 4.14
CWE-1220: Insufficient Granularity of Access Control
CWE-1220: Insufficient Granularity of Access Control