lowRISC / lowRISC/opentitan

[otp_macro] Add support for not burning any fuse twice

Open
#28,023 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Component:RTL
Dominant language
SystemVerilog
Stars
3.6k
Forks
1.1k
Avg merge
2d 22h
Merged PRs (30d)
141

Description

Some eFuse implementations may signal an error or expose undefined behavior if one tries to "burn" (write 1 to) an individual fuse bit that has already been burned.

The current `otp_macro` doesn't take this into account: While the read-modify-write ensures that no bits get cleared, it unconditionally sets a bit to 1 if the data to be written has it set:
https://github.com/lowRISC/opentitan/blob/3744f2cb27bb4e2e1f7dd7982727badb2c963943/hw/ip/otp_macro/rtl/otp_macro.sv#L409-L411

The logic function we want instead is `wdata_new = wdata_rmw & ~rdata_q[cnt_q]`, I think:

| wdata_rmw | rdata_q[cnt_q] | wdata_new |
|-----------|----------------|-----------|
| 0 | 0 | 0 |
| 0 | 1 | 0 |
| 1 | 0 | 1 |
| 1 | 1 | 0 |

My first thought was to make this the default implementation. However, that could be suboptimal from a security perspective for eFuses that accept "double burning" -- as FI could try to attack this logic? On the other hand, `otp_macro` is a generic implementation (which instantiates a RAM to store data rather than an actual eFuse macro which may have a more complex interface than that of an SRAM).

Thoughts @Razer6, @andrea-caforio, @vogelpi, @moidx, @matutem ?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read hw/ip/otp_macro/rtl/otp_macro.sv around lines 409-411 and trace the read-modify-write path. Resolve with maintainers whether already-burned bits should be suppressed by default or handled differently for security, then verify the chosen behavior in the relevant RTL tests. Done means the policy is agreed and the macro no longer attempts unsupported repeated burns.

Written by the indexing model from the issue text.

Assessment

Domain
embedded-iot, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.