Issue to track latest AR feedback

[ved-rivos]

Here is summary of feedback to be updated in next PR:

1. Move CSRs description into their extension specific chapter
2. Renamce *FCFIE and *BCFIE to LPE and SSE respectively
3. Move MPELP/SPELP bit positions in mstatus to bits 41/23 respectively
4. Move U-mode SSE/LPE from mstatus to *envcfg CSRs
5. Rename ssprr to ssrdp and sspinc to ssincp
6. Separate mnemonic for ssload to be sslw when xlen is 32 and ssld when xlen is 64
7. Restrict sspinc to only pop one xlen wide word
8. Replace illegal inst on lp miss or return address missmatch to use new integrity-check fault (was in PR Introduce integrity-fault exception #137 )

I will create a PR with 1 through 7 shortly.

The AR has asked us to drop the ssamoswap instruction. The current use of the ssamoswap to perform an atomic read of the checkpoint and replace it with a value of 0 so as to enforce the "use checkpoint once" property can be achieved using a non-atomic sequence. The window of vulnerability between reading the checkpoint and clearing it is considered acceptable. If TG members have a counter to this please add to this issue. Otherwise we will be dropping this instruction in next update. If we drop ssamoswap we would need a sswr to be able to write to the shadow stack for functional reasons such as exception fixup, boot strap a new shadow stack with a checkpoint, and signal delivery cases.

[ved-rivos]

PR #139 created to address this issue.

[ved-rivos]

Since this is a large PR I will go ahead and merge it so its easier to read the merged text. Please feel free to leave comments in the PR or in this issue.

[jklockars]

The text currently says bit 2 for SSE in senvcfg and henvcfg. Should be bit 3 as for menvcfg (and the figures).

[jklockars]

Doesn't the new handling of LPE for U go against what the privileged standard says regarding MENVCFG?

I understand that the idea is to make it possible to enforce landing pads in U without doing it in S, and for some reason save bits in *STATUS, but it seems inconsistent with the intended purpose of MENVCFG as stated in the standard.
For SENVCFG, the standard says that it controls the U-mode execution environment, but MENVCFG "controls certain characteristics of the execution environment for modes less privileged than M".

Now SENVCFG.LPE enables LP for U, even if MENVCFG has it disabled "for modes less privileged".

Also, it is a bit strange that an operating system would be required to change the U-mode execution environment on task switch (when only some tasks have LP protection).

[ved-rivos]

The text currently says bit 2 for SSE in senvcfg and henvcfg. Should be bit 3 as for menvcfg (and the figures).

Thanks. Queued PR #140 to fix that.

[ved-rivos]

Doesn't the new handling of LPE for U go against what the privileged standard says regarding MENVCFG?

So while the current bits in the menvcfg have affected all privilege modes less than M that does not need to be true always. I interpret this text as "that controls certain characteristics of the execution environment for modes less privileged than M" as allowing for controlling only a subset of execution environment less privileged than M. I will bring this up with AR to verify if they really intended this when it was suggested.

Also, it is a bit strange that an operating system would be required to change the U-mode execution environment on task switch (when only some tasks have LP protection).

The OS can optimize this. For example, if the outgoing senvcfg and incoming senvcfg settings are identical then a change is not required.

[jklockars]

The stated encoding for c.ssincp ("c.lui x0, 0") is said to be c.mop.0, which does not comply with what was said earlier regarding Zcmop.

Eight code points in the 16-bit encoding space are provided for MOPs:
c.mop.0, encoded in the reserved encoding space where c.lui x1, 0 would be encoded
c.mop.1 (c.lui x3, 0)
c.mop.2 (c.lui x5, 0)
...
c.mop.7 (c.lui x15, 0)

Is it c.ssincp that is wrong, or has the proposed Zcmop changed?

The documentation must also be wrong regarding which c.mop.N that are used for c.sspush x1 (claimed c.mop.1, but should be c.mop.0 according to earlier Zcmop description) and/or c.sspopchk x5 (claimed c.mop.2, which was correct according to earlier Zcmop description).

[ved-rivos]

That is unfortunately an error that crept in. The c.ssincp should be c.mop.1, c.sspush should be c.mop.0, and c.sspopchk be c.mop.2. Fixed in f419a17

[ved-rivos]

Following the Architecture Review, the Architecture Review Committee (ARC) requested a justification for the ssamoswap instruction. We have attached a writeup on this topic. Please provide your comments and feedback on this paper.

[ved-rivos]

Updates from 9/26 ARC:

• We extensively discussed the Zicfiss extension's proposed ssamoswap instruction. Although we remain concerned that the instruction incompletely addresses its stated purpose of preventing multiple threads from initiating execution on the same shadow stack, we do not object to its inclusion, given that it subsumes the ssstore instruction at minimal additional cost. (The implication is that Zicfiss will depend on implementations supporting AMOs, which we believe will be broadly acceptable.)
• Also on the topic of the Zicfiss extension, we request that the instructions that support the control-stack mode (namely, ssload and ssincp) be split into a separate extension. We anticipate ongoing debate over the control-stack mode's practicality, given that it requires an ABI change yet offers reduced security as compared to the shadow-stack mode. Recognizing the importance of the shadow-stack feature, we wish to facilitate its rapid approval while the control-stack discussion continues.
• Finally, we discussed the Zicfilp extension. We'll reach out to the TG to address some minor CSR-field adjustments, but otherwise we anticipate a smooth path to approval.

[ved-rivos]

PR #156 created to add the main feedback.

[ved-rivos]

Please leave feedback in on the PR in this issue or directly in the PR.

[ved-rivos]

Closing this issue. The pending code point updates will be tracked in #154