[fuse_ctrl] Zeroization

[andrea-caforio]

This is a functional (smoke tests not included) draft PR of the zeroization mechanism.

Open questions:

1. The digest field of a partition is used to indicate whether a partition is in a zeroized state by
   counting the number of set bits in its bit representation. This has the side effect that ECC must
   be disabled for all digest fields since they are now read first upon initialization. If this is
   undesirable, we need to revert back to a separate zeroization field.
2. The new OTP_CTRL_DAI_ZER_READ (verification of zeroization) can now read the entire
   address space of a partition. This is unproblematic for software partitions but for hardware partition it
   will return the scrambled data of secret partitions. If this is undesirable, a mechanism needs to
   be added to only allow reads of zeroized fuses. For example:
   • Flop address of most recent zeroized fuse and only allow accesses to this address.
   • Check in hardware whether fuse is zeroized and do not return in the negative case.
3. There is a potential race condition that can occur during zeroization of a buffered
   partition when it is interrupted by a periodical consistency check. These checks are
   currently only disabled after a reset (when zeroization is detected).
   • Transfer the partition into a terminal FSM state upon the first successful OTP_CTRL_DAI_ZER_WRITE
     command?

[vogelpi]

Thanks for the PR @andrea-caforio ! I did a first pass and left some comments. Specifically to your questions:

1. The digest field of a partition is used to indicate whether a partition is in a zeroized state by counting the number of set bits in its bit representation. This has the side effect that ECC must be disabled for all digest fields since they are now read first upon initialization. If this is undesirable, we need to revert back to a separate zeroization field.

I don't think we should ignore ECC bits on the digest unless it's zeroized. Can we instead do the following procedure?

1. Read the digest with ECC disabled to check if the partition is zeroized.
2. If it's not, read the entire partition and at the end the digest including ECC (as in the existing implementation)?

2. The new OTP_CTRL_DAI_ZER_READ (verification of zeroization) can now read the entire address space of a partition. ...

I left a comment directly in the code regarding how this could be addressed.

3. There is a potential race condition that can occur during zeroization of a buffered partition when it is interrupted by a periodical consistency check. These checks are currently only disabled after a reset (when zeroization is detected).
   • Transfer the partition into a terminal FSM state upon the first successful OTP_CTRL_DAI_ZER_WRITE command?

The specification discusses a similar issue related to the life cycle partition and life cycle state updates. The challenge here is that at the point where the is zeroization started by the first DAI command and between the last zeroization write (or the reset to trigger re-reading the zeroized digest).

I think it could be solved by adding a mubi register that is written upon detecting a zeroized digest or the first zeroize write (whatever comes first) which is then used to ignore all integrity and consistency check requests. For my own understanding: the integrity checks can proceed as long as the zeroization isn't finished yet, right (because they operate exclusively on the buffer)?

[andrea-caforio]

Thank you @vogelpi for the thorough review. The PR is ready for a second round. :-)

[andrea-caforio]

Concerning the race condition. The first successful zeroization request to a partition will periodic consistency check for this partition.

[vogelpi]

Thanks @andrea-caforio , I am not done yet and will continue with the review later.

[vogelpi]

Some more comments but still not finished. Will continue later.

[andrea-caforio]

@vogelpi Thanks for the 2nd-round of review. With the exception of one point (see comment), I hope everything else
is addressed.

[vogelpi]

Thanks @andrea-caforio for the updates. I have some questions remaining. This is looking good.

[vogelpi]

Thanks @andrea-caforio for addressing the remaining comments. This LGTM!

As discussed over email, we should add a separate field per partition to mark them as zeroized rather than using the digest (to avoid collisions - especially when defining a non-zero margin). But this can be done as a separate PR in my view.

[elliotb-lowrisc]

I'm a bit concerned about the use of $countones(otp_rdata_i).

I suspect $countones may not be synthesisable in all tools. It seems Vivado supports it, but I'm not sure about others. Might I suggest something like the following (untested) 'loop':

logic [$bits(ScrmblBlockWidth)-1:0] count;

count = 0;
for (int ii = 0 ; ii < ScrmblBlockWidth ; ii++) begin
  count = count + otp_rdata_i[ii];
end

Hopefully this will be synthesised as a tree of adders. First adding 32 pairs of single bits, then adding 16 pairs of those two-bit partial sums, 8 pairs of three-bit part-sums, 4 pairs of four-bit part-sums, 2 pairs of five-bit part-sums, and a final add of a pair of 6-bit part-sums to reach the final single result.

Such a large adder tree may unfortunately take up a sizable bit of chip area and path delay.

If you are simply checking that all bits are set (as currently seems to be the case) then it would be far better to use a reduction AND operation: &otp_rdata_i

Another way to reduce the chip area could be to split the 'countones' adder-tree into a separate module and only instantiate one that is shared by all partitions somehow. You may be able to optimise this further by turning it into a multi-cycle operation and greatly reducing the size of the adder tree.

There may also be more efficient ways to synthesise $countones than what I can currently think up.

[matutem]

@elliotb-lowrisc The logarithmic $countones you describe should work, may be required given #579. The largest number of adders are quite small so it may not be that terrible. We could also stop adding at some level, for example given the counts for 16-bit chunks, and decide on that partial information. For example, and based on #579, we could flag "fatal" if more than one has a count of 2, and "okay" if none has more than 1.

[elliotb-lowrisc]

@matutem Ah, I had missed that the zeroization test logic had moved from being in each partition to being a single instance in the DAI. The impact on chip area shouldn't be nearly as bad as I previously thought. $countones support in synthesis tools remains a question for me. I'd personally choose to avoid it just in case, but it can be left as-is and changed later if it does turn out to be an issue or to improve area a bit.

[elliotb-lowrisc]

Or was I still mistaken? Perhaps it is in both the DAI and each partition. My apologies. I am still concerned about the chip area impact then.

[elliotb-lowrisc]

I've not yet fully come to grips with these changes (or OTP in general), but I have found a few things I hope will be useful to point out.