Hi,

Maybe the little issue has been solved. I am just curious. The follows come from "4.1. The seed CSR" in Cryptography Extensions Volume I. It talks about the side effect on read the seed CSR.

===

4.1. The seed CSR

...

For security reasons, the interface guarantees that secret entropy words are not made available multiple times. Hence polling (reading) must also have the side effect of clearing (wipe-on-read) the entropy contents and changing the state to WAIT (unless there is entropy immediately available for ES16). Other states (BIST, WAIT, and DEAD) may be unaffected by polling.

===

However, in the introduction of Chapter 2 in the privileged spec (20211203), it says, "Standard CSRs do not have side effects on reads but may have side effects on writes."

Is there any explanation? or we should modify one of them?

Thanks!

Sincerely,

Paul

On Fri, May 6, 2022 at 2:07 AM Vedvyas Shanbhogue <ved@...> wrote:

The seed CSR must be accessed with a read-write instruction. A read-only instruction raises an illegal instruction exception. So one could consider the wiping as occurring due to the write and not as a side effect of the read and CSRRW is required to be atomic. I think the Zkr spec seems to be loose on the side effect behavior in this paragraph but later explains that the write is the one that does the wipe "The purpose of the write is to signal polling and flushing"  - unfortunately there is no definition for "flushing" but could be interpreted to mean wiping as intended?

Hi,

Yes, the only allowed way of accessing the SEED register is via a read-write operation (csrrw rd, seed, x0) and hence the "write" is explicitly stated. Since a plain read is not even allowed, clearing/polling is not a side effect -- it is explicitly caused by the "write zero" part.

W.r.t. polling and flushing; there is no uniform definition for this and I can imagine different ways of bringing the entropy to the CSR. The most important thing is that it is never possible to read the same entropy word twice (the numerical value for consecutive entropy words can of course the same).

If the implementation is a (FIPS 140-3 or similar) cryptographic module, it will have a completely separate  "zeroization" function; each read would *not* be a zeroization. In short, zeroization is a function that is intended to be invoked on a physical breach of the module, or by a user request. Signaling-wise it can be related to reset logic.

Cheers,

- markku

 

regards

ved

On Thu, May 5, 2022 at 7:56 PM Paul Ku <scku@...> wrote:

Hi,

Maybe the little issue has been solved. I am just curious. The follows come from "4.1. The seed CSR" in Cryptography Extensions Volume I. It talks about the side effect on read the seed CSR.

===

4.1. The seed CSR

...

For security reasons, the interface guarantees that secret entropy words are not made available multiple times. Hence polling (reading) must also have the side effect of clearing (wipe-on-read) the entropy contents and changing the state to WAIT (unless there is entropy immediately available for ES16). Other states (BIST, WAIT, and DEAD) may be unaffected by polling.

===

However, in the introduction of Chapter 2 in the privileged spec (20211203), it says, "Standard CSRs do not have side effects on reads but may have side effects on writes."

Is there any explanation? or we should modify one of them?

Thanks!

Sincerely,

Paul