2016
);
reg lock_status;
always @(posedge Clk or negedge resetn)
if (~resetn) // Register is reset resetn
begin
lock_status <= 1'b0;
end
else if (Lock)
begin
lock_status <= 1'b1;
end
else if (~Lock)
begin
lock_status <= lock_status
end
always @(posedge Clk or negedge resetn)
if (~resetn) // Register is reset resetn
begin
Data_out <= 16'h0000;
end
else if (write & (~lock_status | scan_mode | debug_unlocked) ) // Register protected by Lock bit input, overrides supported
for scan_mode & debug_unlocked
begin
Data_out <= Data_in;
end
else if (~write)
begin
Data_out <= Data_out;
end
endmodule
If either the scan_mode or the debug_unlocked modes can be triggered by software, then the lock
protection may be bypassed.
Example Language: (Good)
Either remove the debug and scan mode overrides or protect enabling of these modes so that only trusted and authorized
users may enable these modes.
Example 2:
The following example code [REF-1375] is taken from the register lock security peripheral of
the HACK@DAC'21 buggy OpenPiton SoC. It demonstrates how to lock read or write access to
security-critical hardware registers (e.g., crypto keys, system integrity code, etc.). The configuration
to lock all the sensitive registers in the SoC is managed through the reglk_mem registers. These
reglk_mem registers are reset when the hardware powers up and configured during boot up.
Malicious users, even with kernel-level software privilege, do not get access to the sensitive
contents that are locked down. Hence, the security of the entire system can potentially be
compromised if the register lock configurations are corrupted or if the register locks are disabled.
Example Language: Verilog (Bad)
...
always @(posedge clk_i)
begin
if(~(rst_ni && ~jtag_unlock && ~rst_9))
begin
for (j=0; j < 6; j=j+1) begin
reglk_mem[j] <= 'h0;
end
end
...
CWE Version 4.14
CWE-1235: Incorrect Use of Autoboxing and Unboxing for Performance Critical Operations
CWE-1235: Incorrect Use of Autoboxing and
Unboxing for Performance Critical Operations