-
Notifications
You must be signed in to change notification settings - Fork 781
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[flash_ctrl/rtl] Enable SecFifoPtr for TL-UL FIFOs #23515
Conversation
This commit enables the .Secure() option of the prim_fifo_sync FIFOs inside the tlul_adapter_sram used by the flash_ctrl module. On an error, the intg_error_o signal will be flagged. Signed-off-by: Pascal Nasahl <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @nasahlpa !
This enables an additional security feature we already had for the blocks we can use it.
Area impact should be super low because it concerns the very small fifo ctrs only.
Code change is small: parameter change to switch on transparent hardening; additional error signals; additional assertions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks @nasahlpa !
With lowRISC#23515, the .Secure(1'b1) parameter was also enabled for the u_tlul_adapter_sram_imem.u_reqfifo and u_tlul_adapter_sram_imem.u_sramreqfifo. Hence, for the same reason as explained in lowRISC#23627 we should also exclude FI on these FIFOs. In addition, lowRISC#23627 only excluded the FI tests for the u_rptr. However, the same issue ('X all over the place) could also happen when faulting the u_wptr of the according FIFO. Hence, this commit also excludes FI for the u_wptr. Signed-off-by: Pascal Nasahl <[email protected]>
With lowRISC#23515, the .Secure(1'b1) parameter was also enabled for the u_tlul_adapter_sram_imem.u_reqfifo and u_tlul_adapter_sram_imem.u_sramreqfifo. Hence, for the same reason as explained in lowRISC#23627 we should also exclude FI on these FIFOs. In addition, lowRISC#23627 only excluded the FI tests for the u_rptr. However, the same issue ('X all over the place) could also happen when faulting the u_wptr of the according FIFO. Hence, this commit also excludes FI for the u_wptr. Signed-off-by: Pascal Nasahl <[email protected]>
With #23515, the .Secure(1'b1) parameter was also enabled for the u_tlul_adapter_sram_imem.u_reqfifo and u_tlul_adapter_sram_imem.u_sramreqfifo. Hence, for the same reason as explained in #23627 we should also exclude FI on these FIFOs. In addition, #23627 only excluded the FI tests for the u_rptr. However, the same issue ('X all over the place) could also happen when faulting the u_wptr of the according FIFO. Hence, this commit also excludes FI for the u_wptr. Signed-off-by: Pascal Nasahl <[email protected]>
With lowRISC#23515, the .Secure(1'b1) parameter was also enabled for the u_tlul_adapter_sram_imem.u_reqfifo and u_tlul_adapter_sram_imem.u_sramreqfifo. Hence, for the same reason as explained in lowRISC#23627 we should also exclude FI on these FIFOs. In addition, lowRISC#23627 only excluded the FI tests for the u_rptr. However, the same issue ('X all over the place) could also happen when faulting the u_wptr of the according FIFO. Hence, this commit also excludes FI for the u_wptr. Signed-off-by: Pascal Nasahl <[email protected]>
With lowRISC#23515, the .Secure(1'b1) parameter was also enabled for the u_tlul_adapter_sram_imem.u_reqfifo and u_tlul_adapter_sram_imem.u_sramreqfifo. Hence, for the same reason as explained in lowRISC#23627 we should also exclude FI on these FIFOs. In addition, lowRISC#23627 only excluded the FI tests for the u_rptr. However, the same issue ('X all over the place) could also happen when faulting the u_wptr of the according FIFO. Hence, this commit also excludes FI for the u_wptr. Signed-off-by: Pascal Nasahl <[email protected]>
This commit enables the .Secure() option of the prim_fifo_sync FIFOs inside the tlul_adapter_sram used by the flash_ctrl module.
On an error, the intg_error_o signal will be flagged.