Inconcistency in Shadow stack enable definition ? (and wavedrom typo)

[Antoine Linarès]

Hello, according to me there is an inconsistency in the description of the enable state for Shadow Stack (xSSE).

In the menvcfg description we have:

Zicfiss extension introduces the SSE field (bit 3) in menvcfg. When SSE field is 1, the Zicfiss extension
is enabled in S-mode. When SSE field is 0, the Zicfiss extension is not enabled in S-mode and the
following rules apply to privilege modes less than M.
• Attempts to access the ssp CSR raise an illegal instruction exception.
• The 32-bit Zicfiss instructions revert to their Zimop defined behavior.
• The 16-bit Zicfiss instructions revert to their Zcmop defined behavior.
• The pte.xwr=010b encoding in S-stage page tables is reserved.
• The henvcfg.SSE and senvcfg.SSE fields are read-only zero.

Privilege Mode	xSSE
M	1
S/HS	menvcfg.SSE
VS	henvcfg.SSE
U/VU	senvcfg.SSE

Would look like below: (as henvcfg.SSE and senvcfg.SSE fields are read-only zero)

Privilege Mode	xSSE
M	1
S/HS	menvcfg.SSE
VS	henvcfg.SSE && menvcfg.SSE
U/VU	senvcfg.SSE && menvcfg.SSE

or maybe the text is wrong.

Also, there is a typo in the mseccfg wavedrom scheme:

line 167: ], config:{lanes: 1, hspace:1024}}
might be replaced by ], config:{lanes: 4, hspace:1024}}
otherwise the sheme is quite unreadable

[Ved Shanbhogue]

or maybe the text is wrong.

Both are right. While showing an & of the two bits is a legal implementation, showing it as such would constrain other implementations that are allowed by section 2.4 of the Priv. specification. The effective xSSE however is the state of the controlling bit as shown in the table.

Also, there is a typo in the mseccfg wavedrom scheme:

Thanks. Fixed it in PR #150